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

[GoKhlaYeh <gokhlayeh@xxxxxxxxxx>]

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.

-- 
GoKhlaYeh <gokhlayeh@xxxxxxxxxx>


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