Re: Fix branch ancestry calculation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, 24 Mar 2006, David Mansfield wrote:
> 
> Anyway, I'd like to nail down some of the other nagging ancestry/branch point
> problems if possible.

What I considered doing was to just ignore the branch ancestry that cvsps 
gives us, and instead use whatever branch that is closest (ie generates 
the minimal diff). That's really wrong too (the data just _has_ to be in 
CVS somehow), but I just don't know how CVS handles branches, and it's how 
we'd have to do merges if we were to ever support them (since afaik, the 
merge-back information simply doesn't exists in CVS).

I actually went back to read some of the original CVS papers, and realized 
that CVS _without_ branches actually makes perfect sense.

Suddenly it was a perfectly reasonable system: the fact that you can only 
merge once (between working tree and repo) is perfectly reasonable when 
there is only one branch and checking in requires you to have updated 
first. All the things I really hated about CVS just go away if you don't 
do any branches at all.

Of course, it's a much less powerful thing without branches, but what I'm 
getting at is that the whole branch support seems to have been a total 
crock added later on top of something that was never designed for it, and 
where the data-structures aren't even set up for it.

Live and learn. (Of course, maybe I'm wrong, and the thing doesn't make 
sense even without branches).

			Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]