On Tue, Sep 08, 2009 at 03:47:15PM -0400, David Weintraub wrote:
> 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.)
You need to copy the file twice to get it tagged twice in the current
model. I see no realistic way to change that. Subversion is all about
the 3d-versioned-filesystem tree.
> 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.
Subversion has no individual file revisions.
> 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.
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?
In Subversion, a set of paths can be obtained by copying things
to some place in the versioned tree. This means that we do not need
to maintain lists of paths externally. The paths are in the versioned
tree already, we don't need a separate represention for them.
I'm not saying this is very great or very bad, just that it's part of
the basic idea of the model Subversion is using. Changing assumptions
about the basic model just to get tags read-only makes it very hard
to get a working solution.
> 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.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2392684
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-09 00:24:47 CEST