> -----Original Message----- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: Tuesday, May 21, 2013 2:32 PM > To: users@subversion.apache.org > Subject: Re: Subversion Doesn't Have Branches aka Crossing the Streams > aka Branches as First Class Objects? > > On 21.05.2013 20:26, Branko Čibej wrote: > > > > You cannot identify a directory (or branch or tag) just by its > > basename, only the whole path is a unique identifier (within the > repository).
Yes, I understand why it happens and why it needs to happen. > Just to be clear -- I agree that the the result of 'svn log --stop-on- > copy' changes is confusing. And, as I said (much) earlier in this > thread, that's an unfortunate side effect of how renames are currently > implemented. Personally I've always viewed the --stop-on-copy as a > hack, and we really should invent a better way of identifying branch > points. > I don't think true renames will necessarily fix the problem. Conceptually, the problem is that the parent dir components of a branch/tag are superfluous, e.g. given "svn://server/repo/path/to/project1/branches/1.0", the "svn://server/repo/path/to" and "branches" path components are useless/meaningless to the average user. However, these superfluous dir components are visible to the client, which means they're accessible by, and thus modifiable by the client. Which makes them superfluous *and* dangerous. The client should only see and work with "--project project1 --branch 1.0", e.g. "svn co --project project1 --branch 1.0" to checkout a branch. It's about presentation. Keep the superfluous dir components internal and hidden from the average user. We've already seen a move towards information hiding with the'^' syntax that hides the server component. This would be the logical progression. Anyway, I'm nearly done with implementing my "find common ancestor" script that seems resistant to edge conditions, so I'll stop rambling.
