SBU report

Pierre Labastie pierre.labastie at
Sat Feb 25 06:11:25 PST 2012

Le 24/02/2012 20:20, Peter Palmer a écrit :
> On 24 February 2012 16:45, Pierre Labastie<pierre.labastie at>  wrote:
>> Le 24/02/2012 15:46, Peter Palmer a écrit :
>>> On 24 February 2012 13:13, Pierre Labastie<pierre.labastie at>    wrote:
>>>> I have seen that CLFS is now on git. Have you tried
>>>> to replace svn instructions by "equivalent" git ones
>>>> in jhalfs? I do not know much about git, but I know
>>>> rather well jhalfs, so if I may be of some help...
>>> First thanks to Thomas for giving me an early pointer to the problem I
>>> introduced.
>>> I was just working on another patch but Pierre beat me to it. I don't
>>> bother posting as the only difference is the name for the new variable
>>> :)
>> Sorry for that. I always think it is easier to explain with code...
>>> I never worked with svn as vcs so I use git locally to work with
>>> jhalfs. I've got one branch that I keep in sync with the svn trunk.
>>> Branching is very easy in git so I create a branch for whatever
>>> project I work on. To get the diff I just run:
>> Just to make sure we understood each other (I am not a native
>> English speaker), I meant that jhalfs had some instructions to
>> download on the fly the LFS book from SVN repo. I was not talking
>> about managing jhalfs mods with GIT. Seeing how the philosophy
>> of GIT is to have a local "working copy" (+ repo), those download
>> instructions are maybe not necessary for CLFS.
>> Since I am also busy with the blfs tools, I think I won't add GIT
>> download instructions now.
> Pierre, I was on a different planet there. I am here now:
> ./jhalfs:
> case $PROGNAME in
> # TODO: clfs is now on git
> #  clfs* ) declare -r SVN="" ;;
>        * ) declare -r SVN="svn://" ;;
> esac
> ~~~~~and here:~~~~~
> common/libs/func_book_parser:48:
> svn co $SVN/${svn_root}/${TREE} ${PROGNAME}-$LFSVRS>>$LOGDIR/$LOG 2>&1
> IMHO for a casual user there is little difference between svn, git or
> a tarball and the git philosophy doesn't matter.  Personally, even
> when working on a development branch I would always want to be able to
> fix a particular version of a book as this makes error hunting a lot
> easier. However I can see how the svn/git option is a useful feature
> for some; both for LFS and CLFS (and BLFS of course).
> I would propose to add something like this though:
> if [[ -d $SVN ]] ; then
>    echo --n "You seem to have a working copy of the book already. Do
> you want to update this to the newest version? (no)"
>    read ANSWER
> etc...
> What do you think?
> In the mean time I'll have a look at the CLFS/git download.
There is no need to test $SVN, I think, because in the menuconfig
interface, the user is given the choice of using either local book sources,
or sources downloaded from a remote repository.
My remark about "philosophy" was just that with GIT, it does not seem
to make much difference whether the repository is local or remote, once
you have 'git clone'd one.
As you (and other recently) said, it is not very common to need to
download a book source on the fly. What I do with LFS is to have a local
working copy of the current development book, and I usually don't need it
either. Only when Bruce asked to test the 7.1-rc1 version did I downloaded
it, since it was not supposed to be modified (of course) for tests...
AFAICT, you pointed all the places where the code should be modified.

By browsing the source with Trac, I see that there are a lot of branches.
So a user might want to download a specific version (say 1.2 or 1.1.0..),
to try it. I do not know how to do that with git. Looks like you need to
somehow convert those version numbers into some hexadecimal
string. With SVN, the encoding is done in $svn_root/$TREE.


More information about the alfs-discuss mailing list