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

[Andrei A. Voropaev]

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?

-- 
Minds, like parachutes, function best when open