2

Is it possible to create streamlined workflow using both VCS (preferably SVN) and DVCS (preferably Mercurial or Git)?

Following facts describe desired workflow:

  • There is one central VCS server.
  • Main development happens on central server.
  • Anyone outside core development team (let's name him Joe) could take a snapshot of source code with complete history.
  • Joe would like to develop a feature in his own branch.
  • Joe doesn't have write permission to VCS, so
  • He's developing locally and committing to his own DVCS repo.
  • When he's finished he contacts main repo admin to merge his work into central.

And here comes the tricky part: Can his work be merged into central repo preserving it's history? So that the main development team could track Joe's individual commits?

I'd like to learn anything, that could point me in the right direction. If the workflow is not impossible to implement than feel free to throw a link to a tutorial. If you already have any experience with VCS-DVCS workflow than please share it. If it's not possible to implement it than the information why is also of great value to me.

I'm aware that the question may seem similar to others (such as vcs or dvcs workflow), but I couldn't find any clues whether or not the history is preserved.

Community
  • 1
  • 1
Rekin
  • 9,731
  • 2
  • 24
  • 38
  • 1
    Why not use a git repo for the central repo – alternative Apr 13 '11 at 19:53
  • 1
    Do you have to use SVN for the central repo? Git or Mercurial would support this workflow completely on their own without the need for a SVN at the center. – Andy White Apr 13 '11 at 19:55
  • 1
    yes, or mercurial, you don't actually need to use svn as the server (unless you do for non technical reasons) – jk. Apr 13 '11 at 19:56
  • I'd love to do so. We've got legacy projects, one is 8 years old. The workflow could be a first step into a complete migration. But no one is going to take a risk of abrupt repo switch. Some of the developers know only CVS. – Rekin Apr 13 '11 at 19:58
  • 1
    Just crash the SVN server anonymously, and make it look like SVN is too old and does not work anymore. ;) – alternative Apr 13 '11 at 19:58
  • Hah, Mathepic... I'd love to! :D – Rekin Apr 13 '11 at 20:02

3 Answers3

7

You can do this with both Mercurial and with Git -- both projects have two-way bridges for interacting with Subversion.

For Mercurial, Joe will use hgsubversion to get a Mercurial repository on his machine with the full Subversion history. He then develops as normal using Mercurial. He will repeatedly pull in new revisions from the Subversion server and rebase his own changesets on top of them.

So let us imagine Joe has made three changesets on top of revision 2 from SVN:

... R1 --- R2 --- J1 --- J2 --- J3

He then pulls in new changesets from Subversion (just hg pull -- hgsubversion will understand that it should incrementally convert the new Subversion revisions into Mercurial changesets). The result is:

... R1 --- R2 --- J1 --- J2 --- J3
             \
              R3 --- R4

where the new branch represent the new Subversion revisions. Since Subversion is linear, he has to rebase his work on top of the new branch:

... R1 --- R2 --- R3 --- R4 --- J1 --- J2 --- J3

He keeps working like this, always rebasing instead of merging, and when it is time to send the changes back he asks you or someone else with commit rights on the Subversion repository to pull his Mercurial repository. You get

... R1 --- R2 --- R3 --- R4 --- R5 --- J1 --- J2 --- J3 --- J4

and you can now push the J1-4 changesets into Subversion:

... R1 --- R2 --- R3 --- R4 --- R5 --- R6 --- R7 --- R8 --- R9

The history is preserved: the four changesets become four revisions in Subversion. Please see my guide for more information and pretty pictures.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
2

You can use SubGit to make your Subversion repository available for Git users.

SubGit is basically a couple of hook scripts one has to install into repository to enable bi-directional synchronization. After installation every SVN revision and Git commit sent to the repository get converted by SubGit.

SubGit preserves not just natural history (revisions and commits) but also history of merges, metadata associated with files, etc. More information you may find at documentation and git-svn comparison.

SubGit is a commercial project, but there are some free options.

vadishev
  • 2,979
  • 20
  • 28
1

You can use git's subversion support to interact with a central repository - you would push changes back to central with "git svn dcommit"

http://git-scm.com/docs/git-svn

Chris K
  • 11,996
  • 7
  • 37
  • 65
  • This looks great. Do you know what happens with history? – Rekin Apr 13 '11 at 19:59
  • I believe that it all gets condensed into on diff, individual commits aren't pushed up, but the merge of the whole is. SVK does this with SVN. I can have 100 local commits, but when I merge to central it's ONE commit, with the text of my 100 local commits (if I so choose - you can always override the commit message). SVK has a feature to apply each local commit as a separate commit to central, but that's dangerous. You'd almost never want each individual commit, but rather the changeset as a whole. – Chris K Apr 13 '11 at 20:32
  • Ok, that seems feasible for the project I'm interested in. You advise against pushing each commit? What about pushing to separate branch and than merging? The repo's maintainer is really keen to have it. – Rekin Apr 13 '11 at 20:38
  • I wouldn't push each commit. But you could have each developer create a branch that they do their work on, and commit individual changesets to that branch and then merge that work to trunk. I think it's overkill. A developer will have to remember to go back and apply each individual commit. The overhead for the developer isn't worth it - the value of the commits themselves is arguable. – Chris K Apr 13 '11 at 22:57