Re: [Gnu-arch-users] strategy to handle back-fixies

[John A Meinel]

Andrei A. Voropaev wrote:

> On Fri, Jan 21, 2005 at 01:23:22PM +0100, Harald Meland wrote:
>  
>
> > [Andrei A. Voropaev]
> >
> >    
> >
> > > In fact I was (and still am) wondering how in practice this shall
> > > work. So far no documentation mentions this approach. So below are
> > > my guesses how it should work. Please correct me if I'm
> > > wrong.
> > >      
> > I don't think you're *wrong*, but the solution you propose below is
> > slightly diffuse on some points.
> >
> >    
> >
> > > Suppose I have project foo and it is in
> > > archive/foo--mainline--1.0. So I 'get' this project
> > >      
> > You don't mention what the intention for this branch is.
> >
> > Is it to be used for "development of the project until version 1.0 is
> > ready to be released", or "bugfixes to the project after its 1.0
> > release", or maybe both (a la CVS HEAD)?  Personally, I tend to think
> > of "mainline" branches as having the former semantic, but YMMV.
> >
> > In any case, it is useful to formulate (at least to yourself) a
> > distinct intention for each branch you create.
> >    
>
> Hm. I have to admit you lost me here. Which just shows that I don't have
> clear understanding of branches/revisions naming. Now, with your
> questions in mind I'll try to replay my scenario.
>
> I have source code for project foo-1.0 that I have to maintain from now on.
> So I do "initial import" and name it 'foo--developtment--1.1', to show
> that I'm heading toward release 1.1. After adding few patches I do that
> release. Now I do tla tag foo--development--1.2 to continue with
> developing on 1.2. Now, my boss tells me that we should release 1.1.1
> with some important bug fixes. How should I proceed in this case? Shall
> I do tla tag foo--development--1.1.1?
>
> I'm trying to figure out how to work with tla to be really productive.
> All I really need is
>
> a) Clearly know which sources where used for which realease
> b) What changes were done for each of the releases.
>
> The scenario above seemingly provide me with what I want. getting the
> latest from foo--development--1.1 gives me the sources used for release.
> And changelog for that branch tells me what changes were done. They also
> tell me which base release was used to create the release. This implies
> that after the release is done I stop commiting to the branch. The best
> would be to "lock" this branch somehow, so that nobody else by mistake
> would commit to it.
>
> Am I closer now to "proper" handling of "my" situation?
>
>  
The only difference between what you said, and the recommendation, is 
the idea of keeping a "release" branch. Often, it is not good enough to 
know what the latest 1.0 version is (1.0.1, 1.0.2, etc). You need to be 
able to get a specific one. Customer Foo has installed 1.0.1, you've 
already done some work and are on 1.2, but you have also backported some 
fixes and have a 1.0.3 release.

Foo has a problem with 1.0.1, which doesn't seem to be fixed anywhere, 
but you can't seem to reproduce it with your current code. You need to 
checkout 1.0.1 for debugging purposes. With your scheme, there isn't an 
obvious way to determine what code corresponds to 1.0.1

To keep names short, I will use "dev" and "rel" as the branches, and 
"spam" as the project.

spam--dev--1.0 <- development work towards the 1.0 release
 spam--dev--1.0--patch-10 # you've finally gotten there

# If you are not in a wdir you must supply the full names of the 
revision you are dealing with
# tla tries to be smart so if you supply spam--dev--1.0 it will grab the 
latest revision
tla tag spam--dev--1.0--patch-10 spam--rel--1.0
# spam--rel--1.0--base-0 now corresponds to the 1.0.0 release
# start working on a new version
tla tag spam--dev--1.0 spam--dev--1.1
...
 spam--dev--1.1--patch-4 # You've been working for a while when you 
find a very important bugfix

# you can do this a couple different ways, but it might be easiest to 
get the latest 1.0 dev branch
cd ~
tla get spam--dev--1.0 spam-dev-1.0
cd spam-dev-1.0
#hack hack, possibly merge, blah blah
 spam--dev--1.0--patch-12 # it took a couple of patches to get it right

cd ~
tla get spam--rel--1.0 spam-rel-1.0
cd spam-rel-1.0
tla star-merge spam--dev--1.0
# Instead, you could do tla tag spam--dev--1.0 spam--rel--1.0--patch-1
# But star-merge gives you nicer patch logs, etc.
tla commit -s "Important security bugfix"
 spam--rel--1.0--patch-1 # Corresponds to 1.0.1

cd ~/spam-dev-1.1
# Continue working on new line.
# Depending on how the bugfix was done, it might be very likely that you 
want
# to merge the changes into this tree. Or you might have already done 
the fixes
# here, and only merged them back to 1.0

This is slightly simplified from Jan Hudec's version. Since he included 
a spam--rel--1 line for all of the 1.* versions. His might be better for 
long term work, but I'm hoping my use case helps you understand.
John
=:->

signature.asc
Description: OpenPGP digital signature