On Sun, Nov 18, 2018 at 12:56:15AM -0600, Bruce Dubbs via blfs-dev wrote: > On 11/17/2018 11:37 PM, Ken Moffat via blfs-dev wrote: > > > > The problem with svn, in general, is that it is obscure and very > > poorly documented (in particular, things which are claimed to work > > might not work in BLFS). > > Poorly documented? Try http://svnbook.red-bean.com/en/1.7/index.html > I've had that as a bookmark for a loong time. >
I usually look at the current version of the red book when I'm having problems, but being stuck in a merge and having to keep re-entering my passphrase as svn looked back and forth at different revisions did not seem like a good place to start searching - I didn't want to have it time-out (not sure if it would, or not) and anyway at that point I didn't have any idea what result it would come up with. > Also note in the Editor's guide: > http://www.linuxfromscratch.org/blfs/edguide/chapter03.html > > That also has a link to the subversion documentation in the Introduction > section. That link is to an older version, but the basics haven't changed. > > > Anyway, it is done now. But if you mention making a branch for > > future changes which are intended to end up in trunk, I'll be gone. > > Just for info, when I release a new version of one of the books, I use a > checklist that starts out: > > 1. In sandbox: > cd ~/LFS/tags > svn cp ../trunk/BOOK new-tag > edit general.ent and edit > version (x.y-rc?), short-version, generic-version, releasedate > edit packages.ent and make permanent BOOTSCRIPTS- > {SIZE,MD5SUM,INSTALL-KB} > edit changelog with release entry > commit > Thanks for documenting that. > I admit that I do not try to merge anything from there back into trunk. > > To me, merging is like a patch; you are only updating parts of a file. If > the file in the branch is correct and complete, then to me copying is the > obvious (and simpler) way to go. > > -- Bruce You'll have seen my previous comments (to editors) in the past couple of months. What baffled me with this merge was that for three new files added in trunk, svn thought that in the branch they were added by my merge from trunk, and were therefore potentially different - but using the same response to the options it offered, two were successfully resolved and one was not. I had thought that merging from trunk to the branch would show that the file had coem from trunk, and therefore there would be nothing to do on that file when merging the branch back to trunk. But like everyone has ever said: merges in svn are unpleasant. > > PS: Thank you for all the work you have done to modernize the Perl modules. > It looks good. > Thanks to you, and everyone else, for the kind words. It's time for me to thank Pierre for his help with this. ĸen -- If a man stands before a mirror and sees in it his reflection, what he sees is not a true reproduction, but a picture of himself when he was a younger man. -- de Selby -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
