Saturday 13 October 2012

Git-Svn - a noob's journey, Week 1-2

I've wanted to try out Git for quite a while. Maybe it's just me, the
type of person who wants to know every frigging thing about something
before actually going ahead and doing it, but I've been trying to get
my head around the whole DVCS thing, and still not completely happy
with what I knew. So I kept on reading, mostly blog posts because the
official sources were not that readable, frankly. Problem with blog
posts is that obviously they don't cover everything, and seemed to
raise a lot of corner cases that I didn't feel I understood enough.

That and we used Subversion for our source control at work. So I
didn't see the point. Then I found out about GIt-Svn, which seems to
me the best of both worlds, at least in theory. These are just some
observations and maybe tips for people who want to give git-svn a try.


* OMG. I LOVE the stash functionality. The ability to move your
current working changes into temporary storage, without the
"commitment" of making branches is much welcome.

* git svn rebase means more frequent updates to your working copy,
minimising the chance your changes stray too far from what everyone is
doing.

* I think in the long term, I just need to think about branches in a
new way, since 1. branches can be local, so no one sees the
embarrassing things you're doing; and 2. working in branches means you
can get the latest and greatest code from svn synced to master without
having it cause you any worry about conflicts, etc.

* I had the mistaken idea that if you were using git-svn, that you
couldn't merge from branches. This wasn't the complete picture. Turns
out it's merging between SVN branches in your git repository that you
shouldn't do (see:
http://stackoverflow.com/questions/2693771/git-svn-merge-2-svn-branches)
If you just make a local branch, don't create it remotely in SVN, do
your changes there instead of on "master" (equivalent to svn trunk),
then merge changes back to trunk - that's completely okay.

* Somehow, I lost my changes, even after stashing them. If you make a
stash, don't pop them (ie, apply them and remove from the saved
stashes). I was doing an svn rebase, so stashed the working changes
first. Then the rebase got a conflict, which I then tried to merge. My
merge didn't seem to work, and I saw a post of a similar problem that
said to just do "git rebase --skip". Then my stash wasn't around
anymore! This took me a couple of tries to sort out. Also learned
about "git fsck", which probably would have helped me instead of me
having to manually recreate my changes.

* Don't forget that any commits you make are only local. No one will
see them until you do "git svn dcommit". I knew this would happen to
me eventually. I broke the build doing this, after sending out an
email saying "Yeah, I've fixed the build." then going home. I can also
very easily imagine this happening at a great scale if we ever adopt
it at our workplace.


Please keep in mind that the information here may or may not be
entirely correct. Corrections, comments and advise from more
experienced users are welcome.

TODO: update with list of helpful URLs for git-svn

No comments: