> > It's arbitrary. Whoever gets there first gets 1.3. Since we don't
> > distinguish between copies and references (since the distinction is
> > meaningless in the absence of hard links), it doesn't matter.
> So there's really no distinction between descendents of a
> node-revision, even though one of them looks primary and the rest look
> secondary. Okay. (I can't come up with any reasonable numbering
> system which avoids this artificial distinction, so I guess we just
> live with that foible.)
That's about the way I feel about it, too. I wanted to avoid those
hairy RCS-style numbers, but it ended up being the easiest way out.
> > svn log takes a revision and filename, and finds a node number.
> > Then it walks backward from that node number. Walking backward from
> > a node ID is unambiguous.
> That's an interesting departure from CVS, whose log command shows
> information about branches, as well as information about the future of
> the file you're looking at. But I'm certainly willing to try it out
> and see how many people complain.
I've found CVS's behavior annoying. Red Hat's GNU toolchain
repository has 232 branches, which are almost all irrelevant to what
you want, since all but one don't apply to the text at hand.
What the behavior I've described above lets you say is, "What is the
history of *this* piece of text?" Which, at least for me, is the
question I'd rather be asking.
Received on Sat Oct 21 14:36:16 2006