gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Hudec
Subject: Re: [Gnu-arch-users] strategy to handle back-fixies
Date: Thu, 20 Jan 2005 21:06:45 +0100
User-agent: Mutt/1.5.6+20040907i

On Thu, Jan 20, 2005 at 10:07:35 +0100, Andrei A. Voropaev wrote:
> Hello!
> 
> I need an advice about the best strategy for the following situation.
> 
> I have an archive for the project. Another archive contains simbolic
> tags (snapshots) from the first one. I have created snapshot X and have
> been working on new features for snapshot Y. During the work I've fixed
> couple of important though small bugs. Now my boss wants me to create
> snapshot Z that is identical to X but includes those important bug
> fixes.
> 
> One obvious (for me :) way could be to create one more archive, tag into
                                                         ^^^^^^^
You definitely don't need an                             ARCHIVE
> it snapshot X, do the bug fixes and then tag from it into the snapshots
> archive. But I'm not sure if this is going to work and if this is an
> appropriate approach. Would it work when I add snapshot Y?

In fact, it's exactly what versions are for. The overall schema could
look like:

archive/foo--dev--0
    This is the "HEAD" where you work on the new features
archive/foo--release--1--base-0
    This is where you first released. Your snapshot X.
archive/foo--release--1--patch-1
    This is your snapshot Z. It does not matter whether you have
    merged and commited it or tagged it (tags-only branch), but
    I suggest mergeing, because tag-only branches behave a little
    strangely, because they always only contain the last log.
archive/foo--release--2--base-0
    This will be where you will eventualy create snapshot Y.

You can equaly well create the snapshot Z as
archive/foo--release--1.1--base-0
(by tagging).

Generaly, each major release should have new version. I suggest that you
number your releases so they sort correctly in lexicographical order and
map the revisions so that the last component is revision and all that
before is version. Ie:
foo 1.0   => foo--rel--1--base-0
foo 1.0.1 => foo--rel--1.0--patch-1 (where foo--rel--1.0--base-0 is tag
                                     of the above and patch-1 adds the fixes)
foo 1.1   => foo--rel--1--patch-1   (this simply adds minor features)
foo 1.1.1 => foo--rel--1.1--patch-1 (where foo--rel--1.1--base-0 is tag
                                     of foo--rel--1--patch-1)
foo 2.0   => foo--rel--2--base-0    (tag of your --dev-- later on)

You should keep it all in a single archive. The dev might be in other
archive if you need to have different permissions on it (e.g. if you want
to make the release archive public, but keep the dev one private).

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]