Re: People using code from hg should be aware about tazwok/tazkg/slitaz-dev-tools branching.

[Paul Issott <paul@xxxxxxxxxxxxxxxxxxx>]

Hi

Did you check with the other developers before you started branching the
repos? Because I need to do some work in there and will probably have to
wait until all the branches are merged again (I'm not a developer).


On Fri, 2011-03-04 at 02:21 +0100, GoKhlaYeh wrote:
> Hi all,
> 
> I preparing some new feature / bugfixes for tazpkg/tazwok/tazchroot.
> As each tool new code depends on each other, and as not all is fine yet,
> I'm creating new branches on hg.slitaz.org; to make peoples wanting to
> help able to. I choose this way because it avoid problems like thoses
> we had together due to my previous behavior (tazwok-experimental etc).
> 
> I want to have you aware of this branching, because people using the
> last code from hg should care about which branch they use. I say that
> specially about tank, where tazwok-4.3, tazpkg-4.3 & tazchroot 1.1
> should not be used yet.
> 
> Also, people commiting on theses repositories should care about in
> which branch they're commiting (unless you intend to change something
> about incoming features - or add new ones, you want to commit bugfixes /
> well tested improvement into default branch).
> 
> So, let me explain quickly how I work with branch, as I did some
> research to find a good way to do.
> 
> In our repositories we don't really took advantage of mercurial
> branches until here; just create some unintentionnaly when several
> peoples prepare commits at the same time, than one of them perform a
> merge and push to the repos.slitaz.org.
> 
> So, the only branch existing in all repos is "default" (named this way
> by mercurial). For tazpkg/tazwok, which are 4.1.x, I let the main
> branch named default for bugfixes on them / micro releases. It means you
> can catch the current stable code using 'hg update default'.
> 
> Now, I create a 4.2 branch where I push features I'm working on for the
> next minor release. You can catch the code using 'hg update 4.2' ('hg
> update 1.1' for last tazchroot code into slitaz-dev-tools).
> 
> When you clone the repository, the code you get is the one in the
> default branch. When you pull, it update the code keeping the branch
> you are on. So, everybody have their repos using default branch and will
> still using it unless do a "hg update 4.2" or something this taste to
> change current branch.
> 
> At some point I will tag theses dev branches as beta and push
> tazpkg-cooking/tazwok-cooking/tazchroot-cooking receipts into cooking
> wok. Starting from there, peoples will be able to test the changes
> easily and I will focus on bugfixes (no new features) until all seems
> fine. Then, I will merge theses dev branches into the default one. At
> this point everybody will have the new code in their local hg
> repository by default, as if it was pushed on default branch from the
> start. Also, the branch 4.2 (1.1 for slitaz-dev-tools) will disappear
> from the repository and instead refer to a tag (a specific changeset).
> 
> 
> Feature I'm adding are:
> * tazpkg: ability to recharge only one mirror/undigest
> * tazpkg: use a little file called ID to check if repository is
> up-to-date when using recharge, to avoid download all
> packages.list/packages.txt and so on if they're already up to
> date. (The generation of this ID file is an incoming feature in tazwok)
> * tazpkg: option --rootconfig with install/get-install, which allow to
> use an alternative configuration for tazpkg when using --root= option.
> "Normal" configuration is at /var/lib/tazpkg, while --rootconfig make
> use $root/var/lib/tazpkg. Basically, it allows to create stable chroot
> from cooking and vice-versa using the last packages available.
> * tazchroot: take advantage of the bellow feature to easily create a
> cooking sandbox from stable.
> * tazwok: as for tazchroot, take advantage of the feature bellow
> * tazwok: fix --undigest repository support (a part which will needs
> some help to test various usage cases)
> * tazwok generates a safe-wok, which contains receipts known to cook
> well from tank (allow people who want to use SliTaz from scratch to be
> safe from contributors errors, specially when using a cooking SliTaz
> from scratch); A second already-existing protection being that cooked
> packages go into a dir called packages-incoming; you can push them to
> the (main) packages dir only if all cooked fine, and can test them &
> trash them if it's not OK for you; without loosing previously cooked
> packages.
> * tazwok: better auto-recook of reverse depends when a library is
> updated using elf datas
> * tazwok: check that repositories are well configured before cook
> * tazwok: fix the md5sum list on-the-fly generation when using
> check-incoming
> * tazwok: move some cook-related files from packages to
> packages-incoming.
> 
> If you have some feature requests / bug you want to report, I think
> it's the good time :)
> 
> I will probably put some doc about branching model I use on doc later,
> including information about which command to use to create/merge branch
> correctly.
> 





---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/