Re: Is label support in future release?

Phyrefly wrote:
> 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. Then all SVN commands using a rev number could be fed a
> label instead, and would be a LOT simpler to use.

As I understand it, you can do this by copying rev 1 if DirA and rev 2 or DirB to
a single tag.

> One step further still, If I then found a bug in file X, I could
> branch it at label release_one, fix the bug, re-label the branch file
> as release_1, unlabel the trunk file, and merge the fix back into the
> HEAD.

Now you have lost information. If you have a bug in the field with release_one,
you no longer know what source was used to compile it - the original release_one,
or the new one. Even if you are fairly sure it was the original release_on, you
no longer know what sources were used to compile it, as the release_one label now
referes to a different set of sources.

> Now an export of "release_one" pulls rev 1 for one folder, rev 2 for
> another, ignores a third, and gets me a branched file for file X. All
> ready for release. Clearly any file should only be able to hold a
> specific lable at one revision (including branches).
>
> 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).

I can't see the problem with tagging the sources needed to build each release
when it is released with a unique tag, and using that unique tag to get back
those sources when required.

> 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.

I can't see the problem with having a latest_release branch, and getting them to
always use the HEAD of that branch for release.

However, as a newbie to SVN, I'm agog to hear what the difficulty is.

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org