{"thread":{"id":"8722","subject":"git for subversion users","startedAt":"2007-06-25T19:48:32Z","lastAt":"2007-06-26T13:19:51Z","messageCount":8,"participants":["Patrick Doyle","Sam Vilain","Steven Grimm","Alexander Litvinov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45788","messageId":"e2a1d0aa0706251248j1b8da150xbe19826bec15eed6@mail.gmail.com","threadId":"8722","inReplyTo":null,"subject":"git for subversion users","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2007-06-25T19:48:32Z","receivedAt":"2007-06-25T19:48:32Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"Hello all,\nI've read http://utsl.gen.nz/talks/git-svn/intro.html, \"An\nintroduction to git-svn for Subversion/SVK users and deserters\" and, I\nguess I'm looking for a little more information.\n\nIt is possible that I am trying to use git and git-svn in a manner for\nwhich they were not designed, so I appreciate any guidance that can be\nprovided.  Also, since I'm running FC6, I have git version 1.5.0.6\ninstalled, instead of the 1.5.2.2 that I see on the home page.\nPerhaps that could be my problem.\n\nAnyway, we have a subversion server set up to track our internal\nsoftware development.  I would like to use git/git-svn so that I can\nwork offline, commit early and often, and occasionally synchronize to\nour subversion baseline.  Finally, at least one of our subversion\nrepositories (my own personal one), is not set up in the traditional\nsvn://host/repo/{trunk,tags,branches} format.  It is organized as\nsvn://host/wpd/{project1,project2,project3}.  Since it's my own\npersonal playground, I don't need branches, and tend to remember tags\njust be commit number.\n\nThat's the long, boring setup.  Now for the long boring question...\n\nI started playing with a new project over the weekend, checkign in a\nhandful of commits in git, and now I want to import/export/push/pull\nthem to the subversion server.\n\nHaving read through the tutorial, I started with:\n\n$ svn mkdir svn:///host/wpd/empty-project -m \"Created empty project directory\"\n$ git-svn init svn:///host/wpd/empty-project\n$ svn-git fetch\n\nNow I have an empty directory into which I was hoping to \"pull\" my\nchanges from my weekend playground\n\n$ git pull ~/playground/new-project\n... (I get 7 new files, and, it looks like, their associated history)\n\nHere's where I get stuck...\n1) How can I remind myself of what I changed relative to what was in\nthe Subversion repository the last time I sync'd to it?  Under my\ncurrent model of operation, I come in after a weekend/night away, do\n\"svn status\" and \"svn diff\" to remind myself what's changed, and\ncommit those changes with appropriate log messages.  I am hoping that\nI can make the changes locally, commiting them with nice log messages\nas I make the changes, and then \"push\" them to the subversion server\nwhen convenient.\n\n2) This is going to have some obvious problems when I work on other\nprojects shared with other developers.  We know how to address this\nwith Subversion (good communication, updating the working copy prior\nto a commit, resolving the minor conflicts, etc...) what can I expect\nwhen my local repository is git?\n\n3) If I try to commit my change with:\n\n$ git-svn dcommit\n\nI get an error\nCommit 0e3e....\nhas no parent commit, and therefore nothing to diff against.\nYou should be working from a repository originally created by git-svn\n\nand that's where I get confused.  Is this a bug/feature of 1.5.0.2\nthat will disappear if I switched to 1.5.2.2?\n\nAre there any other tips/resources for mixed mode operation\n(centralized Subversion server, distributed git client(s))?\n\nThanks for any pointers.\n\n--wpd\n"},{"id":"45819","messageId":"46809733.2060200@vilain.net","threadId":"8722","inReplyTo":"e2a1d0aa0706251248j1b8da150xbe19826bec15eed6@mail.gmail.com","subject":"Re: git for subversion users","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-06-26T04:33:55Z","receivedAt":"2007-06-26T04:33:55Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Patrick Doyle wrote:\n> Hello all,\n> I've read http://utsl.gen.nz/talks/git-svn/intro.html, \"An\n> introduction to git-svn for Subversion/SVK users and deserters\" and, I\n> guess I'm looking for a little more information.\n  [...]\n> svn://host/wpd/{project1,project2,project3}.  Since it's my own\n> personal playground, I don't need branches, and tend to remember tags\n> just be commit number.\n\nThere's your first issue - misunderstanding branching :)  You should end\nup realising that every little idea or feature forms a code branch in\nthe direction of its implementation, the choice is whether to let the\nbranches twist and grow together or train them in clear directions.\n\n> Here's where I get stuck...\n> 1) How can I remind myself of what I changed relative to what was in\n> the Subversion repository the last time I sync'd to it?  Under my\n> current model of operation, I come in after a weekend/night away, do\n> \"svn status\" and \"svn diff\" to remind myself what's changed, and\n> commit those changes with appropriate log messages.  I am hoping that\n> I can make the changes locally, commiting them with nice log messages\n> as I make the changes, and then \"push\" them to the subversion server\n> when convenient.\n\nuse git-branch -a to show you the name that the remote subversion branch\nis set up on.\n\nthen you can use \"git-diff svn/trunk\" (say, if it listed it as\n\"svn/trunk\") to show you the files changed between your working copy and\nthe last subversion commit you did.\n\nI can see that this point isn't very clear from the tutorial if you go\nstraight in at \"How to ... commit back to Subversion\".  That section\nneeds a bit of an overall introduction I think.  The idea is that first,\nyou make the changes in your local branch. (see\nhttp://utsl.gen.nz/talks/git-svn/intro.html#local-commit).  Then you use\ndcommit to save it to Subversion.  Using this you can stage multiple\ncommits, and if you don't like them you can go back and review them\nbefore they are set in SVN forever.\n\nThat mode of operation is already natural for SVK users which the\ntutorial was primarily targeted at - so they were probably already\nlooking for information on how to create a local branch, make local\nchanges and then push back.\n\n> 2) This is going to have some obvious problems when I work on other\n> projects shared with other developers.  We know how to address this\n> with Subversion (good communication, updating the working copy prior\n> to a commit, resolving the minor conflicts, etc...) what can I expect\n> when my local repository is git?\n\nIf svn is still the master there should be no difference to the way you\nnormally collaborate development using Subversion.  The central server\nis still the publishing point for trunk, however many release\nengineering branches you use, and feature branches.  It's only if you\nwant to start mixing groups of people, some working with subversion, and\nother people using git-svn and merging between each other at the git\nlevel, that you can start getting confused.  They can safely operate at\nthe patch trading level though.\n\n> 3) If I try to commit my change with:\n> \n> $ git-svn dcommit\n> \n> I get an error\n> Commit 0e3e....\n> has no parent commit, and therefore nothing to diff against.\n> You should be working from a repository originally created by git-svn\n> \n> and that's where I get confused.  Is this a bug/feature of 1.5.0.2\n> that will disappear if I switched to 1.5.2.2?\n> \n> Are there any other tips/resources for mixed mode operation\n> (centralized Subversion server, distributed git client(s))?\n\nAlmost certainly because you haven't committed locally yet.\n\nSam.\n\n> \n> Thanks for any pointers.\n> \n> --wpd\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"45820","messageId":"4680A341.5000208@midwinter.com","threadId":"8722","inReplyTo":"46809733.2060200@vilain.net","subject":"Re: git for subversion users","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-06-26T05:25:21Z","receivedAt":"2007-06-26T05:25:21Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Sam Vilain wrote:\n> If svn is still the master there should be no difference to the way you\n> normally collaborate development using Subversion.  The central server\n> is still the publishing point for trunk, however many release\n> engineering branches you use, and feature branches.  It's only if you\n> want to start mixing groups of people, some working with subversion, and\n> other people using git-svn and merging between each other at the git\n> level, that you can start getting confused.  They can safely operate at\n> the patch trading level though.\n>   \n\nI can vouch for all of that as well. On some of my repositories I use \ngit solely as a fancy Subversion client, no interaction with any other \ngit repositories. And hardly anyone at my company even knows about it; \nas far as they are concerned I just check stuff into the svn repository \nlike any other engineer.\n\nBut on a few of my repositories I do things like use git to keep a copy \nof my work in progress synced up between my laptop and my development \nserver, or (rarely) share my work with another git-aware developer. In \nthose cases I do have to be kind of careful what I do, mostly around \nmaking sure all the repositories are in agreement about which branches \ncome from where and about when I use rebase vs. merge vs. squash merge.\n\nI will say, though, that the upcoming addition to git-svn to allow \nmerges to be directly committed to the svn repository will make some of \nthose kinds of scenarios a lot less brittle than they are now. It's \nstill a work in progress but it looks very promising so far. (Search the \nlist for \"[PATCH] git-svn: allow dcommit to retain local merge \ninformation\" if you want to see what I'm talking about.)\n\n-Steve\n"},{"id":"45822","messageId":"4680AA15.6040501@vilain.net","threadId":"8722","inReplyTo":"4680A341.5000208@midwinter.com","subject":"Re: git for subversion users","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-06-26T05:54:29Z","receivedAt":"2007-06-26T05:54:29Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Steven Grimm wrote:\n> I will say, though, that the upcoming addition to git-svn to allow \n> merges to be directly committed to the svn repository will make some of \n> those kinds of scenarios a lot less brittle than they are now. It's \n> still a work in progress but it looks very promising so far. (Search the \n> list for \"[PATCH] git-svn: allow dcommit to retain local merge \n> information\" if you want to see what I'm talking about.)\n\nYes.  On that.  It would be nice if git-svn could also fake setting\nremote merge properties, too.\n\nSome beginnings at:\n\n  http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge\n  (pull from git://git.catalyst.net.nz/git.git#svk-merge)\n\nWhat it needs to do;\n\n  0. preserve the notion that commits tagged with \"git-svn-id:\" should\n     not vary depending on who synced them.\n\n  1. on commit, if we're committing a merge, make sure that the other\n     parent has the same revision somewhere in the repo, and then set\n     the \"svk:merge\" and \"svnmerge-integrated\" tags to accurately record\n     which parent SVN revisions are used\n\n  2. when fetching revisions, spot these tickets and set parents\n     appropriately.  In the case of SVK, the merge tickets may\n     correspond to revisions in (inaccessible) svk local depots.  It may\n     be possible to infer these extra parents in some limited\n     situations using the extra information svk puts in commit messages\n     by default, but I doubt that is a useful endeavour!\n\nI'll take a look at what you've been working on and see if that's not\nwhat you're already trying...\n\nSam.\n"},{"id":"45823","messageId":"200706261302.10056.litvinov2004@gmail.com","threadId":"8722","inReplyTo":"46809733.2060200@vilain.net","subject":"Re: git for subversion users","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2007-06-26T06:02:09Z","receivedAt":"2007-06-26T06:02:09Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"В сообщении от 26 июня 2007 11:33 Sam Vilain написал(a):\n> There's your first issue - misunderstanding branching :)  You should end\n> up realising that every little idea or feature forms a code branch in\n> the direction of its implementation, the choice is whether to let the\n> branches twist and grow together or train them in clear directions.\n\ngit-svn has one major trouble with branch handling: merge two branches that \nare different branches at svn. Or simply start from different point from svn \nbranch.\n\ngit-svn dcommit operation tries to figure out where to commit at svn side and \nfail at these conditions. It seems to me this happend becuse it uses special \nline at git's commit comment and in case of such merge it does not know there \nto commit. I did not found how to deal with this situation.\n\nSo, git-svn just a offline-capable version of svn client with linear history. \nSure. you can fork your own branch and then merge it into svn branch again \nbut you should really careful about this.\n\nI even does not know the way to solve this problem.\n\n---\nAlexander Litvinov.\n"},{"id":"45824","messageId":"4680C057.5070202@vilain.net","threadId":"8722","inReplyTo":"4680AA15.6040501@vilain.net","subject":"Re: git for subversion users","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-06-26T07:29:27Z","receivedAt":"2007-06-26T07:29:27Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Sam Vilain wrote:\n> It would be nice if git-svn could also fake setting\n> remote merge properties, too.\n> \n> Some beginnings at:\n> \n>   http://git.catalyst.net.nz/gw?p=git.git;a=shortlog;h=svk-merge\n>   (pull from git://git.catalyst.net.nz/git.git#svk-merge)\n> \n> What it needs to do;\n> \n>   0. preserve the notion that commits tagged with \"git-svn-id:\" should\n>      not vary depending on who synced them.\n> \n>   1. on commit, if we're committing a merge, make sure that the other\n>      parent has the same revision somewhere in the repo, and then set\n>      the \"svk:merge\" and \"svnmerge-integrated\" tags to accurately record\n>      which parent SVN revisions are used\n> \n>   2. when fetching revisions, spot these tickets and set parents\n>      appropriately.\n\nProof of concept for #2 at:\n\nhttp://git.catalyst.net.nz/gw?p=git.git;a=commitdiff;h=816e2ef\n\nSam.\n"},{"id":"45825","messageId":"4680C4D1.6050408@vilain.net","threadId":"8722","inReplyTo":"200706261302.10056.litvinov2004@gmail.com","subject":"subversion and merging [was: Re: git for subversion users]","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-06-26T07:48:33Z","receivedAt":"2007-06-26T07:48:33Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Alexander Litvinov wrote:\n> So, git-svn just a offline-capable version of svn client with linear history. \n> Sure. you can fork your own branch and then merge it into svn branch again \n> but you should really careful about this.\n> \n> I even does not know the way to solve this problem.\n\nThe problem is the SVN model.  Only now that people have woken up en\nmasse to the fact that tracking merges is actually really important are\nthey adding it to the core.\n\nTheir system¹ is of course completely incompatible with the predominant\ntool for this SVK (no complaints there).  Thankfully it looks based on\nthe other major solution out there, svnmerge, so hopefully only minor\nincompatibilities can be expected.\n\nMy first analysis of the solution is that they have approached this on\ntwo levels: commit merge ancestry and file merge ancestry.\n\nFile merge ancestry, while central to tools like Perforce, is a pretty\nalien concept to git and almost certainly can be derived (probably more\nreliably in practice) using git-cherry-type algorithms.  I describe this\nas the \"smash patches to pieces\" development model on my git-svn tutorial.\n\nCommit merge ancestry is however a basic feature in git.  They are even\ngoing further than that and allowing cherry picks to be tracked as well.\n This information is currently derived in git using git-cherry.\n\nSam.\n\n¹ http://subversion.tigris.org/merge-tracking/design.html\n"},{"id":"45831","messageId":"e2a1d0aa0706260619u48943163r7f85da944bb88672@mail.gmail.com","threadId":"8722","inReplyTo":"4680C057.5070202@vilain.net","subject":"Re: git for subversion users","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2007-06-26T13:19:51Z","receivedAt":"2007-06-26T13:19:51Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"Thank you all for the tips and pointers,  especially to Sam, who has\ngiven me something to digest, and to Steven, whose mode of operation,\n\"I can vouch for all of that as well. On some of my repositories I use\ngit solely as a fancy Subversion client, no interaction with any other\ngit repositories. And hardly anyone at my company even knows about\nit\"; precisely matches what I am trying to do.\n\nIt seems that a large part of my original problem was with the fact\nthat FC6 only has git-1.5.0.2 on it.  When I installed 1.5.2.2, things\nstarted working much more smoothly for me.\n\nI still have one issue... say I start a project in git and later want\nto publish it to the subversion server, history and all... how do I do\nthat?\n\nRight now, I do the following:\n\n$ svn mkdir url://to/svn/repo/newproject -m \"made directory\"\n$ git-svn clone url://to/svn/repo/newproject\n$ cd newproject\n$ git pull url://from/project/started/in/git\n$ git log\n-- shows the history of my git based project, along with the \"made\ndirectory\" log message\n$ git-svn dcommit\n-- commits only a single change to the svn repository with a log\nmessage that reads something like \"merged\nurl://from/project/started/in/git\"\n$ git-log\n-- no longer shows the history of my git based project, it just shows\nthe subversion history\n\nIs this related to the follow-on discussion regarding handling merges properly?\n\nIs there some other way to \"export\" a git repository to a subversion\nrepository, maintaining the history along the way?\n\nOnce again, thanks for your help.\n\n--wpd\n"}]}