On 02/09/2012 12:08 PM, Tim Blechmann wrote:
with svn your working copy gets easily out of sync ...
svn update is all you need. ever. There are conflicts from time to time. Man up resolve them.
true, but in my experience resolving conflicts with svn is much more fragile than with git ...
the nice thing of git is that it does not really harm if your branch diverges from upstream, as its merge facilities are much more sophisticated than everything that subversion has to offer ...
I've heard that a couple of times now. My personal experience with git however is quite the contrary. I regularly mess up my local repository.
well, you need to have an understanding of what you are doing ... but at least all you changes are stored inside the local repository. if you mess with your local changes, you can revert to them, if you mess with a working copy, you mess with files that you cannot got back to ...
Right, and there are plethora of ways to mess up local copies with git. While it might be possible to get back in a sane state it is extremely hard. As said, especially with the features everything advertises here, it gets really hard to maintain something like a mainline git repository.
frankly, since i moved my code into boost's svn, i find it way more fragile to maintain than before
Yes, I used to advertise git too. I had the exact same experience. That goes away. After a while, you won't look back to git, and enjoy "svn up" and "svn commit" and
svn was a relief for me after using cvs ... i've had the same feeling when switching to git a few years later. using svn again (for boost), it really feels like a bad joke ...
start to question the usefulness of decentralized version control systems for a centralized boost altogether.
just because git is decentralized does not mean you cannot use it for centralized projects.
All I am asking is: what's the point? If it is used as we use svn currently, why change at all? So far, I've only heard stuff like: "X is extremely easy to do with git (If it is done right, and you know what you are doing, otherwise you are screwed)" (paraphrased). As others hinted, git should probably seen as a "meta VCS", the workflow matters. I definitely can see that something like the "linux model" makes sense for certain libraries. Git was obvously designed for it. However, whenever I tried to use all those nice and funky features (ease of branching and merging etc.). I always lost a lot of time because something didn't work as i expected. After asking people who are supposed to know the stuff, they told i did it wrong and i should use another tool in the git toolset. So I did that the next time and ended up right at the beginning. Sorry, I really tried to use git. It is all nice if you are alone and keep developing for yourself and push feature. However, when there are more people involved, with all kinds of branches etc. I always lost track and messed something up. Be it that something didn't compile for others cause merging failed, be it that history was completely borked or that I myself had the hassle to rewrite history so it all worked out again. In the end my experience was that all the nice features you are describing are not worth the hassle and do more harm than they are worth. Of course, chances are high that i just did it wrong. So, what i would like to see from you guys is a definite guide to use git. A description of workflow for both maintainer, contributor and whatever other role you can think of, and a playground to test that out. Otherwise, I don't see a lot of value in such discussions.
tim