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

Re: Tags

From: Erik Kline <ek_at_google.com>
Date: 2006-07-03 18:50:24 CEST

On 7/3/06, Miha Vitorovic <mvitorovic@nil.si> wrote:
> Danny van Heumen <danny.vanheumen@hccnet.nl> wrote on 03.07.2006 00:41:22:
> > John Peacock wrote:
> > > Mark Phippard wrote:
> > >> 5) As others have pointed out, a single property value cannot easily
> > >> express a complex mixed-revision tag.
> > >
> > > As long as the property value or "tag" is an alias for the actual copy
> to some
> > > tag folder, then this isn't a problem at all. The existing Subversion
> cheap
> > > copy becomes the backend implementation and the tag becomes the user
> friendly
> > > front end...
> > >
> > > John
> > >
> >
> > (This reply isn't aimed at anybody in specific,
> > it's just my view of the problem.)
> >
> > Come on guys... how 'user friendly' can you get?
> > The only thing you need to do now is look for a specific name in a
> > folder called 'tags' (or in case of a branche in the folder 'branches'
> > for that matter).
> > And instead of saying 'check out tag "mytag"' you say 'check out url
> > "http://domain.com/repos/tags/mytag"', or even '/tags/mytag' should be
> > enough. And in case you can't remember that, send yourself an email.
> Hi all,
> I'm just a user / dev-lurker, and I would like to offer my input. I've
> never used any other VCS, so I find the concept of "versioned file system"
> very easy to understand and use. So I don't see a problem with tags as
> folders, but I would quite welcome some tagging/branching that would
> remove the need for long URLs (and if you're doing a server side tag, than
> you usually need two of them - almost identical).
> As a SVN admin (small developer base, not much administration) I would
> find the ability to force some things on the server side quite valuable -
> which would also come in play with some tagging suggestions that are
> currently on the list.
> This current "better tagging" suggestion (if I'm not mistaken) yet again
> asks for symbolic revision numbers, so I guess many Subversion users want
> this quite badly. Why not finally give it them?

I am also a lurker. Just thought I'd chip in.

Because the repository layout is specified by the repo admin(s)
(hurray) tagging and branching are probably best left in a wrapper
layer. Specifically: "svn_wrapper tag ..." and "svn_wrapper branch
..." could parse the repo URLs and reformat them according to your
repo layout. I'm sure no one wants to force /repo/tags/ and
/repo/branches/ on the world, especially when some folks (myself
included) use /repo/project{1,2,3,...}/{trunk,tags,branches}/.

The only other way I can think to make it "generic" would be to have
some sort of "variable" in the repo URL, like
"http://example.com/repo/$TAGS_DIR/dir1/file1.cc" and let the server
(or mod_rewrite?) do the fixup. Note: I'm not a fan of this idea, it
just occurred to me to mention it.

Alternatively I supposed there could be environment variables, like
"SVN_TAGS_DIR" or "SVN_BRANCHES_DIR" that, if set and not empty, could
be used to automatically construct the right repo urls somehow. But
again, this is not obviously a great idea.


> I don't think that SVN tagging should become like CVS tagging (I like SVN
> tagging), but I think it is becoming more and more important that SVN
> developers do SOMETHING to scratch the biggest user itches, and add some
> functionality that would enable people to tag/branch in some other way
> except the current one. I guess some people just can't/don't want to wrap
> their heads around a concept that is different from what they know (and
> such people can be seen on both sides). From what I know about Subversion,
> I think it is flexible enough to be able to offer that (almost anything,
> actually).
> Regards,
> ---
> Miha Vitorovic
> Inženir v tehničnem področju
> Customer Support Engineer
> NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
> Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 3 18:51:22 2006

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.