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

Re: Git / Subversion Interoperability

From
Shawn O. Pearce <spearce@spearce.org>
Date
Mar 24, 2007, 06:41 UTC
Message-ID
<20070324064130.GC25863@spearce.org>
In-Reply-To
<20070323103426.GA15923@diana.vm.bytemark.co.uk>
Karl Hasselstr??m <kha@treskal.com> wrote:
Show 15 quoted lines
> On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:
> > 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.
> 
> Maybe the pragmatic solution would be to have built-in handling of a
> few properties such as svn:executable and svn:ignore that have git
> equivalents, and just emulate all other properties with files.
That is not a bad idea at all.  We could easily do
  svn:executable -> (mode & 0111);
  svn:ignore -> .gitignore;

I'm sure there are others, but they are the only two Karl mentioned, and that I know of off the top of my head. ;-)

Additional random properties could just be written out to .gitsvnprop in the parent directory.

Here's another SVN feature that we might have to actually emulate: locks. Apparently clients can "lock" a file, preventing others from editing that same file. This is good for say artwork where the file format is a binary thing that just cannot be merged. Some users may actually be using SVN for exactly this reason. Replacing it for some users may require that feature.

Heck, the F!@&@#*!@&@!*! POS (not SVN) that I have to use at my day job can *only* work in this mode (exclusive lock file) and people there still don't know how two different developers can safely edit the same Java file at the same time without that exclusive lock system in place. They are absolutely terrified of auto-merges like what Git does. ;-)

Then they same users go off and incorrectly hand-merge stuff anyway. Stuff that xdiff's 3-way file merge would have done correctly without any problems. Argh!

-- 
Shawn.
Previous: Daniel BarkalowNext: Karl Hasselström
Message 13 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.