code's life

In software development, the most challenge thing is when you solve one problem another new problem comes out quickly, it demands you to find the solution in smart way.

Like my svn-git study

In normal standard product setup, it seems most of problems solved, yesterday when I look into the real svn repository, Wooh, it is different, it use multi projects in one repository, and in svn, probably this is also “standard”, but this is not friendly to git.

Since git is designed to be one repo, one project, and all the study I did before is try to map master branch (git repo) to svn trunk (svn repo), now we have several (more than 30) projects, then it is tricky.

One possible solution is to create git repo for every project, and for local git repository, I can create the scripts to rebase and initialize them easily, but it will be difficult to commit back and push to git main repository, managing so many repos is also a complex tasks.

The good things is normally one designer only face to 5 projects.

Another possible solution is treat them as one big repo, then every designer will see trunk, tags, branch directly in file directory, this is not nice.

So what ?

Probably I need to give up git-svn integration transition phase and cut to git directly, since for this kind svn repo, it goes to complicated,  when it is complex, more problems will pop up when implement them.

See reference:
* http://stackoverflow.com/questions/2732020/git-repository-layout-for-server-with-multiple-projects
* http://stackoverflow.com/questions/3075171/importing-subversion-to-git-problem-with-subpaths

In old blog, I asked myself why to use seperate git server, and got nice ideas today, see architecture

For CI system

Originally we use svn to remote access the server, and it will be nice to let hudson or sonar (also trigged by hudson) to talk to git server directly, it will be much fast.

And it is also the step to later switch to git system directly.

Collaborate on other branch

To be clear, the git master branch is always sync with svn trunk branch, and people (Larry, Peter) can use Git repo to collaborate on other branch like develop.

From the figure above, larry’s local master branch is always sync with “remotes/trunk” (svn repo), “remotes/local/master” (git repo), and Peter’s master is sync with “remotes/origin/master” (git repo) only, And both of them work on develop branch (link to git repo).

So Larry and Peter normally work on develop branch (clone from master) towards git repo, when it reachs to some level, larry will be responsible to rebase back master branch and commit back to svn repo, after that, it is sync back to git repo, therefore Peter’s master repo is up to date as well

If we have other branch from svn (i.e. demo) , in order to not confuse people, we can name demo-svn when clone to git repo, so everyone will notice this is from svn, no one should collaborate on it

Hope you can follow this

Continuously work on git-svn, and make things more clear (still not master everything), let’s revisit the git server again.

Let’s revisit the reminding in Pro Git book

Don’t set up and collaborate on a separate Git server. Possibly have one to speed up clones for new developers, but don’t push anything to it that doesn’t have a git-svn-id entry. You may even want to add a pre-receive hook that checks each commit message for a git-svn-id and rejects pushes that contain commits without it.

Originally we think to let larry as bridge between svn/git domain, and Peter (git domain) will be safe to play towards Git server, this is WRONG.

“Don’t/Never ever push anything to git server that doesn’t have a git-svn-id entry”, everytime when you dcommit back to svn repository, the id will be “changed” to append git-svn-id entry, see below

So if you push changes to git server (main repository) first, after its dcommit to svn repo, the id is updated, therefore the information in git server and svn repo are different, when new things happen, git server will complain the things are changed, it needs merge again.

For this, Peter has to interactive with svn repo as well, see added grey line for number 2 (in picture). And number 1 (picture) also only allow to push already dcommited information.

It also means all designers in git domain need to deal with two repo (svn, git) with careful.

Then are there any benefits to have a seperate git server ? maybe not so much.

1. Has competence to manage the git server,
2. As said, it is good for new designer to get all source codes easily.
3. Has CI (hudson) system towards git server instead of svn server, it shall be fast
4. ??

So though there is no much benefit to have extra git server, I still recommend to set extra git server to gain experience to further move to git totally

Working on svn – git integration these days, and find it is complex and lots of limitation, therefore I need to reconsider the solution.

Let’s take a quick look how to do the dailywork from beginning

General workflow

$ git svn clone -s https://svnserver.codeslife/svn/repos/myjphone
$ # update codes
$ git svn rebase
$ git svn dcommit

Clone the repository for start

Line 1: first you need clone the svn repository to your local git server, this normally take long long since git need to check out each version, and one at a time, if thousands of commits, this takes like several hours ;-(, fortunately it is one time work.

And –s means using standard svn structure, otherwise use –t tag –b branches –T trunk instead, it may comes out problem if you have strange setup. (some tag locks in my case, I didn’t dig into)

Work on git

Normally it suggested to work on topic (any name) branch, when finished, merge it back to master, then commit back

Line 3: rebase from svn to keep last update

Line 4: dcommit is commit back to svn repository

Some issues

If simple update, then it works smoothly using git, you checkin codes into svn using git, and svn client can see all the history data from svn, but if you want to use more of git, you will see problems, I just list one isse when googled and verify it.

Git branching issues

The benefit for using git is branch and merge, while using git-svn solution, it is tricky, since the history will be updated to follow svn, you can experience this and using gitk or git log to see the difference

it is recommend to use rebase instead of merge, then it will cause other issues.

And it doesn’t recommend to use seperate git server (solution 2,3), see Git-svn summary from Pro-Git book

Git-Svn Summary

The git svn tools are useful if you’re stuck with a Subversion server for now or are otherwise in a development environment that necessitates running a Subversion server. You should consider it crippled Git, however, or you’ll hit issues in translation that may confuse you and your collaborators. To stay out of trouble, try to follow these guidelines:

• Keep a linear Git history that doesn’t contain merge commits made by git merge. Rebase any work you do outside of your mainline branch back onto it; don’t merge it in.
• Don’t set up and collaborate on a separate Git server. Possibly have one to speed up clones for new developers, but don’t push anything to it that doesn’t have a git-svn-id entry. You may even want to add a pre-receive hook that checks each commit message for a git-svn-id and rejects pushes that contain commits without it.

If you follow those guidelines, working with a Subversion server can be more bearable. However, if it’s possible to move to a real Git server, doing so can gain your team a lot more.

I will check continuely to see which is best for us

Reference:

* Pro Git book (Git and Subversion) : http://progit.org/book/ch8-1.html

* Git access to apache codebase: http://www.apache.org/dev/git.html

* Is git-svn dcommit after merging in git dangerous? (@stackoverflow)