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

AW: AW: Re: Simple Label=RevisionID Discussion

From: Felix Gilcher <gilcher_at_exozet.com>
Date: 2006-11-22 18:58:22 CET

Tim Hill <mailto:drtimhill@comcast.net> schrieb am Mittwoch, 22. November 2006 18:37:

> Felix,
>
> I cannot talk for others, but my intention has _never_ been to
> replace tags with labels, for the very reasons you state.

I guessed that.

> However,
> you are talking about _your_ usage model for subversion.

Hey, The ASF repository is not *my* usage model, just a convienient example of an extreme case. However, this model does exist, is acknowledged as a possible solution and any label solution being discussed IMHO *must not* introduce any problems for those usage models.

> There are
> many, many installs where Subversion is used as little more than a
> historical time-machine for a simple, linear, development cycle. In
> these simple scenarios there is _NO_ "path" co-ordinate to manage,
> since there are no branches at all: everything happens on the trunk
> (yes, really!).

I know, I do have those projects as well (we're doing some quite simple websites sometimes and they don't need a complicated development workflow). However, tagging from the trunk works nicely for those once you get used to it (this is at least my experience). You're not likely to get a large number of revisions for those projects either, so you could get away with revision properties or placing a "stable_revisions.csv" somewhere in the root folder. Write a wrapper that handles the file or properties and you're done.

>
> This comes back to my basic argument: _Simple_ uses of subversion
> need a _simple_ way to symbolically track the timeline. Tags are not
> simple. Hence labels. Simple labels are not suitable for non-linear
> (read: anything except simple) dev cycles, and for that we have tags.
>

I hope you can see as clear as I do that people are trying to evolve your "PML" into a full blown secondary tagging mechanism. What I like about svn is that there is a simple way of doing things, creating a tag. It's really dead simple, I make a copy, just as I used to do back when noone was talking about revision control: place a backup somewhere. Creating a secondary tagging mechanism makes the whole thing go from sleek and efficient to bloated and overburdened. I agree that some workflows can be streamlined and that some paradigms are sometimes awkward for small scale projects but I really prefer it over ambigious behaviour and tons of options, multiple ways of doing things.

I understand that your intention is to make things better and simpler, but often the worst things stem from purely good intentions. I'd rather prefer to map the simpler workflows we both want to the "regular" workflows and hide that fact from the user. The tortoiseSVN "tag" command is just this example. It does offer a nice interface to tagging and in the background creates a copy.

> --Tim
>
>

regards

felix

-- 
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 22 18:59:18 2006

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