[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: I miss tags

From: Brad Appleton <brad_at_bradapp.net>
Date: 2004-09-27 19:04:46 CEST

On Mon, Sep 27, 2004 at 09:38:20AM -0400, Scott Palmer wrote:
> I for one think there is room for improvement on the
> current cheap-copy tag system. Though I see that is it
> powerful as is. The example brought up about not seeing
> where things were tagged when viewing a log of the trunk
> is good. I think the alias idea would make it easier
> to deal with specific tagging issues that seem to fit
> awkwardly into the current system.
>
> For example end users need to come up with fancy
> repository layouts to make the 'tags' branch manageable.
> You can have tags of the trunk, tags of branches, tags
> of branches of branches, etc.. and fitting all those
> tags into another repository tree under 'tags' is not
> an easy thing to keep organized. Having the 'label'
> stuck to the actual branch that it is supposed to be
> 'tagging' seems to have some advantages that the current
> system cannot handle well.

I see three specific requirements, some of which are useful
all by themselves, and some which are necessary together:
(a) The ability to associate names with certain revisions
(b) The ability to view/navigate a set of "important" revisions
(c) The ability to freeze a "copy" (either to prevent further
    development on a branch or to prevent changing the
    configuration associated with a "named" configuration)

The current copy mechanism does a+b together (all-or-nothing).

Some folks want to do (a) *WITHOUT* also doing (b) because
- they don't need a name to be in the "important" set
AND/OR ...
- they want the given name to *always* refer to the desired
  revision, and not some other revision

The ability to do (a) by itself makes (c) unnecessary for
many common cases. It still makes (c) necessary if what
is wanted is to freeze development of a branch of evolution.
But if (a) was needed just to be a more meaningful synonym
for a revision, then "copy" is overkill and they now have
to take additional action (e.g. pre-commit hook) to UNDO
the extra stuff that copy-ing does for them.

Suppose for the moment these were all just attributes
of a revision. Let's say a revision has some internal-ID,
and externally (to the user) it has the following attributes:
* revno -- the currently visible revision number)
* revname -- (optional) name that is an alias/synonym for
     the revno
* copy -- values: Unix-style read+write+execute "flags"
    +r means readable
    +w means writable
    +x means make it "navigable"/viewable in the copy-tree

The existing copy mechanism today assumes a default revname
of <null> and a default revcopy (+r,+w,+x).

Some have a need to set a revname value (and be able
to supply it to the -r option anywhere a revnum could
be used) *and* to set revcopy=(+r,-w,-x) where its
not part of the copy-tree and it can't be "evolved".

Possible problem is what happens if I want to change
the revname of an existing revision? Do I require
the attributes to be versioned along with the contents
so I can somehow see what it was previously named?
What should happen in the copy-tree if I change a
revname? Even if revnames must be unique, should I
be allowed to reuse an old revname (even if its not
currently in use?).

The existing copy mechanism removes many of those
scenarios due in part to its simplicity -- and the
price for not having to deal wit the complexity of
configurable combination of "r,w,x" is that you
only get one combination to choose from, even when
its more than what you need/want.

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
  Software CM Patterns (www.scmpatterns.com)
   Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 27 19:05:19 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.