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.
Bruce
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
