Suffering from CVS mindset

Mike Meyer mwm at mired.org
Mon Apr 12 15:50:06 CDT 2010


On Sun, 11 Apr 2010 13:43:36 -0500
Harry Putnam <reader at newsguy.com> wrote:

> Martin Geisler <mg at lazybytes.net> writes:
> 
> >   cd ~/scripts/perl
> >   hg commit -m "Fixed bug."
> >   cd ~/scripts/shell
> >   hg commit -m "Optimized."
> >
> > The difference is that the Perl scripts and the shell scripts now live
> > in different repositories and have different and independent
> > histories. The units-of-work before more well-defined this way. Like
> > Masklinn said, there is no overhead associated with creating
> > repositories in Mercurial (compare "mkdir foo" with "hg init foo"), so
> > this is the suggested way to do things.
> 
> Hope I'm not sounding like a argumentative dodo, but.....
> 
> First, that is a false premise (I think).  You can't compare mkdir foo
> against  hg init foo) .. (both are needed in either case so you would'nt
> compare one against the other) 
> And especially not to creating one repo for all.
> 
> It would be more like mkdir * 12 hg init * 12
> 
> As apposed to mkdir * 13 <to have a top level>,  hg init * 1 <in that
> top level>

As others have pointed out, not quite.

> And so it would be with any other commands wouldn't it?
> 
> That is, instead of hg commit, it would be hg commit * 12.

If you did it that way. But you don't have to.

> Its entirely possible I'm missing the boat here... as I've mentioned
> starting out I'm a total green horn, not to mention a tab bit `thick'.
> But wouldn't it take 12 times the commands to have 12 repos for 12
> projects?  As opposed to 1 repo with 12 directories, each containing
> files and subdir.
> 
> I think at root, I'm really just not getting why its better to keep
> record of changes in an entire repo with every commit, as apposed to
> keep record of changes to individual files.

What percentage of the time do you fix a bug or add a feature and it
only changes *one* file?  Clearly not all the time, but even in a
python-like environment, I'd expect two or three (one each for M, V
and C) to be common, and in a java-like environment - with one file
per class - it could easily be "many".

> I guess I can see a big benefit when the entire repo is strongly
> related, and a single set of software is expected to emerge.
> 
> Beyond that.... I start to not be able to see how things are supposed
> to work for someone mostly interested in individual files.

If you're keeping track of a collection of unrelated files - from your
example, collections of unrelated perl/sh scripts, a collection of
unrelated small C programs, etc, then it works the same way in
mercurial (or any other DVCS) as it would in CVS (or svn, or any other
CVCS).

From my own example, I have src/sh, src/perl, src/python and src/c
(among others), pretty much as described above. In most CVCSs, I have
to decide if I want to check out src, and get one working copy that
holds all of them, or grab the sub-directories, and get one working
copy for each of them.

In a DVCS, you get the same decisions, except you get repositories
instead of working copies. Having one big repo/checkout has the same
upside in both: you can check in lots of changes at once. It has the
downside that you may well get lots of things that aren't of interest
where you're checking it out.

In fact, I find that the easiest way to deal with DVCS's: thinking
about repos as svn "working copies". If I want to start a development
branch for a project in svn, I'll branch it in the server and check
out or switch a working copy to that for the work. In mercurial, I'll
clone a repo and work in the new one.

Where in a large SVN or perforce (or even CVS) project I might have
two or three copies of the project checked out - one a copy of
production should the need for an emergency fix arise, and one of the
trunk for ongoing development, and possibly a copy of the next release
candidate to merge things into from the other two branches, or a
longer-term development branch of some sorth - with mercurial I'll
have multiple repos: a copy of what's in production, a copy of the
development repo, and copies of other things that might be of
temporary interest, like a release candidate or development branch.

In theory, this could all be done with one repo (or working copy) with
multiple branches and switching between them, but that seems to
generate more problems than solutions, as it makes accidents where you
check fixes into the wrong branch a bit to easy.

> Once again, it could very well be due to being a simpleton or just not
> enough experience with it yet.  I ran cvs for around 12 yrs and never
> went beyond the most basic usage. And was still fumbling around at
> times after all that usage.
> So, its likely to take me a while to absorb the different kind of
> focus. 

Sounds like you were using CVS mostly as a wrapper for RCS
commands. Going from that to a DVCS in one swoop is a *long*
stretch. I got to do it in four steps
(RCS/SCCS&CVS/Piccolo/Perforce&svn&etc./DVCSs), and still have problems
with some of the assumptions behind DVCSs.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


More information about the Mercurial mailing list