-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Something tells me that a short time from now, I may wish I
had remained a lurker...but here goes anyway.
It would appear to me, who originally came to version control
via CVS, but now have experience with Subversion, and some of
the large commercial systems including ChangeMan DS, Perforce,
PVCS and Dimensions, that the VAST majority of people who want
CVS style labels have a few issues with copies:
1) Writability. Granted, hook scripts can fix this. However,
I would agree with those who suggest that tags should be
more difficult (but not impossible!) to modify out of box.
The simple truth of the matter is this: If you check out a
tag, forget that it's a tag, make a change and commit, you
have just changed a tag, and may not even know it! At least
in CVS, you have to use -f.
2) Lack of a direct way to see the result of copies when
issuing commands (log) against the original file! I think
this is an inarguably useful thing to expect from a version
control system.
3) A basic misunderstanding that somehow, someway, regardless
of what everyone keeps telling them, copies at NOT cheap.
Notice repeated usage in this thread of derogatory words
such as overkill, and suggestions that it is somehow
wasteful, or more than you want or need, to make copies.
My guess here is that people are more used to checking
out at the root of the repository, and updating from
there as well. With Subversion, if you checkout the root,
updates from the root are painful after a tagging or
branching operation, and I would guess that this is what
gives cheap repository copies the appearance of expense.
Due to this, I've recently converted all local copies of
my SVN repository to checkouts of the root/trunk and now
use "svn ls" to discover the tags and branches.
One of the main disadvantages of tags in the traditional
sense is the lack of a hierarchical namespace. Subversion
provides, via user defined directory structures, highly
flexible namespace creation as many others have pointed
out. This is a *good* thing, IMHO, but it *does* have
issues with respect to general usability of Subversion
as a standard tool, particularly if each and every
Subversion installation is a horse of a different color
so to speak.
On Sep 27, 2004, at 11:04 AM, Brad Appleton wrote:
> 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
>
- --
- -- Tom Mornini
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBWGRqzaKkuvKwKvcRApBjAKCLg15SORn0SfSZQbFhs0kKSp8fDACfUaVW
XvcGGdR+3j/ReT0syPxuO9s=
=7thv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 27 21:12:28 2004