{"thread":{"id":"3213","subject":"Tracking and committing back to Subversion?","startedAt":"2006-02-01T22:51:40Z","lastAt":"2006-02-10T11:16:11Z","messageCount":12,"participants":["Sam Vilain","Eric Wong","Brian Smith","Seth Falcon","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15442","messageId":"1138834301.21899.40.camel@wilber.wgtn.cat-it.co.nz","threadId":"3213","inReplyTo":null,"subject":"Tracking and committing back to Subversion?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-01T22:51:40Z","receivedAt":"2006-02-01T22:51:40Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Hi all,\n\nHas anyone done any work on bidirectional access to SVN repositories?\nie, tracking and committing.\n\nThat would be porcelain that behaves like SVK (http://svk.elixus.org)\n\nIdeally it would probably need to link against the Subversion RA (remote\naccess) library, neon.\n\nI can see forsee two potential issues;\n\n 1. file properties - such as mime type, ignores and custom properties.\n Linus, when I asked you about this in Dunedin, you mentioned that\n there is a place at the end of the directory entry where this could\n fit without breaking backwards compatibility. Perhaps this could\n be an optional pointer to another directory node;\n\n /\n trunk/ # after all, we're tracking an SVN repo ;)\n MyModule/\n Makefile.PL\n MyModule.pm\n /\n svn:ignore\n\n is a directory object, with one file in this example;\n called svn:ignore. The contents of this file would be something\n like the .gitignore;\n\n Makefile\n Makefile.old\n blib\n ...etc...\n\n This configures the directory \"/trunk/MyModule\" to have a property\n \"svn:ignore\", which makes SVN ignore those files.\n\n 2. \"forensic\" file movement history - as opposed to the uncached,\n (and unversioned), automatic \"analytical\" file movement history.\n\n It would be easy for a tool to provide 100% interface compatibility\n with SVN client/SVK using properties, but properties that hang off\n the head rather than the file itself (so that they don't stuff up\n the ability to merge identical trees reached via independent\n paths). SVN calls these \"revision properties\". If a good\n convention is adopted for this, it could be used as a nice way to\n supplement git's automatic analysis of the revision history.\n\n So, then, git could support these three methods of finding\n revision history;\n\n 1. automatic/analytical, as at present. Cachable information,\n and such a cache would not form part of the revision history.\n\n 2. forensic, if using porcelain that supports it; this would\n form part of the revision history, but be out of band to the\n content.\n\n 3. (potentially) retrospective, for instance, somebody studying\n an old code base and tracking history for some reason - or\n even 'correcting' forensic revision history that is causing\n their advanced patch calculus algorithm to trip up (should\n someone be using git as a storage back-end for darcs, for\n instance)\n\n Ideally, it would be possible to distinguish between 2 and 3, of\n course this would require two head identifiers; the content head,\n and the revision history head.\n\nThis might seem like functionality not needed for merging kernel\ntrees ;) but I think it would add value to be able to make git truly\njoin the trump suit in the VCS deck (along with SVK, which can, for\ninstance, track Perforce and even git repositories).\n\nSam.\n"},{"id":"15552","messageId":"20060204054056.GB24314@Muzzle","threadId":"3213","inReplyTo":"1138834301.21899.40.camel@wilber.wgtn.cat-it.co.nz","subject":"Re: Tracking and committing back to Subversion?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-04T05:40:57Z","receivedAt":"2006-02-04T05:40:57Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Sam Vilain wrote:\n> Hi all,\n> \n> Has anyone done any work on bidirectional access to SVN repositories?\n> ie, tracking and committing.\n\nAFAIK, Not yet. But it's something that's been on the back of my mind\nfor a while. I've attempted similar things with Arch <-> SVN in the\npast but didn't get anything extremely robust going from Arch -> SVN\nalthough I'm pretty satisfied with my SVN -> Arch product\n(svn-arch-mirror).\n\n> That would be porcelain that behaves like SVK (http://svk.elixus.org)\n> \n> Ideally it would probably need to link against the Subversion RA (remote\n> access) library, neon.\n\nI prefer to use git-svnimport for pulling from svn since it's pretty\ngood at what it does. That already depends on SVN::Core and SVN::Ra.\nSVK is really nice tool, just a bit slow after I've been using git for a\nwhile.\n\n> I can see forsee two potential issues;\n> \n> 1. file properties - such as mime type, ignores and custom properties.\n> Linus, when I asked you about this in Dunedin, you mentioned that\n> there is a place at the end of the directory entry where this could\n> fit without breaking backwards compatibility. Perhaps this could\n> be an optional pointer to another directory node;\n\nMostly ignore-able, imho. svn:executable is the one that makes the most\nsense (and is easiest) to support.\n\nsvn:ignore <-> .gitignore mapping are pretty close (identical, save for\nrecursive properties that svn gets very wrong. I don't think svn:ignore\nis affected by line order, whereas .gitignore is a plain file and line\norder does matter.\n\nsvn:external is almost definitely better off ignored entirely when\ninterfacing with other RCSes\n\nsvn:keywords: I don't think there's a way to disable this like there\nis with CVS, is there? keywords are evil imho.\n\nI don't use or know much about the other properties...\n\n> 2. \"forensic\" file movement history - as opposed to the uncached,\n> (and unversioned), automatic \"analytical\" file movement history.\n> \n> It would be easy for a tool to provide 100% interface compatibility\n> with SVN client/SVK using properties, but properties that hang off\n> the head rather than the file itself (so that they don't stuff up\n> the ability to merge identical trees reached via independent\n> paths). SVN calls these \"revision properties\". If a good\n> convention is adopted for this, it could be used as a nice way to\n> supplement git's automatic analysis of the revision history.\n\nJust parsing the output of diff-tree -C and marking them in SVN as\ncopies/renames should be sufficient for letting SVN do its thing.\n\nDoing this kind of file movement history on the git side sounds like\noverkill to me. I was a _huge_ fan of logical file-identities in GNU\nArch in the past, but the complexity destroyed it from both a UI and\nperformance perspective.\n\n-- \nEric Wong\n"},{"id":"15578","messageId":"200602040727.30965.linuxfood@linuxfood.net","threadId":"3213","inReplyTo":"1138834301.21899.40.camel@wilber.wgtn.cat-it.co.nz","subject":"Re: Tracking and committing back to Subversion?","fromName":"Brian Smith","fromEmail":"linuxfood@linuxfood.net","sentAt":"2006-02-04T15:27:25Z","receivedAt":"2006-02-04T15:27:25Z","isPatch":false,"sender":{"key":"linuxfood@linuxfood.net","avatar":null},"body":"Well..\n\nOn Wednesday 01 February 2006 14:51, Sam Vilain wrote:\n> Hi all,\n>\n> Has anyone done any work on bidirectional access to SVN repositories?\n> ie, tracking and committing.\n>\n\nI'm working on something that does just that, I haven't gotten to the \nbidirectional part just yet. (The only reason I didn't use git-svnimport is \nthat it has a /terrible/ time importing from the KDE svn repo. )\n\n> is a directory object, with one file in this example;\n> called svn:ignore. The contents of this file would be something\n> like the .gitignore;\n>\n> Makefile\n> Makefile.old\n> blib\n> ...etc...\n\nMy take on the properties, though I like your thoughts on how to handle at \nleast svn:ignore, is to basically just let svn deal with them. I will make a \ncouple tools that will modify them, for interface reasons, but they'll just \nbe wrappers around the svn commands themselves.\n\nAt the moment, the tools are written as bash shell scripts with an interface \nI'm trying to keep as intuitive as cogito (even though I use the core-git \ntools now.)\n"},{"id":"15581","messageId":"m2hd7e52dv.fsf@ziti.local","threadId":"3213","inReplyTo":"20060204054056.GB24314@Muzzle","subject":"Re: Tracking and committing back to Subversion?","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2006-02-04T19:51:08Z","receivedAt":"2006-02-04T19:51:08Z","isPatch":false,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"On 3 Feb 2006, normalperson@yhbt.net wrote:\n>> Sam Vilain wrote:\n>> Has anyone done any work on bidirectional access to SVN\n>> repositories? ie, tracking and committing.\n\nI think tailor claims to be able to handle this:\nhttp://www.darcs.net/DarcsWiki/Tailor\n\nThe README in the devel version seems to indicate that two-way sync\nfor svn <--> git is implemented (despite the table on the main page). \n\n--\n + seth\n"},{"id":"15647","messageId":"43E7D7D9.1000507@vilain.net","threadId":"3213","inReplyTo":"20060204054056.GB24314@Muzzle","subject":"Re: Tracking and committing back to Subversion?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-06T23:12:25Z","receivedAt":"2006-02-06T23:12:25Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Eric Wong wrote:\n>> 1. file properties - such as mime type, ignores and custom properties.\n>> Linus, when I asked you about this in Dunedin, you mentioned that\n>> there is a place at the end of the directory entry where this could\n>> fit without breaking backwards compatibility. Perhaps this could\n>> be an optional pointer to another directory node;\n> Mostly ignore-able, imho. svn:executable is the one that makes the most\n> sense (and is easiest) to support.\n [...]\n> svn:keywords: I don't think there's a way to disable this like there\n> is with CVS, is there? keywords are evil imho.\n> I don't use or know much about the other properties...\n\nRight, but it is also possible to hang directory or file properties,\nwith any name, off any file or directory. It is often important to\nat least preserve or be able to update these when dealing with some SVN\nrepositories, where people are using them for their own purpose.\n\nPerhaps a \"standard\" mapping to dotfiles would be the best solution\nthen. A .svnprops file or something like that.\n\n>> 2. \"forensic\" file movement history - as opposed to the uncached,\n>> (and unversioned), automatic \"analytical\" file movement history.\n>>\n>> It would be easy for a tool to provide 100% interface compatibility\n>> with SVN client/SVK using properties, but properties that hang off\n>> the head rather than the file itself (so that they don't stuff up\n>> the ability to merge identical trees reached via independent\n>> paths). SVN calls these \"revision properties\". If a good\n>> convention is adopted for this, it could be used as a nice way to\n>> supplement git's automatic analysis of the revision history.\n\n> Just parsing the output of diff-tree -C and marking them in SVN as\n> copies/renames should be sufficient for letting SVN do its thing.\n> \n> Doing this kind of file movement history on the git side sounds like\n> overkill to me. I was a _huge_ fan of logical file-identities in GNU\n> Arch in the past, but the complexity destroyed it from both a UI and\n> performance perspective.\n\nRight now, tagging gets an exemption from this requirement, as does the\nextra state required by tools like StGIT. I think this could be\ngeneralised to support this kind of application; however we will see\nwhether this has any real effect or just operational side effect (eg, to\nmake sure renames are tracked correctly then commit before changing the\ncopied version, etc).\n\nSam.\n"},{"id":"15649","messageId":"43E7DA7F.6060503@vilain.net","threadId":"3213","inReplyTo":"200602040727.30965.linuxfood@linuxfood.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-06T23:23:43Z","receivedAt":"2006-02-06T23:23:43Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Brian Smith wrote:\n>>Has anyone done any work on bidirectional access to SVN repositories?\n>>ie, tracking and committing.\n> I'm working on something that does just that, I haven't gotten to the \n> bidirectional part just yet. (The only reason I didn't use git-svnimport is \n> that it has a /terrible/ time importing from the KDE svn repo. )\n\nIndeed, mirroring SVN repositories via SVN::Mirror (which is used by\nSVK) can take hours for large projects with thousands of commits.\n\n> My take on the properties, though I like your thoughts on how to handle at \n> least svn:ignore, is to basically just let svn deal with them. I will make a \n> couple tools that will modify them, for interface reasons, but they'll just \n> be wrappers around the svn commands themselves.\n > At the moment, the tools are written as bash shell scripts with an\n > interface I'm trying to keep as intuitive as cogito (even though I use\n > the core-git tools now.)\n\nRight; I was looking for an approach that did not require working copies\nof the remote subversion repository to be kept locally. Still, perhaps\nthat approach has merit, though I would probably start in Perl and use\nSVK::Simple (see CPAN) to give a richer SVN mirroring API.\n\nAre you planning on publishing these scripts?\n\nSam.\n"},{"id":"15828","messageId":"200602091650.55370.linuxfood@linuxfood.net","threadId":"3213","inReplyTo":"43E7DA7F.6060503@vilain.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Brian Smith","fromEmail":"linuxfood@linuxfood.net","sentAt":"2006-02-10T00:50:54Z","receivedAt":"2006-02-10T00:50:54Z","isPatch":false,"sender":{"key":"linuxfood@linuxfood.net","avatar":null},"body":"On Monday 06 February 2006 15:23, Sam Vilain wrote:\n> >>Has anyone done any work on bidirectional access to SVN repositories?\n> >>ie, tracking and committing.\n> >\n>> [snip]\n>\n> Indeed, mirroring SVN repositories via SVN::Mirror (which is used by\n> SVK) can take hours for large projects with thousands of commits.\n>\n\nActually, I wasn't so much talking about the time required as the fact that\ngit-svnimport expects a very specific directory format, and KDE, since it was\nmigrated from CVS doesn't follow it, not to mention, I'm writing my tools\nfor the purpose of tracking single projects (i.e. Kopete which is part of KDE \nproject).\n\n>> [snip]\n>\n> Right; I was looking for an approach that did not require working copies\n> of the remote subversion repository to be kept locally. Still, perhaps\n> that approach has merit, though I would probably start in Perl and use\n> SVK::Simple (see CPAN) to give a richer SVN mirroring API.\n>\n\nWhile that is an admirable goal, unless you can point me to something that\nwill allow you to actually commit back to SVN without a working copy, it \ndefeats the purpose of my tools which is basically to use to git for the \npurpose of holding intermediate development before sending it into SVN as a \nfinal commit. That, and being able to use git tools which speak to me on a \nlevel far greater than SVN tools. ;)\n\n> Are you planning on publishing these scripts?\n>\n\nSure, you can actually pick up the current development straight from\ngit://linuxfood.net/pub/git/kosek.git\n\nBrian\n"},{"id":"15829","messageId":"7vk6c43ue5.fsf@assigned-by-dhcp.cox.net","threadId":"3213","inReplyTo":"200602091650.55370.linuxfood@linuxfood.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-10T00:54:58Z","receivedAt":"2006-02-10T00:54:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Smith writes:\n\n> While that is an admirable goal, unless you can point me to something that\n> will allow you to actually commit back to SVN without a working copy, it \n> defeats the purpose of my tools which is basically to use to git for the \n> purpose of holding intermediate development before sending it into SVN as a \n> final commit. \n\nWouldn't svk (or svl or whatever it is called these days) be a\nbetter match for that kind of \"keep my work while disconnected\nfrom master svn repository\" purpose?\n"},{"id":"15830","messageId":"200602091706.59521.linuxfood@linuxfood.net","threadId":"3213","inReplyTo":"7vk6c43ue5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Brian Smith","fromEmail":"linuxfood@linuxfood.net","sentAt":"2006-02-10T01:06:58Z","receivedAt":"2006-02-10T01:06:58Z","isPatch":false,"sender":{"key":"linuxfood@linuxfood.net","avatar":null},"body":"On Thursday 09 February 2006 16:54, Junio C Hamano wrote:\n> Brian Smith writes:\n> > While that is an admirable goal, unless you can point me to something\n> > that will allow you to actually commit back to SVN without a working\n> > copy, it defeats the purpose of my tools which is basically to use to git\n> > for the purpose of holding intermediate development before sending it\n> > into SVN as a final commit.\n>\n> Wouldn't svk (or svl or whatever it is called these days) be a\n> better match for that kind of \"keep my work while disconnected\n> from master svn repository\" purpose?\n\nIt would, if it wasn't god awful slow. And besides, AFAIK, it doesn't allow \nyou to do anything other than keep offline work in a separate SVN repo hosted \non your machine, which means I can't use the git tools.\n"},{"id":"15840","messageId":"43EC162E.9090905@vilain.net","threadId":"3213","inReplyTo":"200602091650.55370.linuxfood@linuxfood.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-10T04:27:26Z","receivedAt":"2006-02-10T04:27:26Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Brian Smith wrote:\n>>Right; I was looking for an approach that did not require working copies\n>>of the remote subversion repository to be kept locally. Still, perhaps\n>>that approach has merit, though I would probably start in Perl and use\n>>SVK::Simple (see CPAN) to give a richer SVN mirroring API.\n> While that is an admirable goal, unless you can point me to something that\n> will allow you to actually commit back to SVN without a working copy,\n\nSuch as SVK\n\n http://svk.elixus.org/\n (svn url: http://svn.openfoundry.org/svk/)\n\n> it \n> defeats the purpose of my tools which is basically to use to git for the \n> purpose of holding intermediate development before sending it into SVN as a \n> final commit. That, and being able to use git tools which speak to me on a \n> level far greater than SVN tools. ;)\n\nYour solution may ultimately be the most pragmatic approach. Issues \nsurrounding the C (SWIG) bindings between Perl and the Subversion RA\n(remote access) API were \"the hard part\" in making SVK work, according\nto the lead author.\n\nThat being said, I am unaware of any drastic outstanding issues, so\nperhaps there are useful components there.\n\n> Sure, you can actually pick up the current development straight from\n> git://linuxfood.net/pub/git/kosek.git\n\nI will take a look.\n\nSam.\n"},{"id":"15844","messageId":"200602092301.21098.linuxfood@linuxfood.net","threadId":"3213","inReplyTo":"43EC162E.9090905@vilain.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Brian Smith","fromEmail":"linuxfood@linuxfood.net","sentAt":"2006-02-10T07:01:20Z","receivedAt":"2006-02-10T07:01:20Z","isPatch":false,"sender":{"key":"linuxfood@linuxfood.net","avatar":null},"body":"On Thursday 09 February 2006 20:27, Sam Vilain wrote:\n>>> [snip]\n> >\n> > While that is an admirable goal, unless you can point me to something\n> > that will allow you to actually commit back to SVN without a working\n> > copy,\n>\n> Such as SVK\n>\n> http://svk.elixus.org/\n> (svn url: http://svn.openfoundry.org/svk/)\n\nWell, after reading through a number of pages I discovered something:\n\n\"The repository created is actually a Subversion repository. In other words, \nyou could use any subversion commands with that repository.\" [*1*]\n\nSo, while it is a technicality, there is an SVN Repo, which is what I'm trying \nto avoid (the point being to have a git repo after all, for the purpose of \nusing git commands), perhaps it would be worth looking into to see if I could \nsomehow utilize the svk svn repo (since there are space savings) for the SVN \nworking copy. [*2*]\n\n>\n> > [snip]\n>\n> Your solution may ultimately be the most pragmatic approach. Issues\n> surrounding the C (SWIG) bindings between Perl and the Subversion RA\n> (remote access) API were \"the hard part\" in making SVK work, according\n> to the lead author.\n>\n> That being said, I am unaware of any drastic outstanding issues, so\n> perhaps there are useful components there.\n\nThere are useful things in there. I have considered rewriting in perl so that \nI don't have to use my kludge of a rewrite of Getopt::Long (yes, I did. No, \nnot everything is supported.) but have decided against it mostly because it \nwould take weeks, and Kosek (my program) isn't even complete yet.\n\n(Incidentally, the allure of the SVN perl bindings had me for awhile, but \nafter trying to decipher the horrid PODs for it decided that Bash was just \neasier. )\n\n>\n> > Sure, you can actually pick up the current development straight from\n> > git://linuxfood.net/pub/git/kosek.git\n>\n> I will take a look.\n>\nAwesome let me know what you think. Please try to ignore the massive lack of \ndocumentation, up until someone in the kopete irc channel showed interest I \nhad been writing it for my own purposes. Though, since I posted the link here \nI did go ahead and fixup the readme with a little howto. If you like it, feel \nfree to email me with questions and suggestions.\n\n[*1*] http://svk.elixus.org/?SingleUserSVK (under Mapping Repositories)\n\n[*2*] \nWhile writing this, I had an absolutely insane idea, which I may or may not \npersue. The idea being that it may be possible to remove 99% of the actual \nSVN working copy (except for perhaps the base directory at the root of the \nproject), and just use symlinks for the rest of the hierarchy. This would \nrequire careful management though, since every .svn directory contains \nspecific and distinct information.\n"},{"id":"15848","messageId":"1139570171.12123.29.camel@localhost.localdomain","threadId":"3213","inReplyTo":"200602092301.21098.linuxfood@linuxfood.net","subject":"Re: Tracking and committing back to Subversion?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-02-10T11:16:11Z","receivedAt":"2006-02-10T11:16:11Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2006-02-09 at 23:01 -0800, Brian Smith wrote:\n> > > While that is an admirable goal, unless you can point me to something\n> > > that will allow you to actually commit back to SVN without a working\n> > > copy,\n> > Such as SVK\n> > http://svk.elixus.org/\n> > (svn url: http://svn.openfoundry.org/svk/)\n> Well, after reading through a number of pages I discovered something:\n> \"The repository created is actually a Subversion repository. In other words, \n> you could use any subversion commands with that repository.\" [*1*]\n> So, while it is a technicality, there is an SVN Repo, which is what\n> I'm trying to avoid[...\n\nYes, currently there is - but let me show you what's under the hood\nbriefly... as you notice later;\n\n> (Incidentally, the allure of the SVN perl bindings had me for awhile, but \n> after trying to decipher the horrid PODs for it decided that Bash was just \n> easier. )\n\nYes, there are SWIG bindings for various languages. In debian/ubuntu the\nPerl bindings will be built to the package libsvn-core-perl.\n\nTake a look at this module:\n\n http://search.cpan.org/dist/SVN-Simple/lib/SVN/Simple/Edit.pm\n\nThat uses the above module and allows you to construct a Subversion\ncommit and try to apply it.\n\nThe documentation's a bit weak, but AFAIK the basic functionality is\nthere and a lot better an abstraction than the raw bindings themselves.\n\nSVN::Mirror:\n\n http://search.cpan.org/dist/SVN-Mirror/lib/SVN/Mirror.pm\n\ncan go the other way.\n\n> (the point being to have a git repo after all, for\n> the purpose of using git commands), perhaps it would be worth looking\n> into to see if I could somehow utilize the svk svn repo (since there\n> are space savings) for the SVN working copy. [*2*]\n\nThat's right - in principle, SVK could be plumbed to have a git\nrepository in its ~/.svk/local - then you could have one git repo, and a\nhead for each mirrored project.\n\nBut don't concern yourself with my plans - it seems our tastes in\nporcelain differ ;)\n\nSam.\n"}]}