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

Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision Aliases)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-03-17 17:47:44 CET

On Wed, 2004-03-17 at 06:53, TBrowder wrote:
[About SVNROOT]
> Allows an administrator an easy way to point to the repository.
> Allows users a default location (svn URL) for their primary
> repository. I'm not a touch typist and use aliases a lot. I can
> easily switch repositories with a two- or three-character alias (under
> tcsh).

Similarly, though, can't you just set two- or three-character shell
variables for the repositories you use frequently, and then do "svn co
$rep/pathname dirname"?

I don't think that approach works so well under Windows, but neither do
your shell aliases.

> .cvsignore
>
> I've tried the method described in the book and (1) it didn't
> work and (2) I don't agree with it.

.cvsignore maps very closely onto the svn:ignores property; I don't see
any reason why we would want two ways of doing the same thing.

> rtag (and the command 'cvs history -T')
>
> Allows a quick glance at milestones of a project without
> cluttering up the repository tree with changeable tags. Not
> changeable by the user. Output of 'cvs history -T' is guaranteed to
> be in reverse chronological order.

What makes you think that CVS tags are not changeable by the user? As
far as I know, there's nothing stopping a CVS user from moving a tag.

SVN's decision to make branches and tags part of the visible tree has
both positive and negative consequences, most of which aren't terribly
important. Polluting the design by adding a second kind of tag would
let users choose which set of positives and negatives they want, but
only at the expense of making Subversion a more complicated and
harder-to-learn system. I think we should try to remain simple unless
we discover strong evidence that we made the wrong call.

(Pros of SVN tags: the creation of a tag is a versioned event; you can
manage the set of visible tags without permanently destroying
information; a single concept covers copies, branching, and tag
operations. Cons of SVN tags: you can't get a comprehensive list of all
the tags ever created without a complicated query; they create a
multiplying effect if people check out the root of your tree; an extra
mechanism is required to prevent users from editing the contents of a
tag; folding copying and branching into a single concept may lose
information.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 17:48:04 2004

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

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