On Tue, Sep 08, 2009 at 12:28:09PM -0400, David Weintraub wrote:
> But, that is still a stop gap measure. Tags should have been a built in
> concept from the get-go. Occasionally, there is a discussion on this mailing
> list about the lack of true tags. One recommendation is to make tags aliases
> of revisions, so where you use a revision number, you could use a tag to
> represent that revision. You'd need some commands to create these revision
> aliases, more commands to lock them, and even pre-tag/post-tag hooks to
> allow you to define what a tag can and cannot look like.
I don't think that implementing tags as aliases of revisions is a good idea.
You've named some disadvantages of this approach, e.g. a huge implementation
effort. In addition to this, Subversion's concept of a single versioned tree
means that it provides logical boundaries scoped by a path namespace.
You can't simply say "r33728 is v1.0", because you also need a path
pointing to the root of the thing you declare being v1.0 to make sense
of this statement.
Is this thing a release branch? Is it trunk? Is it some submodule of
some subcomponent of the persistence backend of your web application?
So, given this, I think the best we could do this is define a new
property in the svn: propery namespace, that is versioned, just like
svn:mergeinfo, and sits at a path (we could require this path to be a
directory). Let's call it "svn:tag". Since the name is in the "svn:"
namespace any third party client can use this name and be interoperable.
The svn client would set this property as part of the commit transaction
when the user runs 'svn copy --tag', which would have the same effect as
doing a copy and setting the svn:tag property on the copy destination in
a subsequent commit, except that it's done in a single commit transaction.
Upon commit, the server would walk up towards the root of the repository
filesystem and check for the existence of an svn:tag property at any
of the parent directories, in the revision the transaction is based
on (just checking HEAD might be racy). Commits would be aborted if such
a property was found.
What if you want to change a tag? Just remove the property in HEAD,
possibly update your WC, and try again.
It's unlikely that people would remove the property accidentally,
except if removing the entire directory. It would not be as easy
anymore to make mistakes as it is now.
This approach is both backwards-compatible and fairly easy to implement.
People could manually set this property on their tag directories so that
the server could take advantage of it when upgraded, and svn:tag-aware
clients could take advantage of it even if the server does not know about
it yet, by browsing the repository manually.
Initially, the property's value would be undefined, but if the need ever
arises we could add content to it to provide more information.
In addition to this, we could have a similar property to designate
branch boundaries (svn:branch). This would solve the dilemma of having
to create svn:mergeinfo every single time people copy things, just
because the copy could be a branch. Does the copy cross a branch
boundary (an svn:branch property)? If so, create mergeinfo.
If not, don't create mergeinfo, we're doing an intra-branch copy.
svn copy --branch would create an svn:branch property at the
destination.
> If Subversion really didn't have any way to emulate tags, then we might have
> seen some movement, but since we have a sloppy way to handle this, no
> further work is done on it.
Yes. I'll think about enhancing the above into a formal design proposal.
Do you see anything wrong with the approach? I'm afraid that there might
be a serious downside I'm overlooking.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392584
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-08 19:40:53 CEST