RE: RE: Is label support in future release?

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
Received on Mon Nov 20 15:35:35 2006