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

Re: Git / Subversion Interoperability

From
Julian Phillips <julian@quantumfyre.co.uk>
Date
Mar 23, 2007, 01:36 UTC
Message-ID
<Pine.LNX.4.64.0703230128330.4001@beast.quantumfyre.co.uk>
In-Reply-To
<20070323012422.GC17773@spearce.org>
On Thu, 22 Mar 2007, Shawn O. Pearce wrote:
Show 8 quoted lines
> Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> That would probably be good enough for the majority of
>> one-project-per-repo Subversion projects at least.  Though there is still
>> the issue that Subversion will actually let you create a "tag" simply by
>> committing whatever you currently have in your working copy (including
>> localally modified files ... yeuch).
>
> Heh.  People do weird things.  ;-)

Well, I don't think there would be too many complaints if a git-based Subversion server didn't support such methods of creating tags ... ;)

Show 13 quoted lines
>
>>> That's all I can think of right now.  But I'm sure there are more.
>>
>> Properties are probably the next biggest headache.  Subversion allows you
>> to associate arbitrary keyword value pairs with files (which are
>> versioned) and with revisions (which are not versioned).  You would need
>> to find someway to support this in git.  Since revision properties are
>> disabled by default in Subversion you may be able to simply disallow them
>> permanently - but I don't know anything about the Subversion protocol ...
>
> I thought about the properties, but didn't bother to write anything
> on that subject as we may just be able to say "look, properties
> are not supported in git-svnserver, so don't try to use them".

Indeed. That's what I was aiming at with the the last sentence (not very clearly unfortunately). It would be nice if the server could tell the client that properties are not supported ... but I doubt that it can, since they are fundamental part of Subversion.

In particular it's how the client finds out about things like symlinks and line ending conversion. It may be necessary to provide some basic support for some of the properties in the svn:... namespace in order for the Subversion repo access library not to refuse to talk to the git server.

>
> The git-svnserver is meant to help users migrate to Git, not to offer
> up all of SVNs features and warts.  A big part of this project may
> just be deciding what features we are willing to try to emulate.

Indeed. It sounds like an interesting idea. Anything that increases the possibilty of my convincing the appropriate people to migrate my work project ... ;)

-- 
Julian

  ---
"From there to here, from here to there, funny things are everywhere."
-- Dr. Seuss
Previous: Shawn O. PearceNext: Karl Hasselström
Message 5 of 25 in “Git / Subversion Interoperability”
  1. Bruno Cesar RibasMar 22, 2007
  2. Shawn O. PearceMar 23, 2007
  3. Julian PhillipsMar 23, 2007
  4. Shawn O. PearceMar 23, 2007
  5. Julian PhillipsMar 23, 2007
  6. Karl HasselströmMar 23, 2007
  7. Bruno Cesar RibasMar 23, 2007
  8. Karl HasselströmMar 23, 2007
  9. Julian PhillipsMar 23, 2007
  10. Bruno Cesar RibasMar 23, 2007
  11. David LangMar 23, 2007
  12. Daniel BarkalowMar 23, 2007
  13. Shawn O. PearceMar 24, 2007
  14. Karl HasselströmMar 24, 2007
  15. Linus TorvaldsMar 24, 2007
  16. Junio C HamanoMar 24, 2007
  17. Sam VilainMar 26, 2007
  18. Christian WieseMar 23, 2007
  19. Steven GrimmMar 23, 2007
  20. Shawn O. PearceMar 24, 2007
  21. Sam VilainMar 26, 2007
  22. Jakub NarebskiMar 23, 2007
  23. Shawn O. PearceMar 24, 2007
  24. Eric WongMar 24, 2007
  25. Eric WongMar 24, 2007

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.