> I really don't want to open this debate again. :-) Here's a quick
> summary.
>
> The general feeling among subversion developers is that the 'label'
> technique of tagging (the way CVS does it) is an inferior strategy for
> tagging, because there's no accountability. In the model you propose
> (as well as in CVS) there's no record of anyone creating a label, nor
> is there any record of someone changing the label or deleting it. In
> the subversion defnition of "tag" (a cheap directory copy), the act of
> tagging is an historical event, recorded forever in the history. If
> someone deletes or accidentally changes the tag, that's recorded as a
> commit as well. A label/revpropsimply doesn't provide any of this
> sort of tracking.
You were right. I gather from the emails in this thread that we should
build upon the current Subversion-like tags. And I believe we could agree
on the following 4 principles:
1. A better tagging system must be based on the current Subversion-like tags.
2. We should include branches and 'projects' into the discussion.
3. Clients should be able to locate and identify 'projects', branches and
tags. The need for this is exemplified by Subclipse.
4. The Subversion commands and libraries should be extended to maintain
and use the meta-information provided by (3). This will finally enable us
to simplify typical Use Cases, like tagging the trunk.
Based on these, I have the following ideas:
PROJECTS
A 'Project' directory contains properties for the location of the 'trunk',
'branches' and 'tags' directories. The following properties should be
specified for a Project directory:
1.1. "svn:project"*
1.2. "svn:tags-location", with a value of e.g. "/svn/tags@456"
1.3. "svn:branches-location" with a value of e.g. "/svn/branches@678"
1.4. "svn:trunk-location" with a value of e.g. "/svn/trunk@234"
*) The property "svn:project" defines a Project directory. The value of it
could be a description of the project, copyright information, contact
information, ...
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.
In addition, each tag directory should have a property
"svn:project-location", e.g. with value "/svn@123".
BRANCHES
All branch directories below the "svn:branches-location" directory should
have a property "svn:branch", e.g. with the value "/svn/trunk@1567" for
the source of the branch.
The "svn:trunk-location" directory should have a "svn:trunk" property,
similar to the "svn:branch" property, but the value of "svn:trunk" will
usually be empty.
In addition, each tag directory should have a property
"svn:project-location", e.g. with value "/svn@123".
RESOLUTION OF REFERENCES
Say I want to find the 'diff' between the tag 'version-1.0' and the
current working directory. The following shows how 'version-1.0' could be
resolved to a URL:
1. "version-1.0" is recognised as a tag.
2. Walk up the local directory tree until I find a "svn:tag-location".
3. The value of that property identifies the 'tags' directory.
4. However, that directory may be located elsewhere in HEAD, so I find
(somehow) the current location of the 'tags' directory.**
5. To the current tags location, I append "/version-1.0".
**) Is this operation fast?
EXTENDING THE COMMANDS
We need to provide commands that will use and support these properties.
There are some options:
1. Make new commands, e.g. 'svn tag'.
2. Extend the syntax for TARGETs, e.g. "@version-1.0" or
"tag://version-1.0" could expand to
"http://svn.collab.net/repos/svn/tags/version-1.0" based on the Project's
"svn:tags-location".
3. Extend the current commands with more options, e.g. the option '-t'
could mean the second argument to 'cp' should be interpreted relative to
the tag container directory. So a command could look like "svn cp -t .
version-1.0".
(2) is probably sufficient, but (1) is more flexible.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 8 18:48:30 2006