When will CVS be replaced by modern version control system?

[Nils Philippsen]

Just for the record, I'm not really interested in private forks of this
discussion. I'll answer some things now that I've received as a personal
mail, slightly edited/rephrased where necessary to protect anonymity. In
the future I won't be so forthcoming -- I'll just reply to the list
fully quoted.

Someone wrote:
> On Sat, 2007-11-10 at 13:41 +0100, Nils Philippsen wrote:
[...] 
> > I have switched over several of my projects from CVS to mercurial and
> > have found that everything I did with CVS I could do with mercurial, but
> > with much less hassle.
> You are the only person with write access, I presume?

Not really. In fact, just about every Fedora translator can -- either by
ways of Transifex or directly -- commit to the repositories.

> You are committing all of your local changes into hg, immediately when
> you change a file locally? (I am use to use checkouts with uncommitted
> local changes)

That's the idea. With Hg (and git and others likely, too), you can
commit every small change because committing isn't expensive. This way I
can easily revert things I broke in between (again without time
consuming network round trips).

> Whenever I use hg I repeatedly find myself in endless
> "pull/merge/commit/push" loops I couldn't get out of. In the end
> causing me to loose changes/patches and having to resurrect work from
> other sources.

With every VCS where more than one person can commit -- distributed or
not -- you have that problem: The person second to commit must bear the
burden of merging. It's only that Hg, git, ... make merging much simpler
than you're used to from CVS.

Take a situation where someone commits a change to a file just before I
wanted to do that. With CVS it goes like this:

nils at gibraltar:~/test/vcs/cvstest/co2> cvs ci
cvs commit: Examining .
cvs commit: Up-to-date check failed for `a'
cvs commit: Examining CVSROOT
cvs [commit aborted]: correct above errors first!

Then you need to "cvs up", which will implicitely try to merge the
changes. In the event of conflicts CVS will garble the file with
snippets of the conflicting revisions ("<<<...", "===...", ">>>..."),
you need to resolve the conflict in the file without aid of
3way-diff-tools like meld and commit. Hopefully you haven't left any of
the conflict markers in the file at this point ;-).

With Mercurial it goes like this:

nils at gibraltar:~/test/vcs/hgtest/co2> hg ci
No username found, using 'nils at gibraltar.str.redhat.com' instead
nils at gibraltar:~/test/vcs/hgtest/co2> hg push
pushing to /home/nils/test/vcs/hgtest/repo
searching for changes
abort: push creates new remote branches!
(did you forget to merge? use push -f to force)

Then I run "hg pull -u; hg merge", it looks like this:

nils at gibraltar:~/test/vcs/hgtest/co2> hg pull -u
pulling from /home/nils/test/vcs/hgtest/repo
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
not updating, since new heads added
(run 'hg heads' to see heads, 'hg merge' to merge)
nils at gibraltar:~/test/vcs/hgtest/co2> hg merge
merging a
conflicts detected in /home/nils/test/vcs/hgtest/co2/a
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

In this case the merger had conflicts, "hg merge" automatically invoked
"meld" which allowed me to easily resolve the conflict, then I committed
again and pushed.

These two ways look very similar to me, with the notable exception of
the automatic invocation of meld in the Hg case (which is of great help
when resolving conflicts).

> Another regression in using hg: WAY more interactive actions required to
> achieve the same purpose.

"cvs up" vs. "hg pull -u" and "cvs ci" vs. "hg ci; hg push" aren't way
more in my book. In fact, you wouldn't need to (shouldn't!) push with
every single small commit. In our case of packaging, you only needed to
push before building or when you're done for the day, leave for lunch,
after every few commits if you're afraid of merging...

To avoid "WAY more interactive actions", we could easily do the VCS
actions as Makefile targets, then let "tag" depend on "push" (or let it
implicitly do that). That way packagers wouldn't have to adapt to
changes even if we switched from a VCS to clerks filing things on paper
and people wouldn't notice a thing (except that things were slightly
slower than with CVS ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011