{"thread":{"id":"10977","subject":"git-svn: surprising behaviors/bugs?","startedAt":"2007-11-22T13:37:27Z","lastAt":"2007-11-29T09:59:51Z","messageCount":3,"participants":["Gustaf Hendeby","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60685","messageId":"bf7b2dda0711220537h3f37c84ag899b74daa9a8fe1f@mail.gmail.com","threadId":"10977","inReplyTo":null,"subject":"git-svn: surprising behaviors/bugs?","fromName":"Gustaf Hendeby","fromEmail":"hendeby@gmail.com","sentAt":"2007-11-22T13:37:27Z","receivedAt":"2007-11-22T13:37:27Z","isPatch":false,"sender":{"key":"hendeby@gmail.com","avatar":null},"body":"I've been running git for most my stuff for some time now, and am\nreally pleased with what it has to offer.  However, all my coworkers\naren't gitified yet, and therefore I sometimes have to work with svn.\nI've learned to appreciate git-svn for this, since it lets me utilize\nthe strengths of git and still allows for my coworkers to think I use\ntheir svn setup.  Thanks to all who contribute to this wonderful\ntools!\n\nIn my work with git-svn I have stumbled upon the following two\nunexpected behaviors.  Basically, am I doing/understanding something\nwrong, or is this buggy behavior in git-svn?  (I'm presently using git\n1.5.3.6, but have been experiencing these things for a while.)\n\n\n1.  I don't really like svn's committer info, so I got an authorsfile\nset.  This works great when I'm fetching/dcommitting from the\ntop-directory in my git checkout (the one with .git in), however, if\nI'm in a subdirectory the authorsfile doesn't kick in and I get the\nsvn commiter info.  This is not a big deal, but a bit surprising and\nmy history gets a bit ugly.\n\n\n2.  My second problem involves getting the support in git-svn for tags\nand branches to work.  Having a standard layout of the svn repository,\nin this case\n   /source/project/(trunk|branch|tags)\nsvn clone -s only works as expected sometimes.  Sometimes I only get\nthe revision history, not including any actual content (ie none files\nof the files under control turns up in git) from the clone.  When I\nget this problem I usually clone the trunk only, and add tags myself.\nThis is far from optimal, and also error prone.  Other times, the\nclone works as expected and gives me the tags and branches and all the\ncontent.\n\nI think the problem occurs when I'm not the owner of the svn\nrepository, and only have access (read/write) to the\nproject/(trunk|branch|tag) part, and don't have any access at all to\nsource.  Ie, svn ls works for /source/project and\n/source/project/trunk etc, but not /source (where I returns 403\nForbidden access).  All svn access is through a svn-server that I\ncan't control myself.\n\n\nI've had a quick look in git-svn.perl, but the code is to beyond my\nlimited perl knowledge.  I'd be happy to provide more details if\nanyone is interested in looking deeper into this.  Any ideas or\ncomments are greatly appreciated!\n\n/Gustaf\n"},{"id":"61378","messageId":"20071129081031.GF32277@soma","threadId":"10977","inReplyTo":"bf7b2dda0711220537h3f37c84ag899b74daa9a8fe1f@mail.gmail.com","subject":"Re: git-svn: surprising behaviors/bugs?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-11-29T08:10:31Z","receivedAt":"2007-11-29T08:10:31Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Gustaf Hendeby <hendeby@gmail.com> wrote:\n> I've been running git for most my stuff for some time now, and am\n> really pleased with what it has to offer.  However, all my coworkers\n> aren't gitified yet, and therefore I sometimes have to work with svn.\n> I've learned to appreciate git-svn for this, since it lets me utilize\n> the strengths of git and still allows for my coworkers to think I use\n> their svn setup.  Thanks to all who contribute to this wonderful\n> tools!\n> \n> In my work with git-svn I have stumbled upon the following two\n> unexpected behaviors.  Basically, am I doing/understanding something\n> wrong, or is this buggy behavior in git-svn?  (I'm presently using git\n> 1.5.3.6, but have been experiencing these things for a while.)\n> \n> \n> 1.  I don't really like svn's committer info, so I got an authorsfile\n> set.  This works great when I'm fetching/dcommitting from the\n> top-directory in my git checkout (the one with .git in), however, if\n> I'm in a subdirectory the authorsfile doesn't kick in and I get the\n> svn commiter info.  This is not a big deal, but a bit surprising and\n> my history gets a bit ugly.\n\nI see you've already fixed that.  Thanks.\n\n> 2.  My second problem involves getting the support in git-svn for tags\n> and branches to work.  Having a standard layout of the svn repository,\n> in this case\n>    /source/project/(trunk|branch|tags)\n> svn clone -s only works as expected sometimes.  Sometimes I only get\n> the revision history, not including any actual content (ie none files\n> of the files under control turns up in git) from the clone.  When I\n> get this problem I usually clone the trunk only, and add tags myself.\n> This is far from optimal, and also error prone.  Other times, the\n> clone works as expected and gives me the tags and branches and all the\n> content.\n\nAny chance there's a BOFH at the other end playing around with\npermissions while you were testing?\n\n> I think the problem occurs when I'm not the owner of the svn\n> repository, and only have access (read/write) to the\n> project/(trunk|branch|tag) part, and don't have any access at all to\n> source.  Ie, svn ls works for /source/project and\n> /source/project/trunk etc, but not /source (where I returns 403\n> Forbidden access).  All svn access is through a svn-server that I\n> can't control myself.\n\nI'll have to look into that some other time.\n\nDoes `svn log -v' work for /source/project ?\n\nAm I correct in what you have is currently like this?\n\n[svn-remote \"svn\"]\n\turl = http://domain/\n\tbranches = source/project/branches/*:refs/remotes/*\n\ttags = source/project/tags/*:refs/remotes/tags/*\n\tfetch = source/project/trunk:refs/remotes/trunk\n\n\nIf so, can you change it to something like this?\n\n[svn-remote \"svn\"]\n\turl = http://domain/source/project\n\tbranches = branches/*:refs/remotes/*\n\ttags = tags/*:refs/remotes/tags/*\n\tfetch = trunk:refs/remotes/trunk\n\nAnd see if that works all the time?\n\nThanks,\n\n-- \nEric Wong\n"},{"id":"61385","messageId":"bf7b2dda0711290159v49b5bc2elb072b610d2237755@mail.gmail.com","threadId":"10977","inReplyTo":"20071129081031.GF32277@soma","subject":"Re: git-svn: surprising behaviors/bugs?","fromName":"Gustaf Hendeby","fromEmail":"hendeby@gmail.com","sentAt":"2007-11-29T09:59:51Z","receivedAt":"2007-11-29T09:59:51Z","isPatch":false,"sender":{"key":"hendeby@gmail.com","avatar":null},"body":"On Nov 29, 2007 9:10 AM, Eric Wong <normalperson@yhbt.net> wrote:\n> Gustaf Hendeby <hendeby@gmail.com> wrote:\n> > 1.  I don't really like svn's committer info, so I got an authorsfile\n> > set.  This works great when I'm fetching/dcommitting from the\n> > top-directory in my git checkout (the one with .git in), however, if\n> > I'm in a subdirectory the authorsfile doesn't kick in and I get the\n> > svn commiter info.  This is not a big deal, but a bit surprising and\n> > my history gets a bit ugly.\n>\n> I see you've already fixed that.  Thanks.\n\nYes, it turned out to be easier than I thought.  The fix indicates\nthat other options are lost as well, but I don't know how to test for\nthat or it would have been easier for others to verify the problem.\n\n> > 2.  My second problem involves getting the support in git-svn for tags\n> > and branches to work.  Having a standard layout of the svn repository,\n> > in this case\n> >    /source/project/(trunk|branch|tags)\n> > svn clone -s only works as expected sometimes.  Sometimes I only get\n> > the revision history, not including any actual content (ie none files\n> > of the files under control turns up in git) from the clone.  When I\n> > get this problem I usually clone the trunk only, and add tags myself.\n> > This is far from optimal, and also error prone.  Other times, the\n> > clone works as expected and gives me the tags and branches and all the\n> > content.\n>\n> Any chance there's a BOFH at the other end playing around with\n> permissions while you were testing?\n\nThis time I think BOFH is innocent, unless for maybe setting up the\nSVN repository in a stupid way.\n\n> > I think the problem occurs when I'm not the owner of the svn\n> > repository, and only have access (read/write) to the\n> > project/(trunk|branch|tag) part, and don't have any access at all to\n> > source.  Ie, svn ls works for /source/project and\n> > /source/project/trunk etc, but not /source (where I returns 403\n> > Forbidden access).  All svn access is through a svn-server that I\n> > can't control myself.\n>\n> I'll have to look into that some other time.\n\nWould be great, thanks, let me know how I can help.  I've tried to\nanswer your questions about the setup below.\n\n>\n> Does `svn log -v' work for /source/project ?\n\nWorks just fine.\n\n>\n> Am I correct in what you have is currently like this?\n>\n> [svn-remote \"svn\"]\n>         url = http://domain/\n>         branches = source/project/branches/*:refs/remotes/*\n>         tags = source/project/tags/*:refs/remotes/tags/*\n>         fetch = source/project/trunk:refs/remotes/trunk\n>\n>\n> If so, can you change it to something like this?\n>\n> [svn-remote \"svn\"]\n>         url = http://domain/source/project\n>         branches = branches/*:refs/remotes/*\n>         tags = tags/*:refs/remotes/tags/*\n>         fetch = trunk:refs/remotes/trunk\n>\n> And see if that works all the time?\n\nI just made three different setups to get the same (problematic) project.\n\nPLAIN TRUNK (works as expected, but lacks tags/branches)\ngit svn init https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.trunk\ncd shapes.trunk\ngit svn fetch  # Now gives me the history of the trunk with all content\ncat .git/config\n[core]\n        repositoryformatversion = 0\n        filemode = true\n        bare = false\n        logallrefupdates = true\n[svn-remote \"svn\"]\n        url = https://svn.isy.liu.se/rt/tidefelt/source/shapes/trunk\n        fetch = :refs/remotes/git-svn\n\n\nWITH STANDARD LAYOUT (gets no content)\ngit svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes\ncd shapes\ngit svn fetch  # No files present in any commit\ncat .git/config\n[core]\n        repositoryformatversion = 0\n        filemode = true\n        bare = false\n        logallrefupdates = true\n[svn-remote \"svn\"]\n        url = https://svn.isy.liu.se/rt\n        fetch = tidefelt/source/shapes/trunk:refs/remotes/trunk\n        branches = tidefelt/source/shapes/branches/*:refs/remotes/*\n        tags = tidefelt/source/shapes/tags/*:refs/remotes/tags/*\n\nWhat seems to complicate things here, and that I didn't realize\nbefore, is that I have access to https://svn.isy.liu.se/rt (at least\nread), so if git-svn starts from the bottom and checks for premissions\nit will find this root directory.\n\nWITH CHANGED STANDARD LAYOUT (retrieves neither content nor tags)\ngit svn init -s https://svn.isy.liu.se/rt/tidefelt/source/shapes shapes.fix\ncd shapes.fix\n# Edit .git/config\ngit svn fetch\ncat .git/config\n[core]\n        repositoryformatversion = 0\n        filemode = true\n        bare = false\n        logallrefupdates = true\n[svn-remote \"svn\"]\n        url = https://svn.isy.liu.se/rt/tidefelt/source/shapes\n        fetch = trunk:refs/remotes/trunk\n        branches = branches/*:refs/remotes/*\n        tags = tags/*:refs/remotes/tags/*\n\nThe version where I make changes in .git/config file fails also for a\nproject that I don't have any problems with just using the -s option.\nDo I have to do anything more than just change the config file?\n\nAll of the above git svn fetch complains a bit the first time with a\nmessage similar to:\n\nW: Ignoring error from SVN, path probably does not exist: (175007):\nHTTP Path Not Found: REPORT request failed on\n'/rt/!svn/bc/100/tidefelt/source/shapes':\n'/rt/!svn/bc/100/tidefelt/source/shapes' path not found\n\nPlease, let me know if there is any other information that would be useful.\n\n/Gustaf\n"}]}