Continuing :) On Saturday, February 27, 2010, Mathieu MARACHE <mathieu.mara...@gmail.com> wrote: > Hi Bruce, > > Le 26 févr. 2010 à 22:55, Bruce Wheaton <br...@spearmorgan.com> a > écrit : > >> On Feb 26, 2010, at 12:38 PM, Mathieu Marache wrote: >> >>>> Speaking of which, here's my 2c. Git is designed to address the >>>> exact problems discussed in this thread - it allows contributors >>>> to safely develop parallel branches and 'grown-ups' to merge >>>> selected branches with the main branch, and it has great support >>>> for tags and full releases, *but* it's way harder for the dabbler >>>> to work on some features but try to keep up to date with an >>>> ongoing flow of many changes. For instance, if I were working on >>>> ImageStreams, and had occasional small fixes, but also wanted to >>>> keep up to date with the 'head' branch, I'd expect to have a lot >>>> of merge problems when I update - I do have with another project >>>> that has moved to Git. >>> >>> I'm confused. DCVS tools should ease this process (or at least they >>> all claim it loud). It would be grand if you could be more precise >>> in your description of the process. Because it looks like this >>> could be a show stopper... >> >> I'm not sure it would be a show stopper. For the regular full-on >> updaters - who I believe we're trying to reduce the strain on right >> now - there's great tools for merging branches and making new ones >> etc. For the beginner or straightforward user, getting a full >> checkout of a tagged release is easy enough. >> >> It's just the in between users - those who tend to make a few >> tweaks, and/or would like to stay current that will have to work a >> bit harder. >> >> In essence, the problem seems to be that Git always regards your >> local work - which is a real repo, as sacrosanct, and you can't tell >> it to ignore your noodlings and overwrite it with the lovely fresh >> code from the master branch. If you try, by accident, then auto- >> merges tend to fail (in my experience) and you end up with a hung >> repo that's between one state and another. You then, in theory would >> go by hand and merge things and execute some magic to tell Git that. >> In the particular project I dealt with it, this included a huge >> amalgamated C++ file that would be suicidal to try to merge by hand. >> >> I also find that the failed merges fills files with <<<<<<< mine >> type stuff, and double copies of things (mine/theirs in one file) >> that make diffs very hard. The solution seems to be to make branches >> very often, so you can revert them or switch away from them. I think >> they're enforcing what they believe to be the correct behaviour. It >> was Linus that made it, after all. They actually removed an old >> merge strategy of 'prefer theirs', god bless 'em. >> >> I sometimes solve it with a forced update/switch trick, but it >> always feels like a bodge. >> >> I still think making the change will help - it's obvious the load on >> one developer is unfair, and I'd prefer it be Git, but I wanted to >> warn people it's not as seamless a change as it might seem from the >> ease of importing svn. > > Thanks a lot for taking the time to explain this in more details. I am > one of those 'in between' users and have a few tweaks that I need to > survive osg update. As of today I have to use the vendor branch > technique in svn to reduce the pain, but then I only use tagged > developper releases not the regular trunk. I'm
also looking for a process to handle my local tweaks against the trunk. My goal is to make those tweaks suitable into a formal submission. Working on this process would highlight one of the scenario osg submitters need to follow using git. I'm still waiting to be able to have write access to the wiki to detail those scenarii, maybe I'll stick on github's in the meantime. Mathieu -- -- Mathieu O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
