> 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?
Yes.
> 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.
Oh, I see. We could use that value.
But we still need to mark the copy as a 'tag' operation, and not just some
copy operation. And so we need the "svn:tag" property, just not its
value.
Now if we already need to get the property "svn:tag", then we got its
value for free. If we instead use the copy-from-path, then that would take
an extra 'log' call (to the repository)...
> 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)
We should differentiate between what the user would like Subversion to do
(the public interface), and how Subversion implements those features.
A branch is conceptually where the development of the code happens. A tag
saves a snapshot of the development.*
And so one client may want to draw a history of a branch, and plot in its
tags. In the same graph, the client may or may noy want to also plot the
off-shot branches. Or it may want to draw the branches in a different
color, or it may plot them exactly like tags. We must give the client a
chance to do what they like.
A client may want to show tags which have been altered after their
creation in red, to warn the user of a possible 'code attack'. You do not
want that for a branch.
*) The tag is not a snapshot of a branch when the it is a copy of a
working copy tree. But take Subversion as an example; Its tags are very
close to a URL@revision, as so it might still be said to be a snapshot of
a branch.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 23:18:01 2006