On 11/20/2006 9:52 AM, Phyrefly wrote:
> Nobody's saying that branching should be removed, just that a simpler
> function-set is needed for simpler purposes.
>
> If you need to fix a bug from a prior revision, that is when branching
> is needed, it shouldn't be needed when all you want to do is identify
> a release-point. If you label, rather than tag, to identify a stable
> build, then identifying that point is easy at any point in the future.
> And should you need to branch from it, that function is easy too.
I'm not sure how much you want to put in a label, but if it's just a
shorthand for a revision number (i.e. label "release1.5" stands for
12345), what you say above just plain won't work.
For example: You create the label as above, then continue work on the
trunk in preparation for version 2. A user finds a bug, so at that
point you create a branch from trunk -r"release1.5", and fix the bug,
releasing it as something you want to call "release1.6". But that's not
enough! If "release1.6" just contains the revision number (54321 at this
point), it won't tell you that it's not from the trunk, it's from the
branch.
You should have branched at the time you decided you would fix bugs on
the release. Then you should tag each release by copying it somewhere,
so you can find releases in a known place.
>
> The proposed solution of a copied-to property makes identifying the
> revision you need to look at easy, but it still means having to look
> (quickly) through the rev history to find the rev number with that
> property, and then plug that rev number into other svn commands.
>
> The main advantage of labelling (for basic users) in other source
> control apps is the ability to plug a label name into svn commands
> instead of rev #s. Tagging doesn't allow that, and tweaking the
> tagging functionality, while making the alternative workflows easier,
> doesn't completely solve this.
Tagging is exactly equivalent: but instead of plugging a rev number in,
you plug a URL in. Since in the general case it is *impossible* to
update to a particular release (e.g. you can't update trunk to
"release1.6" in the example above), you have to switch to it, and you
might as be consistent and *always* use the same way to switch to a
particular release.
Duncan Murdoch
>
> On 20/11/06, Tony Harverson <tony.harverson@iglu.com> wrote:
>> Hi there Robert,
>>
>> > -----Original Message-----
>> > From: Robert Graf-Waczenski [mailto:rgw@lsoft.com]
>> >
>>
>> When we were discussing this on the Complex tags issue, I did say that I think the problem here is not with the lack of labels , but that it's hard to see at a glance how a file's history has branched in the past. I believe the solution to this may be a "Copied To" history entry in subversion, so that one can look at the history of foo.c and see:
>>
>> ...
>> 13795 - Copied to tags/2.0.0/
>> ...
>> ...
>> 17985 - copied to tags/2.1.0/
>> ...
>> ...
>> ...
>> 19000 - copied to tags/2.2.1/
>> ...
>>
>> etc.
>>
>>
>>
>> > For this, a very simple concept of a label would suffice:
>> > A text that can be associated with a revision number.
>> > This text must be *independent* of the commit message that
>> > was supplied by the committer of the change that created the
>> > given revision number. It is as simple as sticking a post-it
>> > to the correct sheet in a huge pile of paper. (Thanks to the
>> > other poster who used this analogy!) And, to stay with this
>> > analogy, removing the post-it and sticking it on a different
>> > paper or writing a different text on it should also be possible.
>>
>> Where then, does one deal with the common problem of the problem of fixing a bug in a file which has major changes on trunk since the release? One doesn't wish to include the new version of the file in a bug fix for an old tag, as it may break binary compatibility, introduce a new bug in concert with an older bar.c, etc. This then begs the question of where we fix the bug.. If the tree has been branched and then tagged, the fix is applied to the branches you're still supporting in the field, and then you're sorted, the branches are retagged with a new tag (or the old one, if you're feeling brave).
>>
>>
>> > I don't want to have to look through all the /tags
>> > subfolders, then lookup the file, then open this file's
>> > history to determine if the offending change is there or not.
>>
>> I recognise this as a problem, I'm just wondering if labels are an appropriate solution.. More branching history (including tagging history) might be the optimal solution for this problem. Unless there's a workflow other people are doing which require the identification but not fixing of a bug, I don't see how the label thing is going to work. Could someone suggest a workflow for the problem of:
>>
>> 1) Identifying a bug in the trunk
>> 2) finding which supported releases currently have the bug
>> 3) Fixing the bug for those releases
>> 4) Testing those releases
>> 5) Re-Releasing those releases
>>
>> Using a labelling rather than tagging? I'd be interested to see where fixes are committed.
>>
>> Tony
>>
>
> ---------------------------------------------------------------------
> 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 Mon Nov 20 16:25:26 2006