On 4/26/19 2:15 PM, Jeremy Huntwork wrote:
On Fri, Apr 26, 2019 at 2:36 PM Bruce Dubbs <[email protected]> wrote:
My concern is maintaining the current integration between svn and trac.
If the move of jhalfs works well, then we can consider moving LFS and
BLFS (patches/hints also) to git.
The other issue is the work required. Personally I do not see the
advantages in git for LFS. The move appears to be more work for little
or no benefit. There are only a few svn command to know:
svn checkout (once)
svn update
svn status
svn commit
svn diff
and very occasionally
svn info
svn blame
svn cp
svn delete
svn add
svn mv
Changing to git will also require rewriting or at least a major update
of the editor's guide and to several web pages.
http://www.linuxfromscratch.org/blfs/edguide/
Also note that the proposed change affects me more than anyone else.
Currently I make about 90% of the changes to LFS and a little over 60%
of the changes to BLFS. It's difficult for me to see those numbers
changing much in a change to git.
Why do you think that is the case?
As Don mentioned, subversion is a centralized architecture. Git, by
using a more decentralized design makes it easier to track
transactional changes and avoid conflicts with other devs. Branches
are essentially free. And git has long surpassed subversion as the
more commonly used tool, so even if it's less familiar to you, it is
now much more familiar to lots more people. All of that encourages
collaboration.
Branches don't really cost anything in svn either. About the only
conflicts we get are in the changelog.
Add to git a public service with a thriving community like Github and
you make it even that much more accessible. As a case in point, take a
look at Gentoo's Github account: https://github.com/gentoo, and look
at how many pull requests they have:
https://github.com/gentoo/gentoo/pulls Just about each one has active
discussions and comments. A setup like this means someone doesn't have
to have a 'linuxfromscratch.org' account to contribute, or even
subscribe to a mailing list to submit a patch. As account owners for
the repo you can still manage who has the ability to accept pull
requests so code doesn't make its way to the master branch that isn't
approved, but the barrier to entry for collaboration reduces
significantly.
Really?
svn co svn://svn.linuxfromscratch.org/LFS/trunk/BOOK/ LFS
cd LFS
vi <file to change>
svn diff > lfs.patch
Send email with attachment.
The difference is that you need to sign up to the mailing list instead
of the git repository. For small changes we don't even need a patch.
Just saying what is needed is often enough.
If you haven't worked this way before, I can appreciate why you might
not see the advantages. To those who have done both (like me) they are
obvious. Even if you don't ever change LFS to git, it's worth trying
out collaborating this way at some point with some project. It really
is a much nicer way to work.
I can do a git clone, but do not contribute to other projects.
Actually, I think the biggest factor that makes users hesitant to
contribute directly is that the books are written in docbook formatted
xml.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
