Suffering from CVS mindset

Martin Geisler mg at lazybytes.net
Sun Apr 11 06:41:01 CDT 2010


On Sun, Apr 11, 2010 at 10:51, Johan Samyn <johan.samyn at gmail.com> wrote:
>
> In Cvs you track files. While in a dvcs you track some kind of unit-of-work.
>
> So if a unit-of-work needs changes to more than one file, you can
> simply do that, and then commit as a whole. All files will then be
> 'grouped' together in that one committed changeset.That perfectly
> explains the word 'changeset' : a set (= maybe more than one) of
> changes that belong together.
>
> This changeset has more than one extra value over committing single
> files : you can f.i. 'undo' a complete change in one move being sure
> the changes in all the files of that unit-of-work are undone together.
> (Try that with Cvs ...)
> You can export a changeset, being sure you have all changes belonging
> together in that bundle. Etcetera.
>
> So if you make different changes into your different 'modules' (perl,
> backup, etc), it's up to you to determine what are the right
> units-of-work for those uncommitted changes. If the one perl file is a
> u-o-w, then commit it separately. If two files where changed for the
> backup experiment, commit those two together in a separate commit too.
> Then you can register a really meaningfull commit message for every
> separate commit.
>
> The Hg tool has no way of determining what changes belong toether for
> your units-of-work. Not even by considering the top-folder names. So
> you - the human - have to do the book keeping yourself (explicitely
> mentioning the files for a commit), or only work on one unit-of-work
> at a time (which indeed allows you to simply do 'hg ci', without
> mentioning files).

I like this explanation with it's focus on units-of-work. I will just
like to add that you can "help" Mercurial by splitting your bigger
repository up into smaller pieces. With a big repository you would do

  cd ~/scripts
  hg commit -m "Fixed bug." perl/foo.pl
  hg commit -m "Optimized." shell/bar.sh

and so on, that is, naming the files on the command line when you have
modified more than one file at a time. If you had instead made a
"perl" repository and a "shell" repository, then you can in a
meaningful way just let Mercurial commit it all:

  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.

-- 
Martin Geisler


More information about the Mercurial mailing list