6 ms·

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that ne

by amix 16y ago

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user friendly. I am currently evaluating Mercurial, since it seems to be easier to use and more user friendly. Anybody have experiences working with both Git and Mercurial with a team of 5-10 people?

jlgbecom 16y ago
I've had similar experiences. Git has great potential, but the tools seem very immature, and basic things I took for granted with Subversion are huge pita's with Git. And it seems like all that needs to happen is a really solid toolkit to simplify those tasks.
- JustAGeek 16y ago
  Could you please elaborate on that? What basic things did you have problems with?
- city41 16y ago
  I've had the opposite experience. I've generally found git a joy to use and I don't miss SVN in the slightest. I highly recommend reading Chacon's Pro Git book. As really understanding how Git works internally helps in using it a lot.
JustAGeek 16y ago
Which issues did you have exactly? I'm asking because my team members want to switch to Git after having to suffer through my praising git for long enough and I'd like to know which traps to avoid. My personal switch from SVN to Git was rather painless but that's probably because I "only" used git-svn and at first used Git pretty much like I used SVN and then step by step explored the possibilities offered by Git like local branches etc. pp. That's what I'd recommend to anyone making the switch, first try it out with git-svn, don't use every new feature at once. DVCS is a completely different paradigm, it requires some time to wrap your head around. :)
- sandGorgon 16y ago
  For me the biggest problem was ending up with a lot of heads. I guess this happens when you go back to a previous commit and in-advertently starting checking in stuff - In SVN, this is prevented. I dont exactly remember how I handled this the last time around, but I think some rebase-fu was needed
ciupicri 16y ago
Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html http://hgbook.red-bean.com/read/managing-releases-and-branch...
- masklinn 16y ago
  > It forces me to have a repository for every topic branch when I'm contributing to an open source project. You might want to read the first link you gave, I think.
  - ciupicri 16y ago
    What do you mean? I read that guide almost an year ago and decided that branching with clones is the best option for me.
    - tednaleid 16y ago
      Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.
      - ciupicri 16y ago
        Here's my current setup: I have 2 clones/repositories of Satchmo. [1] is for bug fixing and [2] for translations. I've asked for a better solution on the #mercurial channel and no one has offered it to me. If you have a better idea that's similar to git[3] (1 repo), I'm waiting for it. Until then I'll complain about what Mercurial is offering me, just like Groxx and cdavid (see above). [1] http://bitbucket.org/ciupicri/satchmo http://bitbucket.org/ciupicri/satchmo [2] http://bitbucket.org/ciupicri/satchmo-l10n-ro http://bitbucket.org/ciupicri/satchmo-l10n-ro [3] http://github.com/ciupicri/cobbler/tree/master-pagination-bugfix http://github.com/ciupicri/cobbler/tree/master-pagination-bu...
fr0sty 16y ago
My team of 5 switched to git this year. Hust yesterday (I'm not making this up) one of my team members thanked me for pushing the change. Develoment for us has gone much more quickly now than before and we have had very few issues. One thing that is essential to a good transition is to have a strong evangelist who is willing to address problems, educate people and investigate when something happens that you don't understand. ProTip: #git on freenode is a great resource if you find yourself out of your depth.
adam-_- 16y ago
We use git to manage the codebase of two apps that have about 15 people working on each. Every team or project branches from master at the start of an iteration and works off that branch until the end of the iteration then merges/rebases back onto the master branch. Then we we tag and branch at the end of an iteration to push code live. Works very well for us and seems a lot less painful than the frontend guys using SVN.
pyre 16y ago
> We recently switched from SVN to Git Part of the problem is that git is not similar to SVN in the way that SVN was similar to CVS. People have to give up their old paradigm of thinking, and it certainly helps if at least one person in your group is a git guru (or at least someone that is willing to investigate/fix problems without feeling like it is a chore) otherwise you will end up in the situation where everyone feels like the whole conversion process/idea was just a chore. If there is someone that makes themselves the 'go to guy/girl' for git issues it alleviates the rest of the group from thinking about git issues all of the time.
prog 16y ago
I have been using bzr with a team of 4 for some time now. Moved from ClearCase UCM and haven't looked back. :-) As most people had experience with cvs and svn the command set was easy to pick up. We just needed to put together a policy with integration branch and user specific product branches. It was a unix only install so standard unix groups/perms were used for these directory hierarchies.
yummyfajitas 16y ago
There is little technical reason to choose Git over Mercurial or vice versa. Their usage is extremely similar. Git exposes a few more internals, and lets you fix mistakes more easily. For sharing branches which are incomplete, git's `rebase -i` is also somewhat superior to mercurial queues. Overall, I've found git to be marginally better than hg. The real killer feature that git has is that git talks to github and svn. Mercurial only talks to bitbucket (sorry guys, network effects are important and github won).
- tednaleid 16y ago
  Mercurial also talks with git (http://hg-git.github.com/ http://hg-git.github.com/) so you can use it with github if you want. This was actually created by Scott Chacon, the guy who wrote the subject of the OP. I think it's worth giving both git and hg a try to see which fits your head better. Mercurial feels better to me and there are quite a few people in many communities (including most of the python community).
- kree10 16y ago
  The genius thing about git-svn is not that it only "talks" to svn: using git-svn (you could say subversively) converts your repo to git. One day, when somebody suggests dumping svn for git, you can skip the "but how do we preserve all that history if we switch" conversation, because it's already done.
  - brodie 16y ago
    Mercurial's hgsubversion works just like this as well: http://mercurial.aragost.com/kick-start/hgsubversion.html http://mercurial.aragost.com/kick-start/hgsubversion.html
e40 16y ago
What issues are you having? I converted my company over a year ago to Git from CVS. The main problem we still have are people that either refuse to spend the time to learn Git properly or quasi-technical people who just aren't capable of it. For the former group, some people are just lazy and try and take the easy way out. Or, they're stubborn and think they can get by with a little knowledge. I've found, to a person, that once they put in the work and know how to use it, it's a rewarding and fun experience to use Git. It's not easy, though.
darklajid 16y ago
I managed to talk my company into git as well - although our route is different: We literally had no (official, my projects always ended up using a private repository of some sorts) source control. At all. So, after fighting the battle for far too long I'm now rolling out git/gitorious right now, with lots of early adopters using that already, on my (properly backed up..) test machine. The biggest issue that I've seen so far are mostly general "I just don't get scm" things (no commit message or a useless one. Working around rules by just entering space if I try to prohibit this). The only git specific issue that come up is that the people don't understand that each user's clone/working copy is a separate branch of the origin already. If 2 guys clone from the "server", you now have 2 branches of origin/master. pull by default merges remote and local branch, which leads to a huuuuuge number of completely useless merge commands in the histories of some projects. That makes the history far less useful in my book and all visualizers now show you a large numbers of branches that you don't care about. You can work around that by educating users to, for example, using git pull --rebase - but that is a concept that needs quite some understanding first. Apart from the thing above the introduction seems to work fine so far and people with different background (VSS.., cvs/svn mostly) are using it without (real, major) problems. And I'm glad that we finally will have an official scm server sometime this month, after only ~5 years of nagging. Ah, it's the small things that make me happy these days...
- JustAGeek 16y ago
  You can config Git so that it always uses rebase when pulling: git config branch.autosetuprebase always To override this simply use --no-rebase.

by amix 16y ago

jlgbecom 16y ago

I've had similar experiences. Git has great potential, but the tools seem very immature, and basic things I took for granted with Subversion are huge pita's with Git. And it seems like all that needs to happen is a really solid toolkit to simplify those tasks.

JustAGeek 16y ago
Could you please elaborate on that? What basic things did you have problems with?
city41 16y ago
I've had the opposite experience. I've generally found git a joy to use and I don't miss SVN in the slightest. I highly recommend reading Chacon's Pro Git book. As really understanding how Git works internally helps in using it a lot.

JustAGeek 16y ago

Which issues did you have exactly? I'm asking because my team members want to switch to Git after having to suffer through my praising git for long enough and I'd like to know which traps to avoid. My personal switch from SVN to Git was rather painless but that's probably because I "only" used git-svn and at first used Git pretty much like I used SVN and then step by step explored the possibilities offered by Git like local branches etc. pp. That's what I'd recommend to anyone making the switch, first try it out with git-svn, don't use every new feature at once. DVCS is a completely different paradigm, it requires some time to wrap your head around. :)

sandGorgon 16y ago
For me the biggest problem was ending up with a lot of heads. I guess this happens when you go back to a previous commit and in-advertently starting checking in stuff - In SVN, this is prevented. I dont exactly remember how I handled this the last time around, but I think some rebase-fu was needed

ciupicri 16y ago

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... [2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html http://hgbook.red-bean.com/read/managing-releases-and-branch...

masklinn 16y ago
> It forces me to have a repository for every topic branch when I'm contributing to an open source project. You might want to read the first link you gave, I think.
- ciupicri 16y ago
  What do you mean? I read that guide almost an year ago and decided that branching with clones is the best option for me.
  - tednaleid 16y ago
    Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.
    - ciupicri 16y ago
      Here's my current setup: I have 2 clones/repositories of Satchmo. [1] is for bug fixing and [2] for translations. I've asked for a better solution on the #mercurial channel and no one has offered it to me. If you have a better idea that's similar to git[3] (1 repo), I'm waiting for it. Until then I'll complain about what Mercurial is offering me, just like Groxx and cdavid (see above). [1] http://bitbucket.org/ciupicri/satchmo http://bitbucket.org/ciupicri/satchmo [2] http://bitbucket.org/ciupicri/satchmo-l10n-ro http://bitbucket.org/ciupicri/satchmo-l10n-ro [3] http://github.com/ciupicri/cobbler/tree/master-pagination-bugfix http://github.com/ciupicri/cobbler/tree/master-pagination-bu...

fr0sty 16y ago

My team of 5 switched to git this year. Hust yesterday (I'm not making this up) one of my team members thanked me for pushing the change. Develoment for us has gone much more quickly now than before and we have had very few issues. One thing that is essential to a good transition is to have a strong evangelist who is willing to address problems, educate people and investigate when something happens that you don't understand. ProTip: #git on freenode is a great resource if you find yourself out of your depth.

adam-_- 16y ago

We use git to manage the codebase of two apps that have about 15 people working on each. Every team or project branches from master at the start of an iteration and works off that branch until the end of the iteration then merges/rebases back onto the master branch. Then we we tag and branch at the end of an iteration to push code live. Works very well for us and seems a lot less painful than the frontend guys using SVN.

pyre 16y ago

> We recently switched from SVN to Git Part of the problem is that git is not similar to SVN in the way that SVN was similar to CVS. People have to give up their old paradigm of thinking, and it certainly helps if at least one person in your group is a git guru (or at least someone that is willing to investigate/fix problems without feeling like it is a chore) otherwise you will end up in the situation where everyone feels like the whole conversion process/idea was just a chore. If there is someone that makes themselves the 'go to guy/girl' for git issues it alleviates the rest of the group from thinking about git issues all of the time.

prog 16y ago

I have been using bzr with a team of 4 for some time now. Moved from ClearCase UCM and haven't looked back. :-) As most people had experience with cvs and svn the command set was easy to pick up. We just needed to put together a policy with integration branch and user specific product branches. It was a unix only install so standard unix groups/perms were used for these directory hierarchies.

yummyfajitas 16y ago

There is little technical reason to choose Git over Mercurial or vice versa. Their usage is extremely similar. Git exposes a few more internals, and lets you fix mistakes more easily. For sharing branches which are incomplete, git's `rebase -i` is also somewhat superior to mercurial queues. Overall, I've found git to be marginally better than hg. The real killer feature that git has is that git talks to github and svn. Mercurial only talks to bitbucket (sorry guys, network effects are important and github won).

tednaleid 16y ago
Mercurial also talks with git (http://hg-git.github.com/ http://hg-git.github.com/) so you can use it with github if you want. This was actually created by Scott Chacon, the guy who wrote the subject of the OP. I think it's worth giving both git and hg a try to see which fits your head better. Mercurial feels better to me and there are quite a few people in many communities (including most of the python community).
kree10 16y ago
The genius thing about git-svn is not that it only "talks" to svn: using git-svn (you could say subversively) converts your repo to git. One day, when somebody suggests dumping svn for git, you can skip the "but how do we preserve all that history if we switch" conversation, because it's already done.
- brodie 16y ago
  Mercurial's hgsubversion works just like this as well: http://mercurial.aragost.com/kick-start/hgsubversion.html http://mercurial.aragost.com/kick-start/hgsubversion.html

e40 16y ago

What issues are you having? I converted my company over a year ago to Git from CVS. The main problem we still have are people that either refuse to spend the time to learn Git properly or quasi-technical people who just aren't capable of it. For the former group, some people are just lazy and try and take the easy way out. Or, they're stubborn and think they can get by with a little knowledge. I've found, to a person, that once they put in the work and know how to use it, it's a rewarding and fun experience to use Git. It's not easy, though.

darklajid 16y ago

I managed to talk my company into git as well - although our route is different: We literally had no (official, my projects always ended up using a private repository of some sorts) source control. At all. So, after fighting the battle for far too long I'm now rolling out git/gitorious right now, with lots of early adopters using that already, on my (properly backed up..) test machine. The biggest issue that I've seen so far are mostly general "I just don't get scm" things (no commit message or a useless one. Working around rules by just entering space if I try to prohibit this). The only git specific issue that come up is that the people don't understand that each user's clone/working copy is a separate branch of the origin already. If 2 guys clone from the "server", you now have 2 branches of origin/master. pull by default merges remote and local branch, which leads to a huuuuuge number of completely useless merge commands in the histories of some projects. That makes the history far less useful in my book and all visualizers now show you a large numbers of branches that you don't care about. You can work around that by educating users to, for example, using git pull --rebase - but that is a concept that needs quite some understanding first. Apart from the thing above the introduction seems to work fine so far and people with different background (VSS.., cvs/svn mostly) are using it without (real, major) problems. And I'm glad that we finally will have an official scm server sometime this month, after only ~5 years of nagging. Ah, it's the small things that make me happy these days...

JustAGeek 16y ago
You can config Git so that it always uses rebase when pulling: git config branch.autosetuprebase always To override this simply use --no-rebase.