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