> hakon@ion.no wrote:
>> TAGS
>>
>> All tag directories below the Project's "svn:tags-location" directory
>> should have a property "svn:tag", with a value of e.g. "/svn/trunk@1452"
>> of the source of the tag.
>
> This doesn't work. A tag is just a branch you haven't committed to yet.
> I have, on rare occasions, copied trunk/ to tags/foo/, and then merged
> a followup commit from trunk/ to tags/foo/ instead of laying down a new
> tag.
>
> "Sliding" tags in this way is an operation that other systems, including
> CVS, support.
The "svn:tag" property serves two purposes.
1. Its presence signals that the directory is a tag. This is unaltered by
your example.
2. Its value should indicate what the tag has tagged. This is affected by
your example.
Let me elaborate on 2).
Tags may be divided into two types, either A) it may be represented by
'path@revision', or B) it must (generally) be represented by the full tag
directory tree. (See the "Tags: What is a tag?" thread for more
information on the two cases A) and B).) Now corresponding to these two
cases:
A) Either you are updating the tag to represent e.g. "/svn/trunk@1454",
and if so the "tag:svn" should be updated with that value. This has to be
done implicitly by the command that is updating the tag. This does not
cover the 'merge' case you described.
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.
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.
> Also, what happens to these properties if directories are moved around?
>
> svn mkdir trunk tags branches
> svn commit -m 'Create normal infrastructure'
>
> ... time passes. Commits happen under trunk/, trunk/ is copied under
> tags/ multiple times ...
>
> And now the repo needs to support a second project. So the committer
> does:
>
> svn mkdir project1
> svn commit -m 'Place for project1 to live'
> svn move trunk project1
> svn move tags project1
> svn move branches project1
> svn commit -m 'Move project1 files under project1'
> svn mkdir project2
> svn mkdir project2/trunk project2/tags project2/branches
>
> What happens to these properties under this sort of move?
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.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 9 20:53:21 2006