On Wed, 05 Oct 2005 19:00:59 +0200, Matthias Wächter
> I think that's due to one of the most severe misconceptions of SVN, not
> distinguishing a tag (should be: bidirectional link/copy read-only) from
> a branch (should be: bidirectional link/copy read-write) from a copy
> (unidirectional copy). Not to mention that revision numbers must be used
> as part of a tag to be really precise. Related to this issue is the
> exclusion of tag/branch/copy operation from the "svn:external" property
> Of course it eases development of SVN and allows a lot of 'new' concepts
> within a project not possible with CVS. But handling tags/branches the
> way I described would require an adaption of the subversion client, the
> server as well as the database backend structure which means currently
> the VC system can't handle it correctly out-of-the-box.
Thanks for your explanation, I didn't like it this concept in SVN either
but I thought it was only me. What's also frustrating in this is that
I still haven't found anything which wouldn't be possible if bidirectional
links were implemented. Even notes/schema-tradeoffs.txt suggests that
these were possible, and doesn't say anything which would justify the
lack of bidirectional links.
The only thing I found in this file which tries to justify this concept is:
Organizations tend to create branches and tags quite
frequently -- much more frequently than asking the question "which
tags contain a specific file?"
But according to my experience in some organizations developers ask that
question 10-100 times more frequently than creating tags or branches. Sure
this may not be true for open source projects but in my case I often
have to look if a bug was fixed in version x and a feature was implented
in version y in our software, which would be very time consuming in SVN.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Oct 6 08:05:55 2005