What I want to be able to do is this:
$ svn cmd -r<TAG>
Subversion should figure out what to do, and do it quickly.
One of the problems is what happens if a particular revision of a file is in
more than one tag. How does your svn:tag property handle this? Do I have to
create a new version the database to create a tag? (It's one of the things
that happens which I am not found of now.)
Perforce has two ways to create tags. Number one is to create a tag, and
then attach that tag to each and every file revision you want that tag on.
Method #2 is more interesting and probably is more what we want.
In that method, the tag contains a description of the change sets and paths
for those change sets. In Perforce, a change set is equivalent to a
Subversion revision number.
Once you defined the file directory list and the change set revision number,
your files are automatically considered tagged. You can even mix and match
revisions if you like. These records can be locked to prevent them from
being changed. See <
http://perforce.com/perforce/doc.091/manuals/p4guide/06_codemgmt.html#1081816
>.
That would be the ideal system. However, I'd take straight revision aliases
if that would help.
On Tue, Sep 8, 2009 at 1:39 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392626
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-08 21:48:14 CEST