Re: cvs better than git?

[Andreas Krey <a.krey%gmx.de@localhost>]

On Sun, 21 Jun 2020 15:20:39 +0000, Johnny Billquist wrote:
...
> >40. And you can abbreviate as far as they stay unambiguous.
> 
> And it's still not anything you would want to type at all.

Yes, but. There are lots of ways to reference commits, like
'two before the current commit on this branch', but in the
end, if you want to reference a random commit, you have a
random address - a hash in git, a revision number in svn,
and, well, nothing in cvs.

...
> I am still curious about how to manage well in git the scenario where 
> you do have a central repository that holds the actual source of truth, 
> and where you want to review and approve anything that gets committed. 

That depends on how you want to work - in git is the usual way
that you commit your work, in reasonable steps, and then hand
that out for review. For git itself this means posting the
diffs of each commit to the git mailing list. (Unsurprisingly
there are tools for that within git.)

For the workflow in our company this means pushing your commits
on a personal branch, creating a pull request, and discussing
the changes inside that pull request and making changes until
all reviewers are happy; then that is ready for integration.

In git you usually don't review changes *before* you commit them.

> The gains of local repositories certainly diminish in the light of that, 

Not really. You wouldn't want to work with any central VCS once
you're 250ms away from the server.

> but it does add potential issues in keeping things in sync, getting 
> committed and shared.

Yes, 'potential'. For a company setting, you avoid these by
providing scripts for the standard workflow actions. You'll
need - or at least want - these, independent of whether you
work with clearcase, svn, or git, as soon as you don't all
work on a single branch.

> As I mentioned, we are using gerrit for this where 
> I work. But that is certainly not without a lot of pain.

I've never seen gerrit up close, and my hearsay indicates
it's a mixed bag. (We use hosted bitbucket, which so far
is a pleasant experience.)

PS: Reading up a bit on gerrit, it seems to use a patch-based
model, with reworking the patches (i.e. amending commits).
That can be daunting for beginners.

> If you use something like github, then you will be using their systems 
> and mechanism for this, and if you are forced to switch, then this also 
> gets hit.

Yes, but you don't lose your history or your current work; 'only'
the open pull requests. With an hypothetical svnhub you'd also
lose the history and have to set up a new server, totally invalidating
all the dev's workspaces. With git, the transition can be much smoother,
even in the case github goes bellyup instantaneously (e.g. you are
kicked out as a customer).

> Which was my point. It's not that you have "pure" git in the 
> first place. If you use some external service, you will also be 
> dependent on surrounding infrastructure provided,

If you choose so. But it's the same with internal infrastructure.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800