RE: RE: Is label support in future release?
From: Tony Harverson <tony.harverson_at_iglu.com>
Date: 2006-11-20 15:29:08 CET
Hi there Robert,
> -----Original Message-----
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:
> For this, a very simple concept of a label would suffice:
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
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
Using a labelling rather than tagging? I'd be interested to see where fixes are committed.
This is an archived mail posted to the Subversion Users mailing list.