hakon@ion.no wrote:
> B) Or, the tag tree is not so simple, exemplified by your 'merge' example,
> and then the value of "svn:tag" is not well-defined. This change to the
> value of "svn:tag" has to be done implicitly by the command that is
> updating the tag.
>
> Is case B) a problem for my suggestions? No, because it is a fact of the
> nature of Subversion-like tags; You cannot generally represent the tag as
> a simple string in case B), while in case A) it is just path@revision.
>
> So in any case, the value of "svn:tag" is _informational_. But if it is
> given, then a client may use that to, say, draw a graph of the history of
> 'trunk' and its tags.
From what I understand 'svn:tag' points to the directory it was copied
from. Am I correct?
Can't we work with the copy-from-path that is already stored when we're
creating a copy? I'm not such a fan of introducing a new tag, unless I
really know we can't solve it any other way.
Also I don't know if it is wise to separate tags and branches... As Nik
already pointed out, they're essentially the same thing (at least it is
the same way in the understanding of subversion).
I think it's kind of powerful that Subversion sees only a copy and we
see a tag or branch because of the directory structure built around it.
(This also makes it more tricky of course :P)
> Note that if you merge changes onto a tag, then no Subversion client will
> be able to plot such a history graph for 'trunk'. It must have some
> meta-information that binds a tag to a revision of trunk.
>
> It was designed for allowing refactoring.
>
> 1. Properties follow its directory in the 'move'.
>
> 2. The property value, e.g. "/trunk@45", will also be safe. It just says
> that at revision 45, the directory had path "/trunk". The problem reduces
> to finding out whether "/project1/trunk@100" is a child of "/trunk@45".
> There might be more to this, but I hope it is doable as many commands
> already separate between 'peg' revisions and 'operational' revisions.
I don't think you should count on peg revisions too much in this phase.
(Just my thoughts)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 12:35:15 2006