In this case, you are much better off using tags and the existing
features. The big push-back in the past on labels has been that they
end up being used as a poor-mans branching system in just the way you
described, and in this case I do agree with the detractors -- this is
a bad use of labels.
--Tim
On Nov 15, 2006, at 4:25 AM, Phyrefly wrote:
> I've just caught up with this thread, and there's one thing I'd
> like to add...
>
> 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.
>
> 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 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).
> 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.
> Getting them familiar enough with the way SVN works to use tag folders
> or branches is just not an option.
>
> On 15/11/06, Dmitri Colebatch <dim@colebatch.com> wrote:
>> On 11/15/06, Nikki Locke <info@trumphurst.com> wrote:
>> > Tim Hill wrote:
>> > > The main issue, as I see it, is that many
>> > > svn workflows involve operations between different revisions in a
>> > > repository, but that there is no real syntax for accessing those
>> > > revisions symbolically.
>> >
>> > Can you give some examples of such operations?
>> >
>> > I'm relatively new to Subversion, and I'm having trouble
>> understanding
>> > exactly what you would want to do that can't be done with tags.
>>
>> We've recently migrated from cvs to svn and the single biggest
>> thing I'm
>> struggling with is the following scenario:
>>
>> I get a bug report from the field, or I want to pre-emptively
>> check to see
>> if a particular fix made it into a release (releases might be in
>> QA for
>> weeks before going out to production). In cvs, I would know that
>> the tag in
>> QA/production is "tag_20061115a". Using IntelliJ I would then
>> view history
>> of that file and I can scan down the history to see which version
>> has that
>> tag.
>>
>> I'm yet to figure out a nice way to do the same thing using svn.
>> I've had a
>> couple of pointers in response to an earlier enquiry but haven't
>> really
>> found anything that is as simple as the above.
>>
>> cheers
>> dim
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 18:34:13 2006