Re: newbie revision question (Re: I miss tags)

[Raye Raskin <ra...@pobox.com>]

> From: "Jeremy Pereira" <je...@ntlworld.com>
> To: "Subversion Users" <us...@subversion.tigris.org>; "Scott Palmer" <sc...@2connected.org>
> Sent: Monday, September 27, 2004 9:30 AM
> Subject: Re: newbie revision question
> 

> Why is it that people can't see past the tags thing?  Can I remind 
> everybody that tags themselves are a bad hack introduced into CVS 
> because of its poor design i.e. CVS is a tool to manage a collection of 
> standalone files which are each under revision control *separately* 
> rather than a single code tree which is under revision control.
> 
> The underlying function that Josh Howe is asking for is to preserve a 
> copy of his tree as it was at the time of release 1.0.  Leaving aside 
> all considerations of implementation, to me the "copy the tree to a 
> special place calling it revision 1.0" seems the more natural metaphor 
> than the "label a particular revision release 1.0".  At least in this 
> instance, it is tags that are the workaround not svn copy.
> 
> Some people seem to be coming up with ideas like "x is difficult in 
> subversion, but if we had tags, it'd be easy".  This may be true, but 
> the question should be "can we fix x without grafting on extra kludgy 
> UI metaphors?"
> 
> One of the reasons I like subversion so much is it presents me with an 
> elegant simple conceptual model which is actually more powerful than my 
> previous version control system (CVS).  If it were my project, it'd 
> break my heart to have to implement something as nasty as tags.
> 
> NB I don't call my tags directory "tags", I call it "releases" which 
> reflects better what it is for.

I agree that the copy metaphor is elegant, inexpensive, and fast
(though I haven't tried it on a large repository yet, but I take
the word of everyone.)  I think it's a good thing.  Kudos to the
SVN development team.  Thinking back on 90 minute tags of large
repositories makes me appreciate the SVN solution (though a long
lunch isn't bad, either.)

The SVN mission statement (I paraphrase) is to be a better CVS.

To me, the crux of the issue (it's not really a "problem") is in
CVS there are two kinds of tags: branch tags and static tags.
They exist for two fundamentally different purposes.

Yes, it has been properly noted that in CVS you are allowed to
"-F"orcefully move a static tag.

In general:

  Branch tag = a moving target
  Static tag = not a moving target

I'm sure most of us have used the -F option to "cvs tag", and
it surely has its uses.  Clearly, SVN has that mechanism
already built in.  :-)

Personally, I'm not asking for (nasty) tags or labels.

I'd like to see an SVN-built-in way to keep a directory
hierarchy from being committed to.  That's it.  Make it
SVN-read-only.  No external scripts or wrappers should be
required to do this.  There should be a way to override
the read-only decision, a la "cvs tag -F", but you should
have to make a real conscious decision to do so.

Raye.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: newbie revision question (Re: I miss tags)

[Mark Phippard <Ma...@softlanding.com>]

"Raye Raskin" <ra...@pobox.com> wrote on 09/27/2004 01:32:20 PM:

> I'd like to see an SVN-built-in way to keep a directory
> hierarchy from being committed to.  That's it.  Make it
> SVN-read-only.  No external scripts or wrappers should be
> required to do this.  There should be a way to override
> the read-only decision, a la "cvs tag -F", but you should
> have to make a real conscious decision to do so.

You can do it today if you are using Apache repository by using mod_authz. 
 

I do not know the issue number, but Repository-based ACL's are high on the 
to-do list.  It has been tossed around that it might be implemented as 
part of adding the locking feature in SVN 1.2, but I do not know if that 
is still the case.  At least one of the committers believes the two 
features have similar internal API requirements.  So, if nothing else, 
when locking is added, it may pave the way for ACL's to come soon after.

Mark


_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org