William Harrington wrote: > > On Mar 9, 2014, at 6:19 PM, Bruce Dubbs wrote: > >> I've been working trying to understand Git a little better and >> trying to >> evaluate whether it is appropriate for LFS to migrate. >> > > Here is an article which presents why a person should move to GIT. > > http://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git > > And as you looking for an answer, it may help you understand why git > would be better suited for a project than subversion in some instances. > >> The biggest issue with git from my perspective is the learning curve. >> It's a completely different paradigm. It seems to me that it takes >> more >> commands to do things than with svn, but the main advantages are >> that it >> brings us up to what so many other open source projects are using and >> that it makes merging easier for coordinating the systemd version of >> lfs >> with the main version. This would be especially important if we >> want to >> create a systemd version of BLFS. > > It depends what you are doing between GIT and subversion for the > commands to be more complex or not. Overall, we definitely like using > GIT for CLFS than Subversion, although subversion is still good in > some instances, such as our patch repo. > > With the amount of development that occurs with LFS, it's rather busy > every day. You will find that after a week or so and when all of the > developers understand how to use git and aren't afraid of messing up a > repo, using git from day to day will be second nature. Granted, I've > used it for over 4 years and I'm still learning how to do things. > Recently I setup my own git server and installed cgit and learned to > mirror repos. > > Most commonly I'll pull, and make some changes, and if I don't like > them, I'll reset head back to the last pull, or if I need to work on > something else, I'll stash my changes and then pull, work on > something, then push. Then I can resetore my stash and continue work. > Or, I'll make a git diff of what I'm doing, restore the diff later > depending if it is needed. Then once changes are all well, run a test > render and make sure the book validates, then I push the changes. > > It is good to have quality control. Make sure how changes will be > committed and how the commit messages will be formatted. Do you change > one file and commit and put exactly what was changed, or change a > bunch of files and one commit and make a huge message about what was > changed or a summary, etc?. A standard way of commits is very helpful. > I don't think CLFS set this up, and I think LFS would benefit greatly > from it. I mostly had to go off what the early development with git > commits were.
Well there is a difference between LFS and BLFS. Although there are several devs authorized to commit to LFS, in the last cycle only Matt and I did so. BLFS had seven committers in the same cycle. Generally the only collisions I see are in the changelog or possibly general.ent and then not very often. When I analyze my activities with svn, I find I only use 10 commands: checkout (rarely), update, add, mv, delete, copy, commit, status, propset (rarely), and diff. Creating a branch is only a copy inside my local sandbox and a commit. Note that only three of those require network communication. Occasional diffs from Trac are about the only thing I do from the server other than commits and updates. I did read the document you reference. "Now stop for a moment and try to remember how many times you’ve gone to get a cup of coffee while Subversion has been running some command." My answer: never. Backups may be an issue, but I think Gerard does that daily. Generally on a RAID system you have to have more than one drive to go bad to lose everything and since higgs is now on Linode, bringing up a new system is pretty fast. Merging is generally not needed by me, but that may be the reason Armin wants to move to git. I can't remember the last time I needed to do a merge. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
