> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Tuesday, September 08, 2009 11:23 PM
> To: David Weintraub
> Cc: Georges Martinez-Valentin; users_at_subversion.tigris.org
> Subject: Re: Svn hooks pre-commit - How, for tag operation, check than
user
> make the tag operation in tags directory
>
[snip]
> OK, you've explained how it works and what it can do. But what
advantage
> would maintaining a separate list of paths_at_revisions with a label on
it
> really give us, when our goal is to make tags, as they exist in
Subversion
> today, read-only?
Is that the goal? I understand branches, but I'm not sure tags need to
work in the same way. Making a read-only branch is not necessarily the
solution that everyone wants.
Where I am, we release very often, so I would have a repo chock-full of
tags, if we used them. As it is, we use the 'revision number' approach
and get old versions out based on their history. It's a more manual
task, but we don't usually need to get older versions very often.
This is where I think the revision number tag is a better solution...
and in fact, I would like to consider both the branch-based and the
revision-based tags as part of subversion. Perhaps if we called
branch-based as tags, and revision-based as 'labels', it might help?
> > However, I'd take straight revision aliases if that would help.
>
> You've said so earlier, but I thought we had determined that straight
> revision aliases don't buy us much because you also need to specify
> which paths in the versioned tree you want this label to apply to.
You don't need paths if your labels were unique. It might be too much of
a restriction for some people though. However, if your label included
some part of the path to make it unique, that would be just fine. I
guess if people have multiple projects in their repository and want to
release them all with labels like 'Release 1', then that is not going to
work, but 'projectA Release 1', 'projectB Release 1' are perfectly ok.
I don't see the problem with prepending a path to the label text either,
isn't this what would happen anyway, and it wouldn't be too troublesome
if it was used to uniquely specify which label you wanted - you don't
need to type out the whole path, just enough to make it unique.
Eg. You have 2 projects, A and B and you insist on labelling them both
"Release 1". Svn stores 'Release1' as the label text, but also stores
'/projectA' or '/projectB' in there as well. When a user tries to "svn
co -rRelease1", it will fail as it cannot tell which label was intended,
so we need to use "svn co -rProjectA/Release1" instead. So we store the
label as the full path+label text, and then specify as much of it (from
the right) as is needed to determine a unique label. (eg.
/root/trunk/projectA/ gets labelled with 'Release1' even though there is
already a Release1 used for project. Now the only part needed to
determine which 'Release1' you meant would be to work backwards through
the path and use ProjectA part of it, not the whole path, which gives us
the means to have unique labels without much hassle on the part of the
user).
The benefit of using labels like this is that branch-based tags can
still be used, and that the mechanism for retrieving the labelled
versions nearly already exists, you just need a lookup of name to
revision.
Maybe I'm missing something, but this appears to be very easy to
implement, and very easy to understand, and because the labels would be
stored in a separate section, it would be fast to search through them -
they'd be like an index to the repository.
If the topic is back on discussion, I'll have to have a long think about
it now. The above are my initial thoughts. Cheers guys.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392815
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-09 11:53:02 CEST