[Top][All Lists]
[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>
signature.asc
Description: Digital signature
- [Gnu-arch-users] strategy to handle back-fixies, Andrei A. Voropaev, 2005/01/20
- Re: [Gnu-arch-users] strategy to handle back-fixies,
Jan Hudec <=
- Re: [Gnu-arch-users] strategy to handle back-fixies, Andrei A. Voropaev, 2005/01/21
- Re: [Gnu-arch-users] strategy to handle back-fixies, Harald Meland, 2005/01/21
- Re: [Gnu-arch-users] strategy to handle back-fixies, Andrei A. Voropaev, 2005/01/21
- Re: [Gnu-arch-users] strategy to handle back-fixies, John A Meinel, 2005/01/21
- Re: [Gnu-arch-users] strategy to handle back-fixies, Andrei A. Voropaev, 2005/01/24
- Re: [Gnu-arch-users] strategy to handle back-fixies, James Blackwell, 2005/01/24