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