decentralized development using git and git-svn
Asked Answered
V

3

6

We have 2-3 small teams of 2-3 people. We all use git for local and svn for central repository and git-svn got sync. This is works all the time except when we want to share our code between the team it self.

So we have tried out git pull, this creates lots of conflicts and it does not detect that we are on the same tree. It fetches all the changes (same as clone then pull) Of course i dont want to clone full repo. every time I want to share.

Please suggest a better flow.

  1. We can't get rid of central svn.
  2. We can't clone every time.
Visitation answered 10/1, 2011 at 9:35 Comment(0)
C
3

Nominate one team member as the 'git hub', he/she syncs with the SVN server, other team members interact with them, rather than the SVN server directly. That way git will know that all team members are on the same tree.

Chaim answered 10/1, 2011 at 9:42 Comment(2)
Thanks, but how is it decentralized development.Visitation
You have the central SVN server...so, but you will be able to pull updates of each other, as long as only one person interacts with the SVN server. A much better solution would be to replace the SVN server with either 'github' or your own git server, but as you say in your question, you can't do that.Chaim
K
3

SubGit seems like a great alternative for you.

SubGit is server-side solution, it enables Git access to Subversion repository and vice versa. That means you can work with Git repository only, using Git client of your choice.

You need to install SubGit into your Subversion repository once. After that SubGit immediately translates svn revision into git commit on every svn commit and git commit into svn revision on every git push.

SubGit is closed-source software but it is free for open-source projects. For more information please refer to SubGit documenation.

Kriemhild answered 9/12, 2011 at 4:5 Comment(0)
D
2

To add to Chris Huang-Leaver's answer, you need a central point to dcommit/rebase with the svn repo.
That doesn't deny the "decentralized" aspect of Git, it simply allows everyone to work with, as one of their remote repositories, one "central" repo of reference (i.e. the one sync with svn)

There is no easy way to avoid the burden to clone everything coming from the (potentially huge) svn repo, because the resulting Git repo cannot be split into submodules.
That leaves at least one "solution", which would involve:

  • creating different Git beside the main one (which sync with SVN)
  • exporting patches from the main repo
  • applying those patches to each Git repo representing a project within the main Git repo.

It obviously needs to be automated, but one team would focus on one of those git repos as its "central" repo, and the person in charge of SVN synchronization would update those smaller Git repos with patches coming from the main (and hidden) Git<=>SVN repo.

Disrobe answered 10/1, 2011 at 11:49 Comment(1)
OK, I am geting the point here. But I pitty much satisfied with git and git-svn. There are few people in teams who are not ready to go to git (god help them). So I am looking for a way by which we can share code b/w each other by simply pulling or pushing. Currently we use git format-patch which is of course not neat.Visitation

© 2022 - 2024 — McMap. All rights reserved.