John Calcote schrieb:
> Stuart Celarier wrote:
>> John, I think you've overlooked some use cases for tags. Here are three
>> to consider.
>>
> I've seen a lot of comments on additional use cases for tags. It seems
> most of them can be summarized in the following three use cases:
>
> 1. Tags as pure symbolic revisions (snapshot in time)
> 2. Tags as proper subsets of files within a revision (a snapshot in
> time and space)
> 3. Tags as subsets of files with mixed revisions (a snapshot of a
> corrupt work area)
Don't forget that you should be able to tag a tag of a tag and end up
with the same set of files (and revision numbers!) that you had before
the tag.
In SVN it is annoying that I run "svnversion" and read "300", after
tagging the directory (and updating to the tag) the same command returns
"315". If I tag the same directory again after three years, "svnversion"
returns 4012 or such.
A solution to all that would be an automated "walk back" feature for
co/up/cp/export/sw/lock/unlock as brainstormed in
http://svn.haxx.se/dev/archive-2006-02/1609.shtml
Simon appears to have something similar in mind:
Simon Large schrieb:
> The one small gripe I have about tags is that you can look back from the
> tag to see where it was copied from, but you cannot look forward from an
> item to see at which point a copy was taken.
> That is not a complete solution either, because if I created the tag
> from a mixed revision WC, or from a non-HEAD repository revision, the
> tag revision bears no relation to the revisions of the items being
tagged.
I disagree. If I tagged from a mixed revision, so I get a mixed revision
after de-referencing the tag. If I tagged a locally-modified revision, I
get a locally-modified revision after de-referencing the tag (the tag
minus the merge for it).
My solution may miss the "first class" feature property of tagging since
one would use "svn cp" and the long tag directory URL again, but the
result would be perfectly matching the above-mentioned three use cases.
John Calcote schrieb:
> BTW, I used the term "corrupt" in point 3 above loosely to mean a work
> area that cannot be recreated with any automated operation provided by
> the version control system. Human intervention is required to ensure
> that all files exist in the work area at the desired revision.
Isn't this an option "-f" for update/checkout etc.? Per default, only
the tagged files will be used, newer or older files are ignored.
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 23:59:11 2006