Damn you, ash-cloud! Am 19.04.2010 um 19:28 schrieb Howard Lewis Ship:
> It's looking like the problem is access from Europe: > http://www.apache.org/dev/version-control.html#latest-baseline > > On Mon, Apr 19, 2010 at 9:19 AM, Robert Hailey <rob...@cmediacorp.com> wrote: >> >> On Apr 19, 2010, at 8:57 AM, Howard wrote: >> >>> Apache is stuck using Subversion ... >> >> Looks like you've already identified the root problem :) >> >>> Committed r935569 W: 86533530aac8673a9e107e323de5201b7187270f and >>> refs/remotes/origin/trunk differ, using rebase: :040000 040000 >>> 9c78596ee3f916f012c51d8927b4aa31d497f17b >>> 8eb2b9b4f28e825e223c736eaa664bb53018258e M tapestry-core Current branch >>> trunk is up to date. # of revisions changed before: >>> 07b37e03cbc17012247d2221e795023c564d8228 >>> 0830b5f383dc94ae16088185efefac2e1358cf30 >>> [...] >>> 79dcfa32b291454bf9c652d635374d60638b8fb8 >>> 304d12f9d7d040f4dc231d213df663fcdf3863b6 >>> 0d626a7b0648735ab83bc7a2fd241390eb92e4e2 after: >>> 86533530aac8673a9e107e323de5201b7187270f >>> [...] >>> 304d12f9d7d040f4dc231d213df663fcdf3863b6 >>> 0d626a7b0648735ab83bc7a2fd241390eb92e4e2 If you are attempting to >>> commit merges, try running: git rebase --interactive --preserve-merges >>> refs/remotes/origin/trunk Before dcommitting ~/work/t5-project $ >> >> Is the output really this garbled? It looks like it's dumping a list of >> commits when trying to simply get a count. >> >> At this point I would first check which version of git you are using. >> >>> I did the right things; git co trunk followed by git svn rebase, then >>> git rebase revised-assets-12apr2010. >> >> Without actually having used git with svn, I would bet that the order here >> is wrong. Whatever work "git svn rebase" has done to line up the git commits >> with the svn commits would be re-done by the second "normal" rebase. For the >> second command, perhaps try a 'merge' rather than a 'rebase'. >> >>> It claimed to replay my branch >>> changes on top of the trunk branch, but regardless, the dcommit failed. >>> Doing some hunting around with Google, I found a partial explanation, >>> that at least gives me a way forward. I'd still like to know how I got >>> into this predicament. >>> At this point I just keep blindly entering the command: git reset >>> --hard 705ccfb1e27d303a9db62de755b2fcfcca9a02f6 ; git svn rebase; git >>> svn dcommit and get one Git commit further each time (that's the Git >>> hash code for my final change in my original branch). Joy. >> >> Well... I suppose at worst you could make a quick shell script to repeat >> that until the head matches the expected value. >> >> If you do not have a git branch visualizer (like gitx / gitk), I recommend >> you get one. You may find that the hash you are reseting to is not from the >> branch you expect (or that svn expects). >> >> -- >> Robert Hailey >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
