Re: crm versions in CVS

Johannes Berg <[email protected]> Thu, 27 Mar 2008 14:17:19 +0100
Newsgroups	gmane.mail.spam.crm114
Message-ID	<[email protected]>
Corey,

I think you misunderstood my point. Let me explain.

> > While that is possible, the resulting trees will most likely not be
> > mergeable because at some point some slightly different patch
> > description will creep in.
>  
>   I see two points here:
>   1. under a dvcs, trees diverge over time and become difficult (sometimes 
> impossible) to merge.  This would seem to be a general problem of any 
> distributed system, and also one that is media independent.

Yes, but at least once you have merged you don't have to re-do that
merge again, consider a case where Bill publishes a tree and I start
hacking on it. We then have
           /--------- my version ----------I merge both
his-orig                                   /
          \-------- his continued version /

Once I merge, any decent system will remember that for all future. If,
however, my tree was only equivalent on a tree basis and didn't have
equivalent tree/commit IDs as well, then it would be unable to remember
that. This is rather likely to happen when we both work only based on
patches.

>   2. Slightly different patch descriptions cause problems under git.  I've not 
> used git in a multi-person setting, and am not terribly familiar with its 
> quirks.  So I really don't know what this means.

>   As to problem #2, doesn't this just mean that a naming convention for 
> patches needs to be proposed and enforced which makes the names be unique?

The problem is that in git, commit IDs are based on the commit
description. So if you, say commit a patch with the description
"fix hyperspace\r\n" it will get one ID, while if I commit it after
line-conversion "fix hyperspace\n" it will get another ID and the system
will be unable to tell automatically that the same patch got committed.
This problem is resolved if I simply pull in the patch from Bill, then I
get binary identically object.

>   Would these issues be mitigated (or even resolved) if every release also had 
> a tarball of the git repository from whence it came, on which developers were 
> expected to rebase their local repositories?

I'm not sure, and rebasing isn't necessarily a good idea. What could
work would be to publish the ".git" directory so you can rebase on the
actual git tree rather than just the source tree.

johannes

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
Crm114-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crm114-general
signature.asc (application/pgp-signature, 828 B)