RE: recovering from unordered stage entries in index error
see these commands, or something else. Could you try again with GIT_TRACE=/absolute/path/to/some/where instead of GIT_TRACE=2 and post the content of /abso../some/where? It looks the same as far as I can see: $ GIT_TRACE=/tmp/git-trace git svn fetch fatal: unordered stage entries in index write-tree: command returned error: 128 $ egrep -i 'read|tree|update|index' /tmp/git-trace 13:26:08.169921 git.c:348 trace: built-in: git 'write-tree' $ cat /tmp/git-trace 09:26:07.402735 git.c:557 trace: exec: 'git-svn' 'fetch' 09:26:07.402784 run-command.c:351 trace: run_command: 'git-svn' 'fetch' 09:26:07.688866 git.c:348 trace: built-in: git 'rev-parse' '--show-prefix' 13:26:07.691207 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 13:26:07.693228 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup' 13:26:07.695594 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet' 13:26:07.697279 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog' 13:26:07.699030 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths' 13:26:07.700914 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile' 13:26:07.702872 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent' 13:26:07.704949 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir' 13:26:07.706674 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime' 13:26:07.708590 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps' 13:26:07.710669 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps' 13:26:07.712602 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache' 13:26:07.714527 git.c:348 trace: built-in: git 'config' '--get' 'svn.username' 13:26:07.716257 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize' 13:26:07.717872 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata' 13:26:07.719905 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorerefs' 13:26:07.721623 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths' 13:26:07.723485 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout' 13:26:07.725441 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom' 13:26:07.727125 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags' 13:26:07.729179 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack' 13:26:07.731143 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor' 13:26:07.733139 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent' 13:26:07.734911 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall' 13:26:07.736992 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision' 13:26:07.739398 git.c:348 trace: built-in: git 'rev-parse' '--symbolic' '--all' 13:26:07.744514 git.c:348 trace: built-in: git 'config' '-l' 13:26:07.746770 git.c:348 trace: built-in: git 'config' '-l' 13:26:07.749108 git.c:348 trace: built-in: git 'config' '--bool' 'svn.useSvmProps' 13:26:07.751613 git.c:348 trace: built-in: git 'config' '-l' 13:26:07.907707 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.branches-maxRev' 13:26:07.910171 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.tags-maxRev' 13:26:07.912608 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.url' 13:26:07.915539 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.pushurl' 13:26:07.917825 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.uuid' 13:26:07.919620 git.c:348 trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0' 13:26:07.923752 git.c:348 trace: built-in: git 'rev-list' '--pretty=raw' '--reverse' '74332b7d653cde7ba3b999cc7b0adcfd9d924440..refs/remotes/trunk' '--' 13:26:07.926128 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot' 13:26:07.928707 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteUUID' 13:26:07.933621 git.c:348 trace: built-in: git 'cat-file' '--batch' 13:26:08.150396 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '231655' 13:26:08.152963 git.c:348 trace: built-in: git 'config' 'svn-remote.svn.tags-maxRev' '231655'
RE: recovering from unordered stage entries in index error
Per Junio's email, with core.quotepath=false, there are no differences with sorting in either ls-files or the tree named in the GIT_TRACE_2 output: $ git config --local core.quotepath false $ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 ls-tree $ LANG=C LC_ALL=C sort ls-tree ls-tree-sorted-lc-all $ diff -s ls-tree ls-tree-sorted-lc-all Files ls-tree and ls-tree-sorted-lc-all are identical $ git ls-files ls-files $ LANG=C LC_ALL=C sort ls-files ls-files-sorted-lc-all $ diff -s ls-files ls-files-sorted-lc-all Files ls-files and ls-files-sorted-lc-all are identical From: McHenry, Matt Sent: Friday, May 22, 2015 10:47 PM To: Duy Nguyen Cc: Junio C Hamano; git@vger.kernel.org Subject: RE: recovering from unordered stage entries in index error So maybe you can do GIT_TRACE=2 git svn fetch and post the output. I'd expect to see something like git read-tree sha1 before fatal: unorder You can then use git ls-tree sha1 to examine this tree, try to sort the file list with LANG=C sort and compare with the original list. There is no read-tree in the output (below). The sha1 that is mentioned, 74332b7, is the one for the current trunk: $ git svn log -1 --show-commit --oneline trunk r231655 | 74332b7 | CLT: changed skill from not compound to compound. So not surprisingly, I guess, I get basically the same results as with the ls-files commands earlier: files with Unicode chars are quoted and sort at the front: $ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 ls-tree $ LANG=C LC_ALL=C sort ls-tree ls-tree-sorted-lc-all $ grep -n Ninja__Beta ls-tree* ls-tree:36974:curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip ls-tree-sorted-lc-all:89:curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip (Just sorting with LANG=C but without LC_ALL=C produced a ton of other differences, mostly around numeric vs. lexical ordering as far as I could tell.) I tried this same thing with my test repo, and it exhibits the same quoted-filename-sorts-to-the-top behaviour, but does not exhibit the git svn fetch write-tree error. $ GIT_TRACE=2 git svn fetch 22:21:16.683918 git.c:557 trace: exec: 'git-svn' 'fetch' 22:21:16.683945 run-command.c:351 trace: run_command: 'git-svn' 'fetch' 02:21:16.918593 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 02:21:16.920218 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup' 02:21:16.921997 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall' 02:21:16.923609 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack' 02:21:16.925164 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags' 02:21:16.926706 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision' 02:21:16.928847 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout' 02:21:16.930410 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps' 02:21:16.931963 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime' 02:21:16.933538 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths' 02:21:16.935107 git.c:348 trace: built-in: git 'config' '--get' 'svn.username' 02:21:16.936675 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache' 02:21:16.940413 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet' 02:21:16.942064 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor' 02:21:16.943696 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata' 02:21:16.945344 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps' 02:21:16.947607 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent' 02:21:16.950737 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom' 02:21:16.952532 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog' 02:21:16.954133 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths' 02:21:16.955704 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent' 02:21:16.957287 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir' 02:21:16.958930 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile' 02:21:16.962142 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize' 02:21:16.963913 git.c:348 trace
RE: recovering from unordered stage entries in index error
Yes, that does turn up some interesting stuff. It looks like the repository contains some paths with non-ASCII characters, for example this one has some en-dashes (U+2013) in its name: $ svn ls -R svn://dev/trunk/curriculum/Fluency | grep Ninja__Beta Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 – Ninja/FT3 – Ninja__Beta.zip $ svn ls -R svn://dev/trunk/curriculum/Fluency | grep Ninja__Beta | od -cx 000 H u r i x w o r k / s o u r c 7548697220786f776b72732f756f6372 020 e f r o m M a y 2 0 1 4 / 206572666d6f4d207961322031302f34 040 F o r _ A n e s h / 0 6 D e l 6f465f726e4173652f68363044206c65 060 i v e r a b l e s / P h a s e 766972656261656c2f73685073612065 100 2 / F T 3 342 200 223 N i n j a / 2f325446203380e22093694e6a6e2f61 120 F T 3 342 200 223 N i n j a _ _ B 5446203380e22093694e6a6e5f61425f 140 e t a . z i p \n 74652e61697a0a70 150 In the output of 'git ls-files', those paths appear quoted (there are almost 100 of them): $ git ls-files | grep Ninja__Beta curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip $ git ls-files | grep ^\ | wc -l 89 In the diff you suggested, 'sort' puts those paths at the absolute top of the list, while plain old ls-files puts them inline with the rest of the contents of the curriculum/ subdir: $ grep -n Ninja__Beta Q R Q:36109:curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip R:89:curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip Also, I have the curriculum/Fluency/ directory marked as sparse-checkout: $ cat .git/info/sparse-checkout /* !/curriculum/Fluency/ !/curriculum/Problems/lisp/ !/curriculum/Problems/lisp_es/ !/curriculum/Problems/sdk/Geometry/ !/curriculum/Problems/sdk_es/Geometry/ !/curriculum/Problems/sdk/Test-Questions/ !/curriculum/Problems/sdk_es/Test-Questions/ !/curriculum/Problems/sdk/Grammar/ However, I tried to construct a test case that would reproduce this with a simple SVN repo containing a file created by 'touch make-git-svn-$(echo -e '\u201c')unhappy$(echo -e '\u201d')', but could not get it to fail. So there may be something more subtle going on here ... -Original Message- From: jch2...@gmail.com [mailto:jch2...@gmail.com] On Behalf Of Junio C Hamano Sent: Friday, May 22, 2015 15:25 To: McHenry, Matt Cc: git@vger.kernel.org Subject: Re: recovering from unordered stage entries in index error The message unordered stage entries in index comes only when two adjacent entries in the index are in a wrong order, e.g. test0 should come before test1 but somehow the index records them in the other way around. Doing something like this: $ git ls-files Q $ LANG=C LC_ALL=C sort Q R $ diff Q R may tell you which entries are wrong, even though it wouldn't show who made them wrong. (pardon top-posting, overlong lines and typos; sent from GMail web UI) On Tue, May 19, 2015 at 6:48 AM, McHenry, Matt mmche...@carnegielearning.com wrote: I've just upgraded my git from 2.0.5 to 2.3.6, and I'm now unable to run 'git svn fetch' in one of my repositories: $ git svn fetch fatal: unordered stage entries in index write-tree: command returned error: 128 'git status' shows a few untracked files but is otherwise clean. It looks like this check was introduced in 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary read_index_from(): catch out of order entries when reading an index file (first appearing in 2.2.0). Mailing list discussion looked like it implicated third-party tools. I don't recall running any other tools on this repo; it doesn't do much day-to-day other than a long series of 'git svn fetch'es. (But it's been around for a couple of years, so who knows.) At any rate, what can I do to recover from this situation? I tried to locate a path with multiple index entries like this, but got no results: $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \t]*1 ' (I originally posted on SO at http://stackoverflow.com/questions/30264826/; I'll update that with any solutions that come up here, to ease future googling.) -- To unsubscribe from this list: send the line
RE: recovering from unordered stage entries in index error
So maybe you can do GIT_TRACE=2 git svn fetch and post the output. I'd expect to see something like git read-tree sha1 before fatal: unorder You can then use git ls-tree sha1 to examine this tree, try to sort the file list with LANG=C sort and compare with the original list. There is no read-tree in the output (below). The sha1 that is mentioned, 74332b7, is the one for the current trunk: $ git svn log -1 --show-commit --oneline trunk r231655 | 74332b7 | CLT: changed skill from not compound to compound. So not surprisingly, I guess, I get basically the same results as with the ls-files commands earlier: files with Unicode chars are quoted and sort at the front: $ git ls-tree --name-only -r 74332b7d653cde7ba3b999cc7b0adcfd9d924440 ls-tree $ LANG=C LC_ALL=C sort ls-tree ls-tree-sorted-lc-all $ grep -n Ninja__Beta ls-tree* ls-tree:36974:curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip ls-tree-sorted-lc-all:89:curriculum/Fluency/Hurix work/source from May 2014/For_Anesh/06 Deliverables/Phase 2/FT3 \342\200\223 Ninja/FT3 \342\200\223 Ninja__Beta.zip (Just sorting with LANG=C but without LC_ALL=C produced a ton of other differences, mostly around numeric vs. lexical ordering as far as I could tell.) I tried this same thing with my test repo, and it exhibits the same quoted-filename-sorts-to-the-top behaviour, but does not exhibit the git svn fetch write-tree error. $ GIT_TRACE=2 git svn fetch 22:21:16.683918 git.c:557 trace: exec: 'git-svn' 'fetch' 22:21:16.683945 run-command.c:351 trace: run_command: 'git-svn' 'fetch' 02:21:16.918593 git.c:348 trace: built-in: git 'rev-parse' '--git-dir' 02:21:16.920218 git.c:348 trace: built-in: git 'rev-parse' '--show-cdup' 02:21:16.921997 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall' 02:21:16.923609 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.repack' 02:21:16.925164 git.c:348 trace: built-in: git 'config' '--get' 'svn.repackflags' 02:21:16.926706 git.c:348 trace: built-in: git 'config' '--get' 'svn.revision' 02:21:16.928847 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout' 02:21:16.930410 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps' 02:21:16.931963 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.localtime' 02:21:16.933538 git.c:348 trace: built-in: git 'config' '--get' 'svn.includepaths' 02:21:16.935107 git.c:348 trace: built-in: git 'config' '--get' 'svn.username' 02:21:16.936675 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache' 02:21:16.940413 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.quiet' 02:21:16.942064 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor' 02:21:16.943696 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata' 02:21:16.945344 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps' 02:21:16.947607 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.parent' 02:21:16.950737 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom' 02:21:16.952532 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsprog' 02:21:16.954133 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorepaths' 02:21:16.955704 git.c:348 trace: built-in: git 'config' '--bool' '--get' 'svn.followparent' 02:21:16.957287 git.c:348 trace: built-in: git 'config' '--get' 'svn.configdir' 02:21:16.958930 git.c:348 trace: built-in: git 'config' '--get' 'svn.authorsfile' 02:21:16.962142 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize' 02:21:16.963913 git.c:348 trace: built-in: git 'config' '--get' 'svn.ignorerefs' 02:21:16.966130 git.c:348 trace: built-in: git 'rev-parse' '--symbolic' '--all' 02:21:16.970537 git.c:348 trace: built-in: git 'config' '-l' 02:21:16.972410 git.c:348 trace: built-in: git 'config' '-l' 02:21:16.974187 git.c:348 trace: built-in: git 'config' '--bool' 'svn.useSvmProps' 02:21:16.976074 git.c:348 trace: built-in: git 'config' '-l' 02:21:17.136056 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.branches-maxRev' 02:21:17.137928 git.c:348 trace: built-in: git 'config' '--int' '--get' 'svn-remote.svn.tags-maxRev' 02:21:17.140124 git.c:348 trace: built-in: git 'config' '--get' 'svn-remote.svn.url' 02:21:17.142192
RE: recovering from unordered stage entries in index error
Isn't this failure coming from git-svn that tries to write out a tree after it prepared whatever it wants to record in its (possibly temporary) index? I have a feeling that the index held by the end user is not broken. Ahh that would explain why ls-files works. Yep. I created a copy of this repo + wc via rsync and tried a couple of things. 'git svn rebase -l' worked fine, but didn't fix the error. Next, reset: $ git svn log --limit=1 | grep ^r r231655 | avuong | 2015-05-10 10:32:16 -0400 (Sun, 10 May 2015) | 2 lines $ git svn reset -r 231655 -p r231653 = 13a7f6d6a3f3e44ed1c8523b1a63d72fc4f0ddb9 (refs/remotes/trunk) $ git svn fetch fatal: unordered stage entries in index write-tree: command returned error: 128 So it doesn't seem to be specific to the revision being fetched. I could do a more drastic 'git svn reset', but as you can see I've already fetched a lot of revs, so I'd rather avoid re-fetching if possible. Thanks for your help so far -- any other ideas (or requests for further debugging info) are appreciated!
RE: recovering from unordered stage entries in index error
This message can be improved to show what entries have this problem. Yes, that would definitely be a start. :) But then I don't see any way to recover the index manually. ls-files will die too. Perhaps we should be gentle in this case: show warnings Actually, ls-files succeeds on my broken index: $ git ls-files /dev/null $ echo $? 0 Could I do something with 'git read-tree' to force creation of a new valid index? I guess 'git clone' would work too, except that I have 'git svn' metadata that I'd need to preserve. instead of aborting the program and internally reorder the index. I think, unless you have multiple entries with the same stage, the recovered index should run well. The broken index could be renamed to index.broken or something for later analysis, or we forbid writing the reordered index to disk. Hmm? write-tree: command returned error: 128 'git status' shows a few untracked files but is otherwise clean. It looks like this check was introduced in 15999d0be8179fb7a2e6eafb931d25ed65df50aa, with the summary read_index_from(): catch out of order entries when reading an index file (first appearing in 2.2.0). Mailing list discussion looked like it implicated third-party tools. I don't recall running any other tools on this repo; it doesn't do much day-to-day other than a long series of 'git svn fetch'es. (But it's been around for a couple of years, so who knows.) At any rate, what can I do to recover from this situation? I tried to locate a path with multiple index entries like this, but got no results: $ git ls-files -s | cut -f 2-100 | sort | uniq -c | grep -v '^[ \t]*1 ' (I originally posted on SO at http://stackoverflow.com/questions/30264826/; I'll update that with any solutions that come up here, to ease future googling.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Duy
RE: git-svn with ignore-paths misses/skips some revisions during fetch
Enrico asked: Could it be that certain files spent parts of their historical lifetime inside the ignored paths ? I left out one possibly important piece of information: My initial 'git svn fetch' used '-r' to cauterize the history, both because there is a lot of it (almost 12 years) and because the repository was reorganized significantly after a cvs - svn migration. The first revision I have is r83875: $ git log --max-parents=0 --all --date-order | tail -n 1 git-svn-id: svn://dev.carnegielearning.com/trunk@83875 752fcc94-cd22-0410-baa8-ef54ac2c6973 So to answer Enrico's question: Prior to the initial revision that was fetched into git, these files did live in a different top-level directory. However it's not one that's matched by the 'ignore-paths' regex. Here's one example: $ svn log -v svn://dev/branches/localization-merge/buildprocess/antfiles/dmg.xml | grep /dmg.xml | uniq -c 9M /branches/localization-merge/buildprocess/antfiles/dmg.xml 35M /trunk/buildprocess/antfiles/dmg.xml 1A /trunk/buildprocess/antfiles/dmg.xml (from /trunk/buildprocess/assemble-support/dmg.xml:48305) 1D /trunk/buildprocess/assemble-support/dmg.xml 57M /trunk/assemble-support/dmg.xml 1A /trunk/assemble-support/dmg.xml Here are the svn revisions that explain the transition from 'assemble-support' to 'buildprocess/assemble-support', just after the cvs - svn migration. r48303 | matt | 2006-11-27 14:56:10 -0500 (Mon, 27 Nov 2006) | 1 line Changed paths: D /old-trunk/assemble-support A /trunk/buildprocess/assemble-support (from /old-trunk/assemble-support:48302) moving old assemble-support into new buildprocess r48248 | matt | 2006-11-22 13:41:42 -0500 (Wed, 22 Nov 2006) | 1 line Changed paths: A /old-trunk (from /trunk:48247) D /trunk moving old trunk out of the way Matt McHenry Software Developer Carnegie Learning, Inc. (888) 851-7094 x150 toll free (412) 690-2444 fax mmche...@carnegielearning.com www.carnegielearning.com Decision 2012: Election Math | Engaging Video Content | FREE Interactive Math Problems http://www.nbclearn.com/portal/site/learn/decision2012
git-svn with ignore-paths misses/skips some revisions during fetch
My company has a fairly large SVN repository, and I'm running into a bug with git-svn where some revisions aren't being fetched. The repository has a standard trunk/tags/branches layout, but there are some top-level directories under trunk/ that clearly don't belong in Git, and some that do. So, I've been experimenting with two approaches: a single git-svn clone that uses 'ignore-paths' to exclude the stuff that I don't want; and a series of per-subdir clones that use fetch = trunk/subdir:refs/remotes/trunk to pull in only that subdir. The problem is that the 'ignore-paths' approach sometimes misses commits during a fetch, and then at some later time will realize it and squash those changes onto some other, unrelated commit. (I've never seen this happen with the per-subdir 'fetch' approach.) Here are three commits in SVN: $ svn log -v -r 172602 -r 172605 -r 172626 svn://dev r172602 | matt | 2012-10-31 16:03:08 -0400 (Wed, 31 Oct 2012) | 1 line Changed paths: M /branches/localization-merge/buildprocess/antfiles/dmg.xml D /branches/localization-merge/buildprocess/resources/CDs/JavaApplicationStub M /branches/localization-merge/buildprocess/resources/launchanywhere/Cognitive Tutor.app.zip update to use newer java application stub r172605 | matt | 2012-10-31 16:29:25 -0400 (Wed, 31 Oct 2012) | 1 line Changed paths: M /branches/localization-merge/buildprocess/antfiles/dmg.xml M /branches/localization-merge/buildprocess/antfiles/lmstree.xml ensure that sdk-fe code is installed; fix to get correct app-dir value for antcalls; add problem authoring tool r172626 | leslie | 2012-11-01 08:49:36 -0400 (Thu, 01 Nov 2012) | 1 line Changed paths: M /branches/localization-merge/authoring/sdk/src/sdk-cc/src/main/java/cl/sdk/tdde/problemspace/problemtypes/geo/area/AreaPerimeterTutorInstance_PPV.java check the right shape-values for the gn The first two are not to be found in git: 'git log --all --grep 17260[25]' returns nothing. However, the third commit is there, and has had the changes from the earlier two (and some others) squashed into it somehow: $ git log --grep 172626 --numstat --summary commit 6d9a10abc17c74396e07bb4bc7692059ac0e8b99 Author: leslie leslie@752fcc94-cd22-0410-baa8-ef54ac2c6973 Date: Thu Nov 1 12:49:36 2012 + check the right shape-values for the gn git-svn-id: svn://dev.carnegielearning.com/branches/localization-merge@172626 752fcc94-cd22-0410-baa8-ef54ac2c6973 13 8 authoring/sdk/src/sdk-cc/src/main/java/cl/sdk/tdde/problemspace/problemtypes/geo/area/AreaPerimeterTutorInstance_PPV.java 11 2 buildprocess/antfiles/dmg.xml 2 0 buildprocess/antfiles/lmstree.xml - - buildprocess/resources/CDs/JavaApplicationStub - - buildprocess/resources/launchanywhere/Cognitive Tutor.app.zip 0 25 runtime/sdk-be/src/main/resources/cl/sdk/common/localized_words_es.properties 98155143 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules 773 5 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules_strings 773 5 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ctrules_strings_es 156279 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes 261 3 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes_strings 261 3 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.cttypes_strings_es 217 17 runtime/sdk-be/src/main/resources/cl/sdk/tdde/problemspace/problemtypes/scratchpads/scratchpad-tutor.ttspec 25 0 runtime/sdk-be/src/main/resources_es/cl/sdk/common/localized_words_es.properties 246 0 runtime/ui/src/main/resources/tp-tx-formula-sheet_es.html delete mode 100755 buildprocess/resources/CDs/JavaApplicationStub delete mode 100644 runtime/sdk-be/src/main/resources/cl/sdk/common/localized_words_es.properties create mode 100644 runtime/sdk-be/src/main/resources_es/cl/sdk/common/localized_words_es.properties create mode 100644 runtime/ui/src/main/resources/tp-tx-formula-sheet_es.html The directories on the server are: $ svn ls svn://dev/trunk IDEs/ QA-automation/ authoring/ bugtracking/ buildprocess/ curriculum/ doc/ images/ installer/ lib/ misc-tools/ research/ runtime/ scripts/ serversearch/ user-assistance/ web/ My config file is: $ cat
