git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Re: native-git-svn: A Summer of Code 2010 proposal

From
Dave Olszewski <cxreg@pobox.com>
Date
Mar 21, 2010, 23:51 UTC
Message-ID
<alpine.DEB.2.00.1003211643470.21433@narbuckle.genericorp.net>
In-Reply-To
<32541b131003191430ld0eaa9cw1d2aac08cff15682@mail.gmail.com>
On Fri, 19 Mar 2010, Avery Pennarun wrote:
Show 15 quoted lines
> For example, I'd be very happy to learn that your new design would
> allow two people to independently pull from svn://, do work in their
> respective copies of the git repositories, branch and merge all day
> long, pull from each other, and then push back to svn without a)
> making a mess of the svn repo and causing zillions of conflicts, or b)
> linearizing history and losing git's complex DAG.
>
> In the current version of git-svn this is very hard. 'git svn dcommit'
> generates entirely new git commit objects corresponding to the ones
> that were created in svn... but which nevertheless have your merge
> history included, which is awesome.  But if a new person clones the
> svn repo from scratch, he will end up with git commits corresponding
> to those same ones from svn, but *without* the merge history, and
> therefore with different commit ids, and which therefore prevent
> push/pulling between other people who have cloned the repo.

I've been working on a script that does 2-way integration with an upstream CVS repo, using git-cvsimport and git-cvsexportcommit to do the difficult parts.

I solved this problem you mention by rebasing in both directions onto detached HEADs and exporting the result, meaning that the history is permanently diverged from a DAG standpoint. Of course, over time, the rebase would become increasingly messy and horrible, so I created a couple of placeholder refs which are updated after the import/export is finished. These mark the last time it was done, and allow you only to attempt to apply the commits which are new on each side.

It's still very green and I've already worked though a number of pretty hairy problems, so I'm not going to say it's a bulletproof solution. But it does work.

     Dave
Previous: Peter BaumannNext: Jonathan Nieder
Message 29 of 33 in “native-git-svn: A Summer of Code 2010 proposal”
  1. Ramkumar RamachandraMar 19, 2010
  2. Avery PennarunMar 19, 2010
  3. Sverre RabbelierMar 19, 2010
  4. Avery PennarunMar 19, 2010
  5. Ramkumar RamachandraMar 20, 2010
  6. Johannes SchindelinMar 20, 2010
  7. Ramkumar RamachandraMar 20, 2010
  8. Ramkumar RamachandraMar 20, 2010
  9. Jonathan NiederMar 20, 2010
  10. Johannes SchindelinMar 21, 2010
  11. Jonathan NiederMar 21, 2010
  12. Johannes SchindelinMar 21, 2010
  13. Ramkumar RamachandraMar 21, 2010
  14. Johannes SchindelinMar 21, 2010
  15. Sverre RabbelierMar 21, 2010
  16. Jonathan NiederMar 21, 2010
  17. Daniel BarkalowMar 22, 2010
  18. Christian CouderMar 22, 2010
  19. Ramkumar RamachandraMar 22, 2010
  20. Johannes SchindelinMar 22, 2010
  21. Best example of GSoC student participation (was: Re: native-git-svn: A Summer of Code 2010 proposal)Jakub Narebski, Mar 21, 2010
  22. Johannes SchindelinMar 21, 2010
  23. Daniel BarkalowMar 20, 2010
  24. Ramkumar RamachandraMar 20, 2010
  25. Ramkumar RamachandraMar 21, 2010
  26. Daniel BarkalowMar 21, 2010
  27. Ilari LiusvaaraMar 21, 2010
  28. Peter BaumannMar 21, 2010
  29. Dave OlszewskiMar 21, 2010
  30. Jonathan NiederMar 19, 2010
  31. Johannes SchindelinMar 19, 2010
  32. Johannes SchindelinMar 22, 2010
  33. Ramkumar RamachandraMar 23, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.