{"thread":{"id":"7358","subject":"Git / Subversion Interoperability","startedAt":"2007-03-22T22:48:29Z","lastAt":"2007-03-26T03:06:51Z","messageCount":25,"participants":["Bruno Cesar Ribas","Shawn O. Pearce","Julian Phillips","Karl Hasselström","Jakub Narebski","Christian Wiese","Steven Grimm","Daniel Barkalow","David Lang","Linus Torvalds","Eric Wong","Junio C Hamano","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"37766","messageId":"20070322224829.GA7048@c3sl.ufpr.br","threadId":"7358","inReplyTo":null,"subject":"Git / Subversion Interoperability","fromName":"Bruno Cesar Ribas","fromEmail":"ribas@c3sl.ufpr.br","sentAt":"2007-03-22T22:48:29Z","receivedAt":"2007-03-22T22:48:29Z","isPatch":false,"sender":{"key":"ribas@c3sl.ufpr.br","avatar":null},"body":"Hello,\n\nI'm going to apply for the Git / Subversion Interoperability project.\n\nI saw that there is no mentor yet assigned for the \"job\". So i'm sending this\nmail to get some help to start the project by submiting to GSOC and begin to\nwork :)\n\nMy idea on this project is to create:\n1. git-svnserver\n2. write a backend for Subversion\n\nAnd make it easy to work with SSH using those \"common\" flags in\nauthorized_keys like:\ncommand=\"svnserve -t -r /home/svn --tunnel-user=bruno\" ssh-dss bla bla\n\nAnd as an idea i would like to make the same funcionality to git, as it is\nnot as easy today to do something like above :)\n\nWell, that's it for now! And i'm waiting for replys\n\nRegards,\nBruno\n\n-- \nBruno Ribas - ribas@c3sl.ufpr.br\nhttp://web.inf.ufpr.br/ribas\nC3SL: http://www.c3sl.ufpr.br \n"},{"id":"37769","messageId":"20070323004335.GA17773@spearce.org","threadId":"7358","inReplyTo":"20070322224829.GA7048@c3sl.ufpr.br","subject":"Re: Git / Subversion Interoperability","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-23T00:43:36Z","receivedAt":"2007-03-23T00:43:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Bruno Cesar Ribas wrote:\n> I'm going to apply for the Git / Subversion Interoperability project.\n> \n> I saw that there is no mentor yet assigned for the \"job\". So i'm sending this\n> mail to get some help to start the project by submiting to GSOC and begin to\n> work :)\n\nI'll consider being a mentor for this project, but I know very\nlittle of the SVN protocol or how its server behaves. I also\ndon't really have the time to learn those nitty-gritty details\nmyself, nor do I have any burning desire to.\n \n> My idea on this project is to create:\n> 1. git-svnserver\n> 2. write a backend for Subversion\n\nThese are two different approaches to the same problem. I think\nwhat was meant here was:\n\n> 1. git-svnserver\n\nHere we create a new program that can be invoked via SSH that runs\nthe server-side of the SVN protocol. Or we create a CGI program that\nacts as the extended-WebDAV server for SVN. Sam Vilain (mugwump\non #git) is suggesting using this approach as it probably will be\neasier to debug.\n\n> 2. write a backend for Subversion\n\nIn this case we try to reuse the existing SVN server code by\ncreating a library module that plugs into that system and uses a\nGit repository to store data, rather than say the existing bdb or\nfsfs stores. Git should be much faster than fsfs, use a lot less\ndisk space, and be just as atomic.\n\nBy using this approach you avoid the need to reimplement their\nnetwork protocol. Which is a nice part of this approach. But the\ndownside is you have to write code to run within their library and\naddress space, and that conforms to their storage API.\n\n\nBut either approach has a few key issues:\n\n- Assigning repository-wide revision numbers. Git doesn't have\nsuch a concept, but its key to SVN. These would need to be stored\nin a file so the server can quickly map from revision number to\nGit commit SHA-1. The reflogs may help here, but currently they\nalso expire. Any reflog that is being used to do this mapping\ncannot be expired, ever.\n\n- Branches. In SVN these are in the repository wide namespace,\nbut in Git they aren't. I imagine we'd want to just enforce the\nstandard layout that the SVN people recommened:\n\n /trunk/ --> refs/heads/master\n /branches/ --> refs/heads/ (minus master)\n /tags/ --> refs/tags/\n\nThat's all I can think of right now. But I'm sure there are more.\n\n> And make it easy to work with SSH using those \"common\" flags in\n> authorized_keys like:\n> command=\"svnserve -t -r /home/svn --tunnel-user=bruno\" ssh-dss bla bla\n\nNot following you...\n \n> And as an idea i would like to make the same funcionality to git, as it is\n> not as easy today to do something like above :)\n\nAgain, not following you...\n\n-- \nShawn.\n"},{"id":"37771","messageId":"Pine.LNX.4.64.0703230052570.2746@beast.quantumfyre.co.uk","threadId":"7358","inReplyTo":"20070323004335.GA17773@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-03-23T01:03:31Z","receivedAt":"2007-03-23T01:03:31Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 22 Mar 2007, Shawn O. Pearce wrote:\n\n> Bruno Cesar Ribas wrote:\n>> 2. write a backend for Subversion\n>\n> In this case we try to reuse the existing SVN server code by\n> creating a library module that plugs into that system and uses a\n> Git repository to store data, rather than say the existing bdb or\n> fsfs stores. Git should be much faster than fsfs, use a lot less\n> disk space, and be just as atomic.\n>\n> By using this approach you avoid the need to reimplement their\n> network protocol. Which is a nice part of this approach. But the\n> downside is you have to write code to run within their library and\n> address space, and that conforms to their storage API.\n\nThis might run headlong into some of the issues facing the libification \nproject - in particular the tendancy of git code to die as a primary error \nhandling mechanism. This approach may not viable without access to a \nlibified git?\n\n> But either approach has a few key issues:\n>\n> - Assigning repository-wide revision numbers. Git doesn't have\n> such a concept, but its key to SVN. These would need to be stored\n> in a file so the server can quickly map from revision number to\n> Git commit SHA-1. The reflogs may help here, but currently they\n> also expire. Any reflog that is being used to do this mapping\n> cannot be expired, ever.\n\nYou could probably do something similar to the system used by \ngit-svnimport to record the Subversion revision to git SHA1 mapping - \nperhaps with a hook script to update?\n\n>\n> - Branches. In SVN these are in the repository wide namespace,\n> but in Git they aren't. I imagine we'd want to just enforce the\n> standard layout that the SVN people recommened:\n>\n> /trunk/ --> refs/heads/master\n> /branches/ --> refs/heads/ (minus master)\n> /tags/ --> refs/tags/\n\nThat would probably be good enough for the majority of \none-project-per-repo Subversion projects at least. Though there is still \nthe issue that Subversion will actually let you create a \"tag\" simply by \ncommitting whatever you currently have in your working copy (including \nlocalally modified files ... yeuch).\n\n>\n> That's all I can think of right now. But I'm sure there are more.\n\nProperties are probably the next biggest headache. Subversion allows you \nto associate arbitrary keyword value pairs with files (which are \nversioned) and with revisions (which are not versioned). You would need \nto find someway to support this in git. Since revision properties are \ndisabled by default in Subversion you may be able to simply disallow them \npermanently - but I don't know anything about the Subversion protocol ...\n\n-- \nJulian\n\n ---\nPractical politics consists in ignoring facts.\n \t\t-- Henry Adams\n"},{"id":"37774","messageId":"20070323012422.GC17773@spearce.org","threadId":"7358","inReplyTo":"Pine.LNX.4.64.0703230052570.2746@beast.quantumfyre.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-23T01:24:23Z","receivedAt":"2007-03-23T01:24:23Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Julian Phillips wrote:\n> On Thu, 22 Mar 2007, Shawn O. Pearce wrote:\n> >Bruno Cesar Ribas wrote:\n> >>2. write a backend for Subversion\n> >\n> >In this case we try to reuse the existing SVN server code by\n> >creating a library module that plugs into that system\n...\n> >downside is you have to write code to run within their library and\n> >address space, and that conforms to their storage API.\n> \n> This might run headlong into some of the issues facing the libification \n> project - in particular the tendancy of git code to die as a primary error \n> handling mechanism. This approach may not viable without access to a \n> libified git?\n\nYes, exactly. The libification won't be ready early enough for\nthis project. So that does make it more difficult. But this just\npoints out another reason why libification might be useful. ;-)\n\n> >- Branches. In SVN these are in the repository wide namespace,\n> >but in Git they aren't. I imagine we'd want to just enforce the\n> >standard layout that the SVN people recommened:\n...\n> That would probably be good enough for the majority of \n> one-project-per-repo Subversion projects at least. Though there is still \n> the issue that Subversion will actually let you create a \"tag\" simply by \n> committing whatever you currently have in your working copy (including \n> localally modified files ... yeuch).\n\nHeh. People do weird things. ;-)\n \n> >That's all I can think of right now. But I'm sure there are more.\n> \n> Properties are probably the next biggest headache. Subversion allows you \n> to associate arbitrary keyword value pairs with files (which are \n> versioned) and with revisions (which are not versioned). You would need \n> to find someway to support this in git. Since revision properties are \n> disabled by default in Subversion you may be able to simply disallow them \n> permanently - but I don't know anything about the Subversion protocol ...\n\nI thought about the properties, but didn't bother to write anything\non that subject as we may just be able to say \"look, properties\nare not supported in git-svnserver, so don't try to use them\".\n\nThe git-svnserver is meant to help users migrate to Git, not to offer\nup all of SVNs features and warts. A big part of this project may\njust be deciding what features we are willing to try to emulate.\n\n-- \nShawn.\n"},{"id":"37775","messageId":"Pine.LNX.4.64.0703230128330.4001@beast.quantumfyre.co.uk","threadId":"7358","inReplyTo":"20070323012422.GC17773@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-03-23T01:36:11Z","receivedAt":"2007-03-23T01:36:11Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 22 Mar 2007, Shawn O. Pearce wrote:\n\n> Julian Phillips wrote:\n>> That would probably be good enough for the majority of\n>> one-project-per-repo Subversion projects at least. Though there is still\n>> the issue that Subversion will actually let you create a \"tag\" simply by\n>> committing whatever you currently have in your working copy (including\n>> localally modified files ... yeuch).\n>\n> Heh. People do weird things. ;-)\n\nWell, I don't think there would be too many complaints if a git-based \nSubversion server didn't support such methods of creating tags ... ;)\n\n>\n>>> That's all I can think of right now. But I'm sure there are more.\n>>\n>> Properties are probably the next biggest headache. Subversion allows you\n>> to associate arbitrary keyword value pairs with files (which are\n>> versioned) and with revisions (which are not versioned). You would need\n>> to find someway to support this in git. Since revision properties are\n>> disabled by default in Subversion you may be able to simply disallow them\n>> permanently - but I don't know anything about the Subversion protocol ...\n>\n> I thought about the properties, but didn't bother to write anything\n> on that subject as we may just be able to say \"look, properties\n> are not supported in git-svnserver, so don't try to use them\".\n\nIndeed. That's what I was aiming at with the the last sentence (not very \nclearly unfortunately). It would be nice if the server could tell the \nclient that properties are not supported ... but I doubt that it can, \nsince they are fundamental part of Subversion.\n\nIn particular it's how the client finds out about things like symlinks and \nline ending conversion. It may be necessary to provide some basic support \nfor some of the properties in the svn:... namespace in order for the \nSubversion repo access library not to refuse to talk to the git server.\n\n>\n> The git-svnserver is meant to help users migrate to Git, not to offer\n> up all of SVNs features and warts. A big part of this project may\n> just be deciding what features we are willing to try to emulate.\n\nIndeed. It sounds like an interesting idea. Anything that increases the \npossibilty of my convincing the appropriate people to migrate my work \nproject ... ;)\n\n-- \nJulian\n\n ---\n\"From there to here, from here to there, funny things are everywhere.\"\n-- Dr. Seuss\n"},{"id":"37805","messageId":"20070323103426.GA15923@diana.vm.bytemark.co.uk","threadId":"7358","inReplyTo":"Pine.LNX.4.64.0703230128330.4001@beast.quantumfyre.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-23T10:34:26Z","receivedAt":"2007-03-23T10:34:26Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:\n\n> On Thu, 22 Mar 2007, Shawn O. Pearce wrote:\n>\n> > I thought about the properties, but didn't bother to write\n> > anything on that subject as we may just be able to say \"look,\n> > properties are not supported in git-svnserver, so don't try to use\n> > them\".\n>\n> Indeed. That's what I was aiming at with the the last sentence (not\n> very clearly unfortunately). It would be nice if the server could\n> tell the client that properties are not supported ... but I doubt\n> that it can, since they are fundamental part of Subversion.\n>\n> In particular it's how the client finds out about things like\n> symlinks and line ending conversion. It may be necessary to provide\n> some basic support for some of the properties in the svn:...\n> namespace in order for the Subversion repo access library not to\n> refuse to talk to the git server.\n\nMaybe the pragmatic solution would be to have built-in handling of a\nfew properties such as svn:executable and svn:ignore that have git\nequivalents, and just emulate all other properties with files.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"37815","messageId":"eu0njb$q3b$1@sea.gmane.org","threadId":"7358","inReplyTo":"20070323004335.GA17773@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-23T14:21:20Z","receivedAt":"2007-03-23T14:21:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn O. Pearce wrote:\n\n> - Assigning repository-wide revision numbers.  Git doesn't have\n> such a concept, but its key to SVN.  These would need to be stored\n> in a file so the server can quickly map from revision number to\n> Git commit SHA-1.  The reflogs may help here, but currently they\n> also expire.  Any reflog that is being used to do this mapping\n> cannot be expired, ever.\n\nAnother idea is to use lightweight tags for that, especially now\nwith packed refs support in git.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"37819","messageId":"20070323152102.GA4818@c3sl.ufpr.br","threadId":"7358","inReplyTo":"20070323103426.GA15923@diana.vm.bytemark.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Bruno Cesar Ribas","fromEmail":"ribas@c3sl.ufpr.br","sentAt":"2007-03-23T15:21:02Z","receivedAt":"2007-03-23T15:21:02Z","isPatch":false,"sender":{"key":"ribas@c3sl.ufpr.br","avatar":null},"body":"On Fri, Mar 23, 2007 at 11:34:26AM +0100, Karl Hasselström wrote:\n> On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:\n> \n> > On Thu, 22 Mar 2007, Shawn O. Pearce wrote:\n> >\n> > > I thought about the properties, but didn't bother to write\n> > > anything on that subject as we may just be able to say \"look,\n> > > properties are not supported in git-svnserver, so don't try to use\n> > > them\".\n> >\n> > Indeed. That's what I was aiming at with the the last sentence (not\n> > very clearly unfortunately). It would be nice if the server could\n> > tell the client that properties are not supported ... but I doubt\n> > that it can, since they are fundamental part of Subversion.\n> >\n> > In particular it's how the client finds out about things like\n> > symlinks and line ending conversion. It may be necessary to provide\n> > some basic support for some of the properties in the svn:...\n> > namespace in order for the Subversion repo access library not to\n> > refuse to talk to the git server.\n> \n> Maybe the pragmatic solution would be to have built-in handling of a\n> few properties such as svn:executable and svn:ignore that have git\n> equivalents, and just emulate all other properties with files.\n\nMy idea is to write the git-svnserver!!! I think it will be easier.\n\nTo begin coding, i plan to write basic functions [updade,commit,checkout,\ncopy,merge,...] then start to implement most \"complex\" instructions.\n\nAs spearce said before, the idea of this is to migrate from svn to git\nwithout many trouble in transition, so basic can work as the initial thought.\n\n> \n> -- \n> Karl Hasselström, kha@treskal.com\n> www.treskal.com/kalle\n\n-- \nBruno Ribas - ribas@c3sl.ufpr.br\nhttp://web.inf.ufpr.br/ribas\nC3SL: http://www.c3sl.ufpr.br \n"},{"id":"37822","messageId":"20070323154851.GA22517@diana.vm.bytemark.co.uk","threadId":"7358","inReplyTo":"20070323152102.GA4818@c3sl.ufpr.br","subject":"Re: Git / Subversion Interoperability","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-23T15:48:51Z","receivedAt":"2007-03-23T15:48:51Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-23 12:21:02 -0300, Bruno Cesar Ribas wrote:\n\n> On Fri, Mar 23, 2007 at 11:34:26AM +0100, Karl Hasselström wrote:\n>\n> > Maybe the pragmatic solution would be to have built-in handling of\n> > a few properties such as svn:executable and svn:ignore that have\n> > git equivalents, and just emulate all other properties with files.\n>\n> My idea is to write the git-svnserver!!! I think it will be easier.\n\nUmm ... what I said was intended as a possible way to do the mapping\nbetween svn and git concepts. I was under the impresson that\ngit-svnserver would need to use such a mapping.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"37830","messageId":"Pine.LNX.4.64.0703231758020.8105@reaper.quantumfyre.co.uk","threadId":"7358","inReplyTo":"20070323152102.GA4818@c3sl.ufpr.br","subject":"Re: Git / Subversion Interoperability","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-03-23T18:13:16Z","receivedAt":"2007-03-23T18:13:16Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Fri, 23 Mar 2007, Bruno Cesar Ribas wrote:\n\n> On Fri, Mar 23, 2007 at 11:34:26AM +0100, Karl Hasselström wrote:\n>> On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:\n>>\n>>> In particular it's how the client finds out about things like\n>>> symlinks and line ending conversion. It may be necessary to provide\n>>> some basic support for some of the properties in the svn:...\n>>> namespace in order for the Subversion repo access library not to\n>>> refuse to talk to the git server.\n>>\n>> Maybe the pragmatic solution would be to have built-in handling of a\n>> few properties such as svn:executable and svn:ignore that have git\n>> equivalents, and just emulate all other properties with files.\n>\n> My idea is to write the git-svnserver!!! I think it will be easier.\n\nAlmost certainly - I don't think anyone was proposing otherwise? The repo \naccess library I was referring to is one of the libraries used by the \nclient - specifically the one used to talk to a remote server (I think \nit may be called ra or something? I'm not familiar with Subversion \ninternals).\n\n>\n> To begin coding, i plan to write basic functions [updade,commit,checkout,\n> copy,merge,...] then start to implement most \"complex\" instructions.\n\nOk, but ...\n\nI don't think that merge is a basic function in Subversion. I believe \nthat it is all client side using diffs provided by the server into the \nworking copy, certainly it is up to the user to commit the result. \nUnfortunately that would make it necesary to do some very nasty work \nserver side to try and autodetect merges - git-svnimport (and git-svn?) \nalready does this sort of thing. There are noises about this changing at \nsome point though ...\n\n>\n> As spearce said before, the idea of this is to migrate from svn to git\n> without many trouble in transition, so basic can work as the initial thought.\n\nWhich means that you have to at the very least support the basic \noperations of the Subversion supplied svn client. And my point was that I \nwouldn't be surprised if this meant dealing with properties, since \nsubversion uses properties to expose things like the log message, commit \ndate and author for revisions and other misc. info for files. You may not \neven be able to get commit/checkout working without _some_ property \nsupport.\n\nHaving said that, I don't think it would be a _bad_ thing if this work \nwent far enough that one could replace a Subversion server without any \nusers even noticing ;)\n\n-- \nJulian\n\n ---\nYou know you're using the computer too much when:\na party sucks if theres no computers to use.\n \t-- electrofreak"},{"id":"37836","messageId":"20070323193427.GA12126@c3sl.ufpr.br","threadId":"7358","inReplyTo":"Pine.LNX.4.64.0703231758020.8105@reaper.quantumfyre.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Bruno Cesar Ribas","fromEmail":"ribas@c3sl.ufpr.br","sentAt":"2007-03-23T19:34:27Z","receivedAt":"2007-03-23T19:34:27Z","isPatch":false,"sender":{"key":"ribas@c3sl.ufpr.br","avatar":null},"body":"On Fri, Mar 23, 2007 at 06:13:16PM +0000, Julian Phillips wrote:\n> On Fri, 23 Mar 2007, Bruno Cesar Ribas wrote:\n> \n> >On Fri, Mar 23, 2007 at 11:34:26AM +0100, Karl Hasselström wrote:\n> >>On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:\n> >>\n> >>>In particular it's how the client finds out about things like\n> >>>symlinks and line ending conversion. It may be necessary to provide\n> >>>some basic support for some of the properties in the svn:...\n> >>>namespace in order for the Subversion repo access library not to\n> >>>refuse to talk to the git server.\n> >>\n> >>Maybe the pragmatic solution would be to have built-in handling of a\n> >>few properties such as svn:executable and svn:ignore that have git\n> >>equivalents, and just emulate all other properties with files.\n> >\n> >My idea is to write the git-svnserver!!! I think it will be easier.\n> \n> Almost certainly - I don't think anyone was proposing otherwise? The repo \n> access library I was referring to is one of the libraries used by the \n> client - specifically the one used to talk to a remote server (I think \n> it may be called ra or something? I'm not familiar with Subversion \n> internals).\n> \n> >\n> >To begin coding, i plan to write basic functions [updade,commit,checkout,\n> >copy,merge,...] then start to implement most \"complex\" instructions.\n> \n> Ok, but ...\n> \n> I don't think that merge is a basic function in Subversion. I believe \n> that it is all client side using diffs provided by the server into the \n> working copy, certainly it is up to the user to commit the result. \n> Unfortunately that would make it necesary to do some very nasty work \n> server side to try and autodetect merges - git-svnimport (and git-svn?) \n> already does this sort of thing. There are noises about this changing at \n> some point though ...\n> \n> >\n> >As spearce said before, the idea of this is to migrate from svn to git\n> >without many trouble in transition, so basic can work as the initial \n> >thought.\n> \n> Which means that you have to at the very least support the basic \n> operations of the Subversion supplied svn client. And my point was that I \n> wouldn't be surprised if this meant dealing with properties, since \n> subversion uses properties to expose things like the log message, commit \n> date and author for revisions and other misc. info for files. You may not \n> even be able to get commit/checkout working without _some_ property \n> support.\n> \n> Having said that, I don't think it would be a _bad_ thing if this work \n> went far enough that one could replace a Subversion server without any \n> users even noticing ;)\n\nI began to think about it... the idea to have a git-svnserver is to move from\nsvn to git and get my dev team not to worry about the transition at the\nstart, but it is a good idea to make people get moving to git idea of\ndevlopment, right?\nOr the main idea is that we will have a group devloping under git repo and a\ngroup under svn-gateway for the same project? I don't see a point to have\nthis! when a repo type is defined everyone must begin to understand that way,\neven if it was changed in the middle of the project.\n\nWhen decided above, we can define our dev of this project. Because as people\nmake those 'strange' stuff at svn repo that git won't support we will have to\nmake some workarounds to get git understand those things, and if we have some\npeople migrated do git and some using svn they will not see some 'svn tags'\non git repo.\n\nThat's why i think it should be a transition thing from svn to git.\n\n\n\n> \n> -- \n> Julian\n> \n> ---\n> You know you're using the computer too much when:\n> a party sucks if theres no computers to use.\n> \t-- \n> \telectrofreak\n\n\n-- \nBruno Ribas - ribas@c3sl.ufpr.br\nhttp://web.inf.ufpr.br/ribas\nC3SL: http://www.c3sl.ufpr.br \n"},{"id":"37839","messageId":"20070323233036.77325e5a@athlon","threadId":"7358","inReplyTo":"Pine.LNX.4.64.0703230052570.2746@beast.quantumfyre.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Christian Wiese","fromEmail":"morfoh@opensde.org","sentAt":"2007-03-23T21:30:36Z","receivedAt":"2007-03-23T21:30:36Z","isPatch":false,"sender":{"key":"morfoh@opensde.org","avatar":null},"body":"Hello,\n\n> > - Branches. In SVN these are in the repository wide namespace,\n> > but in Git they aren't. I imagine we'd want to just enforce the\n> > standard layout that the SVN people recommened:\n> >\n> > /trunk/ --> refs/heads/master\n> > /branches/ --> refs/heads/ (minus master)\n> > /tags/ --> refs/tags/\n> \n> That would probably be good enough for the majority of \n> one-project-per-repo Subversion projects at least. Though there is\n> still the issue that Subversion will actually let you create a \"tag\"\n> simply by committing whatever you currently have in your working copy\n> (including localally modified files ... yeuch).\n\nIf the proposed solution just supports \"one-project-per-repo\"\nSubversion projects then you won't attract much projects which are\ncurrently using subversion. I don't know many svn repos of this kind.\n\nWhat you should also consider, is that a project might have splitted a\nproject within a repo into smaller subprojects.\nI'm currently facing this issue while trying to migrate from svn to git\nwithin my local working environment to gather experience while working\nwith git to be able to effectively \"sell\" git to the other people of\nour project and provide a smooth migration path for them.\n\nChris\n"},{"id":"37844","messageId":"46044DF6.6070902@midwinter.com","threadId":"7358","inReplyTo":"20070323233036.77325e5a@athlon","subject":"Re: Git / Subversion Interoperability","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-03-23T22:00:22Z","receivedAt":"2007-03-23T22:00:22Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Christian Wiese wrote:\n> I'm currently facing this issue while trying to migrate from svn to git\n> within my local working environment to gather experience while working\n> with git to be able to effectively \"sell\" git to the other people of\n> our project and provide a smooth migration path for them.\n> \n\nWould a git svn server be of interest in such a situation, though? \nThat's exactly the situation I'm in, and git-svn is doing an admirable \njob of integrating the two environments without disrupting the folks who \nare happy with svn. It seems like the git svn server would be useful in \nthe opposite environment, where you have a git project that people want \nto access with svn tools (e.g. because there's no git integration in an \nIDE or whatever.)\n\nMaybe I'm just misunderstanding what the server in question would do, \nbut it seems like it's not likely to be that useful in cases where you \nalready have a real svn server running and holding the canonical copy of \nthe project.\n\n-Steve\n"},{"id":"37848","messageId":"Pine.LNX.4.63.0703231357170.11744@qynat.qvtvafvgr.pbz","threadId":"7358","inReplyTo":"20070323193427.GA12126@c3sl.ufpr.br","subject":"Re: Git / Subversion Interoperability","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-03-23T22:05:55Z","receivedAt":"2007-03-23T22:05:55Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Fri, 23 Mar 2007, Bruno Cesar Ribas wrote:\n\n> On Fri, Mar 23, 2007 at 06:13:16PM +0000, Julian Phillips wrote:\n>> On Fri, 23 Mar 2007, Bruno Cesar Ribas wrote:\n>>\n>> Having said that, I don't think it would be a _bad_ thing if this work\n>> went far enough that one could replace a Subversion server without any\n>> users even noticing ;)\n>\n> I began to think about it... the idea to have a git-svnserver is to move from\n> svn to git and get my dev team not to worry about the transition at the\n> start, but it is a good idea to make people get moving to git idea of\n> devlopment, right?\n> Or the main idea is that we will have a group devloping under git repo and a\n> group under svn-gateway for the same project? I don't see a point to have\n> this! when a repo type is defined everyone must begin to understand that way,\n> even if it was changed in the middle of the project.\n>\n> When decided above, we can define our dev of this project. Because as people\n> make those 'strange' stuff at svn repo that git won't support we will have to\n> make some workarounds to get git understand those things, and if we have some\n> people migrated do git and some using svn they will not see some 'svn tags'\n> on git repo.\n>\n> That's why i think it should be a transition thing from svn to git.\n\nif you just want to transition everyone on a project from svn to git then you \ndon't need a git-svn server, you just need a translation tool\n\nwhat a git-svn server gives you is the ability to have some people use svn \n(becouse 'git is too complicated') while others use git.\n\nthink about sourceforge as an example. they only want to provide one version \ncontrol tool, they started with cvs and are migrating to svn, but if they could \nput in a git server and git-svn server and support both.\n\nthink of it as 'one version control server to rule them all' (and then encourage \npeople to do git-hg-server, git-arch-server, git-darc-server, etc)\n\nas far as I can tell (with the exception of recording explicit renames) the git \nfunctionality is a strict superset of all the other version control tools, so it \nshould be possible to emulate them with git. svn is just the biggest \nbang-for-the-buck in terms of number of users.\n\nDavid Lang\n"},{"id":"37845","messageId":"Pine.LNX.4.64.0703231758090.6485@iabervon.org","threadId":"7358","inReplyTo":"20070323193427.GA12126@c3sl.ufpr.br","subject":"Re: Git / Subversion Interoperability","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-03-23T22:11:22Z","receivedAt":"2007-03-23T22:11:22Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 23 Mar 2007, Bruno Cesar Ribas wrote:\n\n> I began to think about it... the idea to have a git-svnserver is to move from\n> svn to git and get my dev team not to worry about the transition at the\n> start, but it is a good idea to make people get moving to git idea of\n> devlopment, right?\n> Or the main idea is that we will have a group devloping under git repo and a\n> group under svn-gateway for the same project? I don't see a point to have\n> this! when a repo type is defined everyone must begin to understand that way,\n> even if it was changed in the middle of the project.\n\nIt's been useful in the past (when Wine went from CVS to git) to make it \nunnecessary for all developers to switch which software they're using at \nthe same time. With that particular project, it really went from having a \nCVS repository and a git gateway to having a git repository and a CVS \ngateway without users seeing a difference (except that the CVS access was \nsuddenly faster).\n\nThen, of course, the git users were able to start making use of the more \nflexible representation of history, since the official repository then \ncould represent it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"37863","messageId":"20070324064130.GC25863@spearce.org","threadId":"7358","inReplyTo":"20070323103426.GA15923@diana.vm.bytemark.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-24T06:41:30Z","receivedAt":"2007-03-24T06:41:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Karl Hasselstr??m wrote:\n> On 2007-03-23 01:36:11 +0000, Julian Phillips wrote:\n> > Indeed. That's what I was aiming at with the the last sentence (not\n> > very clearly unfortunately). It would be nice if the server could\n> > tell the client that properties are not supported ... but I doubt\n> > that it can, since they are fundamental part of Subversion.\n> >\n> > In particular it's how the client finds out about things like\n> > symlinks and line ending conversion. It may be necessary to provide\n> > some basic support for some of the properties in the svn:...\n> > namespace in order for the Subversion repo access library not to\n> > refuse to talk to the git server.\n> \n> Maybe the pragmatic solution would be to have built-in handling of a\n> few properties such as svn:executable and svn:ignore that have git\n> equivalents, and just emulate all other properties with files.\n\nThat is not a bad idea at all. We could easily do\n\n svn:executable -> (mode & 0111);\n svn:ignore -> .gitignore;\n\nI'm sure there are others, but they are the only two Karl mentioned,\nand that I know of off the top of my head. ;-)\n\nAdditional random properties could just be written out to .gitsvnprop\nin the parent directory.\n\nHere's another SVN feature that we might have to actually emulate:\nlocks. Apparently clients can \"lock\" a file, preventing others\nfrom editing that same file. This is good for say artwork where\nthe file format is a binary thing that just cannot be merged.\nSome users may actually be using SVN for exactly this reason.\nReplacing it for some users may require that feature.\n\nHeck, the F!@&@#*!@&@!*! POS (not SVN) that I have to use at my day\njob can *only* work in this mode (exclusive lock file) and people\nthere still don't know how two different developers can safely edit\nthe same Java file at the same time without that exclusive lock\nsystem in place. They are absolutely terrified of auto-merges like\nwhat Git does. ;-)\n\nThen they same users go off and incorrectly hand-merge stuff anyway.\nStuff that xdiff's 3-way file merge would have done correctly\nwithout any problems. Argh!\n\n-- \nShawn.\n"},{"id":"37864","messageId":"20070324064556.GD25863@spearce.org","threadId":"7358","inReplyTo":"eu0njb$q3b$1@sea.gmane.org","subject":"Re: Git / Subversion Interoperability","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-24T06:45:56Z","receivedAt":"2007-03-24T06:45:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Shawn O. Pearce wrote:\n> \n> > - Assigning repository-wide revision numbers.  Git doesn't have\n> > such a concept, but its key to SVN.  These would need to be stored\n> > in a file so the server can quickly map from revision number to\n> > Git commit SHA-1.  The reflogs may help here, but currently they\n> > also expire.  Any reflog that is being used to do this mapping\n> > cannot be expired, ever.\n> \n> Another idea is to use lightweight tags for that, especially now\n> with packed refs support in git.\n\nYes, not a bad idea.\n\nExcept the packed refs file can have variable sized records. It has\nno faster access path than to just scan it. Some SVN repositories\nhave revision counts up into the 5 and 6 digits. These would take\nquite a while to scan, even as packed refs. ;-)\n\nI'm inclined to lean towards a really simple binary flat file holding\njust 20 byte SHA-1s, in \"SVN order\". Then its just a simple array\nindex operation to locate the correct Git commit. And adding a\nnew commit is really just an append to the end operation.\n\nYea, I know, append == bad on some older Linux systems, and is\nhard to roll back if you partially appended as it gets into some\npossible nasty mess with truncate, but I think that when combined\nwith a simple lock file we can make it safe enough that its not\nreally going to be a problem.\n\n-- \nShawn.\n"},{"id":"37865","messageId":"20070324065632.GE25863@spearce.org","threadId":"7358","inReplyTo":"46044DF6.6070902@midwinter.com","subject":"Re: Git / Subversion Interoperability","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-24T06:56:32Z","receivedAt":"2007-03-24T06:56:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steven Grimm wrote:\n> Christian Wiese wrote:\n> >I'm currently facing this issue while trying to migrate from svn to git\n> >within my local working environment to gather experience while working\n> >with git to be able to effectively \"sell\" git to the other people of\n> >our project and provide a smooth migration path for them.\n> > \n> \n> Would a git svn server be of interest in such a situation, though? \n> That's exactly the situation I'm in, and git-svn is doing an admirable \n> job of integrating the two environments without disrupting the folks who \n> are happy with svn. It seems like the git svn server would be useful in \n> the opposite environment, where you have a git project that people want \n> to access with svn tools (e.g. because there's no git integration in an \n> IDE or whatever.)\n> \n> Maybe I'm just misunderstanding what the server in question would do, \n> but it seems like it's not likely to be that useful in cases where you \n> already have a real svn server running and holding the canonical copy of \n> the project.\n\nWell, it does make it harder to transparently remove the SVN server\nand drop in a Git based one. ;-)\n\nBut I think Steven is right; like the git-cvsserver you can't do\neverything with git-svnserver that you could have done with SVN or\nwith Git. But you can get basic access to the Git repository and\nstill work with it through SVN based tools.\n\nIf that means that we export things according to the suggested\nSVN repository layout, so be it. Its difficult to argue with\nus when we've followed the SVN advice. ;-)\n\nChristian pointed out that some projects may have different \"slightly\nrelated\" modules stored in the same repository, and have come to\nexpect this to work in certain ways. Moving to Git is difficult\nfor them as git-svnimport and git-svn can have a difficult time\ndivining the correct layout from the soup that is available in SVN.\n\nBut its also hard for Git to export soup back. That is, even once\nwe've successfully decoded the soup we don't really have good\nsubmodule support, so we cannot (easily) take two different Git\nrepositories (one per \"slightly related\" module) and export them\nunder a single SVN name/revision-space.\n\n-- \nShawn.\n"},{"id":"37890","messageId":"20070324185517.GA10876@diana.vm.bytemark.co.uk","threadId":"7358","inReplyTo":"20070324064130.GC25863@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-24T18:55:17Z","receivedAt":"2007-03-24T18:55:17Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-24 02:41:30 -0400, Shawn O. Pearce wrote:\n\n> That is not a bad idea at all. We could easily do\n>\n> svn:executable -> (mode & 0111);\n> svn:ignore -> .gitignore;\n>\n> I'm sure there are others, but they are the only two Karl mentioned,\n> and that I know of off the top of my head. ;-)\n\nThese are the two that git-svnimport handles. I don't think it knows\nabout any other subversion properties.\n\nThere is a slight problem with directly converting between svn:ignore\nand .gitignore, though: the semantics are only almost the same.\nSpecifically, git's ignore patters are recursive (applies to\nsubdirectories) while subversion's are not. But it's not a big\nproblem.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"37894","messageId":"Pine.LNX.4.64.0703241258560.6730@woody.linux-foundation.org","threadId":"7358","inReplyTo":"20070324185517.GA10876@diana.vm.bytemark.co.uk","subject":"Re: Git / Subversion Interoperability","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-24T20:13:06Z","receivedAt":"2007-03-24T20:13:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 24 Mar 2007, Karl Hasselström wrote:\n>\n> There is a slight problem with directly converting between svn:ignore\n> and .gitignore, though: the semantics are only almost the same.\n> Specifically, git's ignore patters are recursive (applies to\n> subdirectories) while subversion's are not. But it's not a big\n> problem.\n\nYou should be able to use an \"absolute\" path-name to ignore something in \n.gitignore, in which case it is not used recursively.\n\nSo if your .gitignore looks like\n\n\t*.o\n\nit means that it recursively ignores all *.o files starting at that level.\n\nHOWEVER, if you write it as\n\n\t/*.o\n\nit means that it ignores *.o files only *within* that level (so it's \n\"absolute\" wrt the particular .gitignore file, not globally).\n\nSo you can have both behaviours.\n\n[ I think the exact behaviour is: if there is a '/' anywhere in the name, \n it's not a recursive match and has to match the file exactly, but \n somebody like Junio should probably back me up on that ]\n\n\t\tLinus"},{"id":"37896","messageId":"20070324203129.GA25571@muzzle","threadId":"7358","inReplyTo":"20070322224829.GA7048@c3sl.ufpr.br","subject":"Re: Git / Subversion Interoperability","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-03-24T20:31:29Z","receivedAt":"2007-03-24T20:31:29Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Bruno Cesar Ribas wrote:\n> Hello,\n> \n> I'm going to apply for the Git / Subversion Interoperability project.\n> \n> I saw that there is no mentor yet assigned for the \"job\". So i'm sending this\n> mail to get some help to start the project by submiting to GSOC and begin to\n> work :)\n\nI work on git-svn and I can certainly help you in some ways. However\nI'm uncomfortable committing myself to this because of time constraints;\nso I won't be signing up as a mentor. Sorry.\n\n> My idea on this project is to create:\n> 1. git-svnserver\n\nI'm not familiar with the internals of the SVN protocol, and my work\nwith git-svn has sufficiently frightened me away from wanting to\ninvestigate further :).\n\nI also suggest you write a HTTP/DAV-based server/plugin/cgi instead of\nrelying on the SVN protocol. In my experience svnserve itself is quite\nfinnicky.\n\n> 2. write a backend for Subversion\n\nOne key difference between git and Subversion is the design emphasis on\ndata structures versus design emphasis on code/APIs. Subversion\ncertainly tries to keep their APIs stable (and for the most part seem\nsuccessful), but their publically available storage backends are\ndefinitely lacking.\n\nI'm not sure this part of the project is going to help git very much\nunless it speeds up the libification effort.\n\n> And make it easy to work with SSH using those \"common\" flags in\n> authorized_keys like:\n> command=\"svnserve -t -r /home/svn --tunnel-user=bruno\" ssh-dss bla bla\n> \n> And as an idea i would like to make the same funcionality to git, as it is\n> not as easy today to do something like above :)\n\nOne reason to work on your project is to help SVN users who have no idea\nwhat UNIX, ssh, and tunneling are. This is also why I recommend working\non the HTTP/DAV protocol instead.\n\n-- \nEric Wong\n"},{"id":"37897","messageId":"7vfy7ufkdn.fsf@assigned-by-dhcp.cox.net","threadId":"7358","inReplyTo":"Pine.LNX.4.64.0703241258560.6730@woody.linux-foundation.org","subject":"Re: Git / Subversion Interoperability","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-24T20:37:40Z","receivedAt":"2007-03-24T20:37:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> So if your .gitignore looks like\n>\n> \t*.o\n>\n> it means that it recursively ignores all *.o files starting at that level.\n>\n> HOWEVER, if you write it as\n>\n> \t/*.o\n>\n> it means that it ignores *.o files only *within* that level (so it's \n> \"absolute\" wrt the particular .gitignore file, not globally).\n>\n> So you can have both behaviours.\n>\n> [ I think the exact behaviour is: if there is a '/' anywhere in the name, \n> it's not a recursive match and has to match the file exactly, but \n> somebody like Junio should probably back me up on that ]\n> \t\tLinus\n\nYes, that is what dir.c::excluded_1() says. If it does not have\n'/' then fnmatch the basename, otherwise fnmatch with\nFNM_PATHNAME. So I think if you write\n\n /obj/*.o\n\nyou can ignore *.o files in obj/ directory (but won't ignore a/obj/b.o).\n"},{"id":"37898","messageId":"20070324203813.GB25571@muzzle","threadId":"7358","inReplyTo":"20070324064556.GD25863@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-03-24T20:38:13Z","receivedAt":"2007-03-24T20:38:13Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"\"Shawn O. Pearce\" wrote:\n> Jakub Narebski wrote:\n> > Shawn O. Pearce wrote:\n> > \n> > > - Assigning repository-wide revision numbers.  Git doesn't have\n> > > such a concept, but its key to SVN.  These would need to be stored\n> > > in a file so the server can quickly map from revision number to\n> > > Git commit SHA-1.  The reflogs may help here, but currently they\n> > > also expire.  Any reflog that is being used to do this mapping\n> > > cannot be expired, ever.\n> > \n> > Another idea is to use lightweight tags for that, especially now\n> > with packed refs support in git.\n> \n> Yes, not a bad idea.\n> \n> Except the packed refs file can have variable sized records. It has\n> no faster access path than to just scan it. Some SVN repositories\n> have revision counts up into the 5 and 6 digits. These would take\n> quite a while to scan, even as packed refs. ;-)\n> \n> I'm inclined to lean towards a really simple binary flat file holding\n> just 20 byte SHA-1s, in \"SVN order\". Then its just a simple array\n> index operation to locate the correct Git commit. And adding a\n> new commit is really just an append to the end operation.\n\nThe rev_db implementation in git-svn is very similar to what you're\ndescribing. However, I decided on 41-byte (SHA1 ascii + \"\\n\") records\nsince it was easier to debug if any problems came up, and a ~50% size\nreduction wasn't worth the potential headache (I already had a lot of\nthose from just dealing with SVN :).\n\nThe biggest weakness of fixed records is that tags or sparsely worked on\nbranches waste a lot of disk space, but it hasn't been a huge problem\nfor me.\n\n-- \nEric Wong\n"},{"id":"37987","messageId":"4607382D.9050200@vilain.net","threadId":"7358","inReplyTo":"20070324065632.GE25863@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-03-26T03:04:13Z","receivedAt":"2007-03-26T03:04:13Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> But its also hard for Git to export soup back. That is, even once\n> we've successfully decoded the soup we don't really have good\n> submodule support, so we cannot (easily) take two different Git\n> repositories (one per \"slightly related\" module) and export them\n> under a single SVN name/revision-space.\n> \n\nSure you can: subprojects\n\nSam.\n"},{"id":"37988","messageId":"460738CB.2050707@vilain.net","threadId":"7358","inReplyTo":"20070324064130.GC25863@spearce.org","subject":"Re: Git / Subversion Interoperability","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-03-26T03:06:51Z","receivedAt":"2007-03-26T03:06:51Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> That is not a bad idea at all. We could easily do\n>\n> svn:executable -> (mode & 0111);\n> svn:ignore -> .gitignore;\n>\n> I'm sure there are others, but they are the only two Karl mentioned,\n> and that I know of off the top of my head. ;-)\n>\n> Additional random properties could just be written out to .gitsvnprop\n> in the parent directory.\n> \n\nThere are also the important properties \"svk:merge\" and \"svnmerge\",\nwhich allow you to notate when a revision has an extra parent. SVK\nand/or svnmerge should then be able to use the extra merge information\nwithout any extra work. Additionally, people might want to push back\nwith these properties.\n\nSam.\n"}]}