Re: [Gnu-arch-users] Re: Re: Future of GNU Arch, bazaar and bazaar-ng ... ?

[Aldrik KLEBER]

Okay, I understand you.
the problem of baz  actually is the documentation, baz need extra effort on 
this matter. I migrate from tla to baz, and it's true that even with tla 
background I was a bit disapointed with the documentation. But bazaar itself 
is good

> Branching branching branching and easy way to keep track of it.
> Furthermore, usability is a major concern since I am fortunate
> enough to be working with real users (who have no way of
> understanding baz to the point of using it, it's just too
> confusing). I guess it's the usability which makes it really hard.
> My complex needs for an SCM are mainly intuitive interfaces.
>
> Also, I often end up making a mess of my repository and would like
> to be able to commit revisions by cherry-picking changes/hunks.
> darcs does this very nicely.
>
tla and baz too,  this is a natural way of working.
In my case I use to make a snapshot branch wich contain only the revisions I 
want and not the others.

baz branch dev-branch--0.1--patch-5 snap-branch--0.1
baz branch dev-branch--0.1--patch-8 snap-branch--0.1
baz branch dev-branch--0.1--patch-35 snap-branch--0.1

and next snap-branch contains revisions 5, 8, 35


> So if I made two changes to a file, I can commit once and select
> only the first hunk, then commit again and let it write the second
> hunk to the archive.
you can commit 
_  the full tree : baz commit
_ a set of file:  baz commit file1 file2 file3    
or baz commit --file-list   list_of_file_to_commit.txt
_  just a file : baz commit file1

>
> While on darcs, the way it allows you to commit changes to the
> upstream is just wonderful.
>
> Another thing I am completely missing from baz is better/more
> flexibly/scalable hook support. Maybe pqm takes care of that.
> I would like to be able to manage my hook scripts as part of the
> archive.
>
> I also need flexible means to assemble multiple checkouts into
> a single hierarchy. build-configs are too cumbersome for this.
> I would like to be able to do SVN-style subcheckouts, but smarter.
>
> E.g. if I may assume that the variables $CATEGORY/$BRANCH/$VERSION
> hold the data for the current checkout, I would like to be able to
> store in the archive the desire that ./debian should always be
> populated with debian-dir--$CATEGORY--$VERSION. Now, doing an update
> in the root should also update such child checkouts.
>
> Having an archive store a default directory name for checkouts would
> be nice.
I agree hook must be improved.


when you want information on a command

baz command -H



Aldrik