On Sat, Feb 28, 2009 at 11:47 PM, Alexis Midon <[email protected]>wrote:
> Disclaimer: I haven't read all the details of these long emails so I > apologize if I'm out of topic. > > If you need a git clone freshly synchronized with svn, jukka's clones are > updated daily and could be updated per commit. Yo could easily pull from > there, then push to github. > http://jukka.zitting.name/git/ > Jukka's is chronically late, at best 4 hours behind SVN, sometimes stretching into days. Right now it reports the most recent change being OpenJPA 5 hours ago. If Apache SVN goes five hours without a commit, something big is happening in the world, but CNN reports nothing out of the ordinary. In fact, SVN happily reports a Maven update 2 minutes ago (Jukka's at 13 hours), and Spam Assassin 18 minutes ago (Jukka's at 24 hours). Of course, if you just want to catch up to head and rebase/merge occasionally, 4~24 hour delay is not a deal killer. But it does get annoying when someone commits your patch to trunk, or makes a change you want to test, and you can't fetch it until the next day. Which is one reason I did not update the Git portion of the documentation yet. We still don't have a recommended repo to clone. Assaf > <http://jukka.zitting.name/git/> > > Alexis > > > On Sat, Feb 28, 2009 at 11:02 PM, Daniel Spiewak <[email protected] > >wrote: > > > Actually, I don't think that it is a restriction that Apache has placed > on > > their SVN server (AFAIK). The way that git-svn works is it grabs every > > single change set back to the beginning of time. This means a really, * > > really* huge checkout from the server, all at once. While this is not > > strictly a problem for SVN, it does pose some issues when SVN is being > run > > through mod_dav. Basically, mod_svn_dav (or mod_svn, whichever it is) > > keeps > > accruing objects in memory as the checkout progresses. At some point, > the > > process handling your HTTP request actually crashes because it runs out > of > > heap space. > > > > I ran into this issue at my previous job, though it would manifest itself > > as > > a PROPSET error on svn checkout. Because we had one particularly huge > > changeset, I was never able to do a full checkout of all revisions from > > scratch. Using the svn client, things were at least passable (since you > > could repeatedly "svn up"), but it wasn't pretty. The really depressing > > thing is that this is a known issue. The mod_dav folks say that it's > SVN's > > fault, while the SVN folks keep bouncing the problem back. I've also > heard > > it said that no one would ever run into this issue when using SVN > > "properly", so it's not a serious concern. :-S The officially > > "workaround" > > is to just allocate more memory to httpd. > > > > I'm not sure why this wouldn't affect incubator, but it may be partially > > due > > to the fact that you performed your initial clone of the Buildr repo at a > > much earlier point than this. Alternatively, there may be some other > > factors in play here beyond annoying bugs associated with SVN+HTTPS. > > > > Daniel > > > > On Sun, Mar 1, 2009 at 12:40 AM, Assaf Arkin <[email protected]> wrote: > > > > > On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <[email protected]> > > > wrote: > > > > > > > Those of you following development progress using Git are probably > > > starting > > > > to notice that the classical "Vic Master" is no longer the > all-knowing > > > > source of data. Actually, Assaf's GitHub fork has become the more > > > > trustworthy one. This is because upon its exit from incubation, > Buildr > > > > gets > > > > to move its SVN repository to a new URL. This is good for the > project, > > > but > > > > bad for the Git forks since git-svn stores the URL information in its > > > > commit > > > > messages. > > > > > > > > The solution of course is to re-clone from SVN, which I assume > exactly > > > what > > > > Assaf did. There result is a repository which contains all of the > same > > > SVN > > > > commits as Vic's, but different messages and very different SHA1 > > > revisions, > > > > meaning that Git has a much harder time merging between the two. I > > > > discovered this when I attempted to merge Assaf's latest changes with > > my > > > > master (forked from Vic's). 57 conflicts later (all petty, little > > issues > > > > unrelated to my additions), I finally had a working master with the > > > latest > > > > commits. Unfortunately, when I cloned Assaf's repository directly > and > > > > attempted to merge back some of my changes, it became very apparent > > that > > > I > > > > would need to fix the issue in a more scientific manner. > > > > > > > > Long story short, the solution is to rebase all of your branches onto > > > > Assaf's master. I did this by finding the exact commit where I > > diverged > > > > from vic (I had it tagged, actually) as well as the corresponding > > commit > > > in > > > > Assaf's master. These commits I tagged "branch-point" and > > > > "new-branch-point", respectively. Then for each branch, I did > > something > > > > like the following: > > > > > > > > git checkout scala-joint-compilation > > > > git rebase new-branch-point > > > > > > > > Once this was done, I went back to my master and performed a similar > > > > procedure: > > > > > > > > git checkout master > > > > git rebase -s ours new-branch-point > > > > > > > > This effectively wiped out all of my changes in that branch (it's > > > possible > > > > that some commits may remain if you try it, but none did in my case). > > > Once > > > > this was done, I went and picked through my origin/master log to see > > what > > > I > > > > was missing. This meant re-merging all of my branches: > > > > > > > > git merge scala-joint-compilation > > > > git merge clojure > > > > ... > > > > > > > > Also, I had to cherry-pick a few commits that I had done on master > > (like > > > > four or five): > > > > > > > > git cherry-pick all-your-ant-base > > > > ... > > > > > > > > Once this was done, I pushed the result back to GitHub: > > > > > > > > git push -f origin > > > > > > > > The one caveat to this approach is I had all of my changes on > numerous > > > > separate branches (for patching reasons). All of these branches were > > > > branched off of the same point on vic/master. Since there hadn't > been > > > any > > > > merging *between* the branches (only onto master), it was fairly easy > > to > > > > just rebase these branches onto the new trunk (I only had three > > conflicts > > > > in > > > > the whole process, all easily resolved). Just judging by GitHub, not > > > many > > > > people are managing their repositories in this fashion. However, > this > > > does > > > > mean that you could be able to just rebase without the "-s ours" on > > your > > > > master and come to the same result. > > > > > > > > The point is that you will need to perform some conniptions of this > > sort > > > in > > > > order to fix your repositories, otherwise your changes will remain > > > > incompatible with the Buildr mainline trunk: you won't be able to > > > (easily) > > > > merge assaf/master, and he won't be able to (easily) pull from you. > > > > > > > > Incidentally, if anyone has a *better* way of doing this > (particularly > > > one > > > > where the entire master history doesn't get wiped out), I'm all ears! > > I > > > do > > > > still have the unmerged repository sitting in Time Machine, so I'm > > > > perfectly > > > > willing to roll-forward a copy and try again if the result turns out > to > > > be > > > > more correct. > > > > > > > > > Thanks. > > > > > > > > > AFAIK it's not possible to git svn clone directly from > svn.apache.orgdue > > > to > > > some weird restriction they placed on the SVN server, it will just keep > > > git-svn hanging forever. Somehow that doesn't affect incubator > projects, > > or > > > svn.eu.apache.org, although my starting point was Jukka's unofficial > but > > > somewhat official git mirror[1]. > > > > > > > > > When you git log, check the git-svn-id: > > > > > > commit a3ab30a66a092bf730950bd95a1394253ebd2f39 > > > > > > Author: Assaf Arkin <[email protected]> > > > > > > Date: Fri Feb 27 22:24:50 2009 +0000 > > > > > > > > > > Fixed RDoc 2.3/2.4 conflict on rake setup. > > > > > > > > > > > > git-svn-id: > > > > > > > > > https://svn.eu.apache.org/repos/asf/buildr/tr...@74872213f79535-47bb-0310-9956-ffa450edef68 > > > > > > > > > If two repositories use a different URL -- look for http vs https, > > > svn.eu.apache.org vs svn.apache.org, asf/buildr vs > asf/incubator/buildr > > -- > > > Git considers them distinct trees (branches). Any time you merge, Git > > will > > > have to merge the entire history of these two branches, leading to a > lot > > of > > > conflicts. > > > > > > So if you have branches with changes, follow Daniel's instructions. If > > you > > > don't, you can still use the -s ours strategy to "switch" from one > branch > > > to > > > another. > > > > > > Until Apache comes with a better solution, I'm going to keep my > > > repository synchronized against > > > https://svn.eu.apache.org/repos/asf/buildr. > > > I suggest you all do the same, that way we have the same history and > can > > > easily merge with each other. > > > > > > Assaf > > > > > > [1] http://jukka.zitting.name/git/ > > > > > > > > > > > > > > > > > > > > > Daniel > > > > > > > > > >
