Phyrefly [mailto:phyrefly.phyre@gmail.com] wrote:
> I agree, tags provide all the needed features, but they're far too
> complex (and expensive in terms of ease-of-use if nothing else) to be
> used as labels. I would like to be able to label my repo at the point
> I do a release, but I have no intention of treating it as a branch,
> just a convenient way of getting that code back.
The 'label' use cases you identify there can easily be achieved by tags;
perhaps the roadblock is more of a mental one than functional one. Why
don't you:
> svn ls
branches/
tags/
trunk/
labels/
release_1_product_A/
release_1_product_B_go_live/
Granted, I personally don't see why you wouldn't want to use tags here,
but I can accept the fact that there's a large group of
non-svn-developers for which a tag will never feel like a label. You
could lock the labels/ dir such that it can only be modified by a
certain account (I lock tags/ with a 'releasemgr' account even if it's
just me using the repo; that way I know I'll never be able to commit
things accidentally to tagged branches. Same could apply with labels.)
> It should be possible to create "complex labels" (the label
> "release_1" is rev 1 of Dir A, but rev 2 of Dir B (as rev 2 contained
> a bugfix in Dir B, and the start of work on release_2 in Dir A). Dir
> C might not be labeled at all at this point, as it's unnecessary in
> release 1.
I think this is a pretty common requirement, at least it is for us. We
approach it by having another top level svn dir called 'views'; the
contents of which are simply empty directories with svn:externals set,
e.g.
> svn ls
branches/
tags/
httpd-2.0.48.1/
httpd-2.2.3.1/
httpd-2.2.4.1/
perl-5.8.4.1/
perl-5.8.8.1/
myproduct-bar-1.0/
myproduct-bar-1.1/
mytool-foo-2.1/
mytool-foo-2.2/
trunk/
views/
2.0.x/
2.0.x-trent-dev/
latest_release/
> svn proplist -v views/latest_release
svn:externals:
common/perl https://svn.mycompany.com/repo/tags/perl-5.8.8.1
common/httpd https://svn.mycompany.com/repo/tags/httpd-2.0.48.1
products/foo https://svn.mycompany.com/repo/tags/myproduct-bar-1.0
tools/bar https://svn.mycompany.com/repo/tags/mytool-foo-2.1
This way, developers/users check out views and don't really need to know
anything about tags/branches/labels.
> There's a lot less difficulty there for my end users (I am the only
> real techy in my dept, but there are lots of HTML scripters that need
> to be able to get old (stable) versions of products for new clients).
> It also means I can keep a label for latest_release, and just move it
> when I'm ready, and they don't have to change their steps at all.
If you used an approach like the one above, you'd have a view called
'latest_release' that's composed of the relevant svn paths, then get
your HTML scripters to check out that particular view.
When you want to move the 'latest_release' on, just edit the
svn:externals for that particular folder. This'll be automatically
picked up when your users do svn update.
We rely on this approach heavily to 'compose' our working copies of all
the relevant tags/branches of the underlying components and it works
like an absolute charm.
Trent.
--
http://www.onresolve.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 15:15:58 2006