Suffering from CVS mindset

Steve Losh steve at stevelosh.com
Sun Apr 11 14:13:48 CDT 2010


On Apr 11, 2010, at 2:43 PM, Harry Putnam 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) 

'hg init foo' will create the directory 'foo' if it doesn't exist.  So 'hg init foo; cd foo' and 'mkdir foo; cd foo; hg init' do exactly the same thing.

Yes, 'hg init foo' is 2 characters more to type (though you could abbreviate it to 'ini' and save one), but that's really not a big deal.

> 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>

It's actually (hg init * 13) vs (mkdir * 13) (see above).

> 
> And so it would be with any other commands wouldn't it?
> 
> That is, instead of hg commit, it would be hg commit * 12.
> 
> 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.

If you make each project a separate repo, you don't commit in every repository when you just change one.

If you make some changes in 'scripts/perl/logparser' then you wouldn't need to commit in 'scripts/python/webscraper'.  You just commit in the 'scripts/perl/logparser' repository.

It's still one command, you just need to run it in the appropriate repository (which you're probably already cd'ed to if you're working on its code and testing your results).

> 
> 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.

Say I'm working on a python project.

* I make a change in foo.py that changes the number of arguments a function takes.
* Then I make a change to bar.py which updates the calls to foo.whatever() to account for those new arguments.

Those two changes belong together.  Making either change alone would break the project.  Keeping track of the changes in the entire repo means that related changes like these can be grouped together.

There's no chance of someone pulling just one of the changesets and only getting half the updates (leaving their copy broken).  The changeset can also be looked over and reviewed *as a whole* by other people.

If you're working alone these aren't huge benefits, but the moment you want to share them with someone else (or have to figure out why you changed line X of file foo after a few weeks have passed).

Making sure every commit results in a working (or at least *running*) version of your project also makes bisecting bugs far easier (see 'hg help bisect') because you won't have to skip lots of changesets.

> 
> 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 have 50 different, self-contained files that *never* rely on each other then no, there's not much extra benefit.  But what happens when files start to rely on each other?

Maybe you add a README file for one of the scripts.  Now the script and the README should be kept track of together.  If you update the command line arguments the script takes you'll need to update the README to explain them.

Keeping track of individual files means there's no way to group the "update script X to take a new argument" and "update the README to mention the new argument" together in a single unit.

It also means that if you want to share your 'scripts/perl/logparser' script with someone (or make it open-source) it's simply a matter of putting the 'scripts/perl/logparser' repository online so people can clone it.

If you keep everything together then you have to either put *everything* online (but you might not want to share everything), or just post the file somewhere without its history, or use some 'hg convert' magic to pull it out of that repo into its own.

> 
> 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. 
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial



More information about the Mercurial mailing list