[blfs-dev] Possible BLFS systemd solution
pierre.labastie at neuf.fr
Mon Jun 30 05:33:41 PDT 2014
Le 30/06/2014 11:12, akhiezer a écrit :
>> Date: Mon, 30 Jun 2014 03:31:32 +0200
>> From: "Armin K." <krejzi at email.com>
>> To: BLFS Development List <blfs-dev at lists.linuxfromscratch.org>
>> Subject: Re: [blfs-dev] Possible BLFS systemd solution
>> On 06/30/2014 03:00 AM, akhiezer wrote:
>>> Armin: why not cut the gordian knot, and setup a git repo for blfs-systemd
>>> and lfs-systemd, and the requisite git/svn bridges to/from 'traditional'
>>> b/lfs svn: that would be a much better foundation; and I'd bet you _would_
>>> build up a healthy lot of contribs to those sysd projects. I think that
>>> part of the problem here is that you are trying to constrain yourself to
>>> work within an unsuitable framework - you're almost being not bold enough
>>> on the matter.
>> I have tried this. BLFS repository is kinda "damaged" and git-svn bridge
>> would fail to update. I haven't investigated the right reason since I
>> got tired after waiting for several hours to create git-svn clone (7+
> Perhaps Pierre could input on that: iirc/aiui Pierre uses git/svn 'ongoingly'
> for working with lfs &/or blfs.
Actually, importing the BFLS svn repository to git svn takes a long
time, but then it is easy to work with, *as long as no new branch is
created in the svn repository*. If a new branch is created, then the
branch tracking machinery of "git svn fetch" restarts the import process
at revision 1... Since somebody has recently created a lot of new
branches in BLFS svn :-), it was really to long to update the git svn,
and I now use a traditional svn sandbox (+ quilt). Even if no branch is
created, a tag has the same effect of restarting the import process.
Well, with a 6 month schedule, that would be doable. Now, something I
have never tried, is to export the git svn repo.
More information about the blfs-dev