aboutsummaryrefslogtreecommitdiff
path: root/perl/Git
Commit message (Collapse)AuthorAge
* git svn: consistent spacing after "W:" in warningsEric Wong2013-03-08
| | | | | | | All other instances of "W:"-prefixed warning messages have a space after the "W:" to help with readability. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git svn: ignore partial svn:mergeinfoJan Pešta2013-03-08
| | | | | | | | | | | | | | Currently this is cosmetic change - the merges are ignored, becuase the methods (lookup_svn_merge, find_rev_before, find_rev_after) are failing on comparing text with number. See http://www.open.collab.net/community/subversion/articles/merge-info.html Extract: The range r30430:30435 that was added to 1.5.x in this merge has a '*' suffix for 1.5.x\www. This '*' is the marker for a non-inheritable mergeinfo range. The '*' means that only the path on which the mergeinfo is explicitly set has had this range merged into it. Signed-off-by: Jan Pesta <jan.pesta@certicon.cz> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Merge branch 'bw/get-tz-offset-perl'Junio C Hamano2013-02-14
|\ | | | | | | | | | | | | * bw/get-tz-offset-perl: cvsimport: format commit timestamp ourselves without using strftime perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases Move Git::SVN::get_tz to Git::get_tz_offset
| * Move Git::SVN::get_tz to Git::get_tz_offsetBen Walton2013-02-09
| | | | | | | | | | | | | | | | | | | | | | | | This function has utility outside of the SVN module for any routine that needs the equivalent of GNU strftime's %z formatting option. Move it to the top-level Git.pm so that non-SVN modules don't need to import the SVN module to use it. The rename makes the purpose of the function clearer. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-svn: cleanup sprintf usage for uppercasing hexEric Wong2013-01-24
| | | | | | | | | | | | | | | | We do not need to call uc() separately for sprintf("%x") as sprintf("%X") is available. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
* | git-svn: do not escape certain characters in pathsPeter Wu2013-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subversion 1.7 and newer implement HTTPv2, an extension that should make HTTP more efficient. Servers with support for this protocol will make the subversion client library take an alternative code path that checks (with assertions) whether the URL is "canonical" or not. This patch fixes an issue I encountered while trying to `git svn dcommit` a rename action for a file containing a single quote character ("User's Manual" to "UserMan.tex"). It does not happen for older subversion 1.6 servers nor non-HTTP(S) protocols such as the native svn protocol, only on an Apache server shipping SVN 1.7. Trying to `git svn dcommit` under the aforementioned conditions yields the following error which aborts the commit process: Committing to http://example.com/svn ... perl: subversion/libsvn_subr/dirent_uri.c:1520: uri_skip_ancestor: Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed. error: git-svn died of signal 6 An analysis of the subversion source for the cause: - The assertion originates from uri_skip_ancestor which calls svn_uri_is_canonical, which fails when the URL contains percent-encoded values that do not necessarily have to be encoded (not "canonical" enough). This is done by a table lookup in libsvn_subr/path.c. Putting some debugging prints revealed that the character ' is indeed encoded to %27 which is not considered canonical. - url_skip_ancestor is called by svn_ra_neon__get_baseline_info with the root repository URL and path as parameters; - which is called by copy_resource (libsvn_ra_neon/commit.c) for a copy action (or in my case, renaming which is actually copy + delete old); - which is called by commit_add_dir; - which is assigned as a structure method "add_file" in svn_ra_neon__get_commit_editor. In the whole path, the path argument is not modified. Through some more uninteresting wrapper functions, the Perl bindings gives you access to the add_file method which will pass the path argument without modifications to svn. git-svn calls the "R"(ename) subroutine in Git::SVN::Editor which contains: 326 my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat, 327 $self->url_path($m->{file_a}), $self->{r}); "repo_path" basically returns the path as-is, unless the "svn.pathnameencoding" configuration property is set. "url_path" tries to escape some special characters, but does not take all special characters into account, thereby causing the path to contain some escaped characters which do not have to be escaped. The list of characters not to be escaped are taken from the subversion/libsvn_subr/path.c file to fully account for all characters. Tested with a filename containing all characters in the range 0x20 to 0x78 (inclusive). Signed-off-by: Peter Wu <lekensteyn@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | git svn: do not overescape URLs (fallback case)Jonathan Nieder2013-01-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subversion's canonical URLs are intended to make URL comparison easy and therefore have strict rules about what characters are special enough to urlencode and what characters should be left alone. When in the fallback codepath because unable to use libsvn's own canonicalization function for some reason, escape special characters in URIs according to the svn_uri__char_validity[] table in subversion/libsvn_subr/path.c (r935829). The libsvn versions that trigger this code path are not likely to be strict enough to care, but it's nicer to be consistent. Noticed by using SVN 1.6.17 perl bindings, which do not provide SVN::_Core::svn_uri_canonicalize (triggering the fallback code), with libsvn 1.7.5, whose do_switch is fussy enough to care: Committing to file:///home/jrn/src/git/t/trash%20directory.\ t9118-git-svn-funky-branch-names/svnrepo/pr%20ject/branches\ /more%20fun%20plugin%21 ... svn: E235000: In file '[...]/subversion/libsvn_subr/dirent_uri.c' \ line 2291: assertion failed (svn_uri_is_canonical(url, pool)) error: git-svn died of signal 6 not ok - 3 test dcommit to funky branch After this change, the '!' in 'more%20fun%20plugin!' is not urlencoded and t9118 passes again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | Git::SVN::Editor::T: pass $deletions to ->A and ->DJonathan Nieder2013-01-17
|/ | | | | | | | | | This shouldn't make a difference because the $deletions hash is only used when adding a directory (see 379862ec, 2012-02-20) but it's nice to be consistent to make reading smoother anyway. No functional change intended. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn, perl/Git.pm: extend and use Git->prompt method for querying usersSven Strickroth2012-12-17
| | | | | | | | | | | | | | git-svn reads usernames and other user queries from an interactive terminal. This cause GUIs (w/o STDIN connected) to hang waiting forever for git-svn to complete (http://code.google.com/p/tortoisegit/issues/detail?id=967). This change extends the Git::prompt helper, so that it can also be used for non password queries, and makes use of it instead of using hand-rolled prompt-response code that only works with the interactive terminal. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-svn, perl/Git.pm: add central method for prompting passwordsSven Strickroth2012-12-17
| | | | | | | | | | | | | | | | git-svn reads passwords from an interactive terminal or by using GIT_ASKPASS helper tool. This cause GUIs (w/o STDIN connected) to hang waiting forever for git-svn to complete (http://code.google.com/p/tortoisegit/issues/detail?id=967). Commit 56a853b62c0ae7ebaad0a7a0a704f5ef561eb795 also tried to solve this issue, but was incomplete as described above. Instead of using hand-rolled prompt-response code that only works with the interactive terminal, a reusable prompt() method is introduced in this commit. Signed-off-by: Sven Strickroth <email@cs-ware.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git svn: work around SVN 1.7 mishandling of svn:special changesJonathan Nieder2012-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subversion represents symlinks as ordinary files with content starting with "link " and the svn:special property set to "*". Thus a file can switch between being a symlink and a non-symlink simply by toggling its svn:special property, and new checkouts will automatically write a file of the appropriate type. Likewise, in subversion 1.6 and older, running "svn update" would notice changes in filetype and update the working copy appropriately. Starting in subversion 1.7 (issue 4091), changes to the svn:special property trip an assertion instead: $ svn up svn-tree Updating 'svn-tree': svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \ line 1583: assertion failed (action == svn_wc_conflict_action_edit \ || action == svn_wc_conflict_action_delete || action == \ svn_wc_conflict_action_replace) Revisions prepared with ordinary svn commands ("svn add" and not "svn propset") don't trip this because they represent these filetype changes using a replace operation, which is approximately equivalent to removal followed by adding a new file and works fine. Follow suit. Noticed using t9100. After this change, git-svn's file-to-symlink changes are sent in a format that modern "svn update" can handle and tests t9100.11-13 pass again. [ew: s,git-svn\.perl,perl/Git/SVN/Editor.pm,g] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: keep leading slash when canonicalizing paths (fallback case)Jonathan Nieder2012-10-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subversion's svn_dirent_canonicalize() and svn_path_canonicalize() APIs keep a leading slash in the return value if one was present on the argument, which can be useful since it allows relative and absolute paths to be distinguished. When git-svn's canonicalize_path() learned to use these functions if available, its semantics changed in the corresponding way. Some new callers rely on the leading slash --- for example, if the slash is stripped out then _canonicalize_url_ourselves() will transform "proto://host/path/to/resource" to "proto://hostpath/to/resource". Unfortunately the fallback _canonicalize_path_ourselves(), used when the appropriate SVN APIs are not usable, still follows the old semantics, so if that code path is exercised then it breaks. Fix it to follow the new convention. Noticed by forcing the fallback on and running tests. Without this patch, t9101.4 fails: Bad URL passed to RA layer: Unable to open an ra_local session to \ URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\ t9101-git-svn-props/svnrepo' contains unsupported hostname at \ /home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148 With it, the git-svn tests pass again. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Git::SVN: rename private path fieldJonathan Nieder2012-10-05
| | | | | | | | | All users of $gs->{path} should have been converted to use the accessor by now. Check our work by renaming the underlying variable to break callers that try to use it directly. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: use path accessor for Git::SVN objectsEric Wong2012-10-05
| | | | | | | | The accessors should improve maintainability and enforce consistent access to Git::SVN objects. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
* Make git-svn branch patterns match complete URLAmmon Riley2012-10-05
| | | | | | | | | | | | | | | | | | | | | | | | | When using the {word,[...]} style of configuration for tags and branches, it appears the intent is to only match whole path parts, since the words in the {} pattern are meta-character quoted. When the pattern word appears in the beginning or middle of the url, it's matched completely, since the left side, pattern, and (non-empty) right side are joined together with path separators. However, when the pattern word appears at the end of the URL, the right side is an empty pattern, and the resulting regex matches more than just the specified pattern. For example, if you specify something along the lines of branches = branches/project/{release_1,release_2} and your repository also contains "branches/project/release_1_2", you will also get the release_1_2 branch. By restricting the match regex with anchors, this is avoided. Signed-off-by: Ammon Riley <ammon.riley@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn.perl: keep processing all commits in parents_excludeSteven Walter2012-10-05
| | | | | | | | | | | This fixes a bug where git finds the incorrect merge parent. Consider a repository with trunk, branch1 of trunk, and branch2 of branch1. Without this change, git interprets a merge of branch2 into trunk as a merge of branch1 into trunk. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Reviewed-by: Sam Vilain <sam@vilain.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tipSteven Walter2012-10-05
| | | | | | | | | | | | | | Consider the case where you have trunk, branch1 of trunk, and branch2 of branch1. trunk is merged back into branch2, and then branch2 is reintegrated into trunk. The merge of branch2 into trunk will have svn:mergeinfo property references to both branch1 and branch2. When git-svn fetches the commit that merges branch2 (check_cherry_pick), it is necessary to eliminate the merged contents of branch1 as well as branch2, or else the merge will be incorrectly ignored as a cherry-pick. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Reviewed-by: Sam Vilain <sam@vilain.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Merge branch 'ms/git-svn-1.7'Junio C Hamano2012-08-22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A series by Michael Schwern via Eric to update git-svn to revamp the way URLs are internally passed around, to make it work with SVN 1.7. * ms/git-svn-1.7: git-svn: remove ad-hoc canonicalizations git-svn: canonicalize newly-minted URLs git-svn: introduce add_path_to_url function git-svn: canonicalize earlier git-svn: replace URL escapes with canonicalization git-svn: attempt to mimic SVN 1.7 URL canonicalization t9107: fix typo t9118: workaround inconsistency between SVN versions Git::SVN{,::Ra}: canonicalize earlier git-svn: path canonicalization uses SVN API Git::SVN::Utils: remove irrelevant comment git-svn: add join_paths() to safely concatenate paths git-svn: factor out _collapse_dotdot function git-svn: use SVN 1.7 to canonicalize when possible git-svn: move canonicalization to Git::SVN::Utils use Git::SVN{,::RA}->url accessor globally use Git::SVN->path accessor globally Git::SVN::Ra: use accessor for URLs Git::SVN: use accessor for URLs internally Git::SVN: use accessors internally for path
| * git-svn: remove ad-hoc canonicalizationsMichael G. Schwern2012-08-02
| | | | | | | | | | | | [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: canonicalize newly-minted URLsMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Go through all the spots that use the new add_path_to_url() to make a new URL and canonicalize them. * copyfrom_path has to be canonicalized else find_parent_branch will get confused * due to the `canonicalize_url($full_url) ne $full_url)` line of logic in gs_do_switch(), $full_url is left alone until after. At this point SVN 1.7 passes except for 3 tests in t9100-git-svn-basic.sh that look like an SVN bug to do with symlinks. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: introduce add_path_to_url functionMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the ad-hoc versions. This is mostly to normalize the process and ensure the URLs produced don't have double slashes or anything. Also provides a place to fix the corner case where a file path contains a percent sign. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: canonicalize earlierMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | Just a few things I noticed. Its good to canonicalize as early as possible. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: replace URL escapes with canonicalizationMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old hand-rolled URL escape functions were inferior to canonicalization functions. Continuing to move towards getting everything canonicalizing the same way. * Git::SVN->init_remote_config and Git::SVN::Ra->minimize_url both have to canonicalize the same way else init_remote_config will incorrectly think they're different URLs causing t9107-git-svn-migrate.sh to fail. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: attempt to mimic SVN 1.7 URL canonicalizationMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, our URL canonicalization didn't do much of anything. Now it actually escapes and collapses slashes. This is mostly a cut & paste of escape_url from git-svn. This is closer to how SVN 1.7's canonicalization behaves. Doing it with 1.6 lets us chase down some problems caused by more effective canonicalization without having to deal with all the other 1.7 issues on top of that. * Remote URLs have to be canonicalized otherwise Git::SVN->find_existing_remote will think they're different. * The SVN remote is now written to the git config canonicalized. That should be ok. Adjust a test to account for that. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * Git::SVN{,::Ra}: canonicalize earlierMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This canonicalizes paths and urls as early as possible so we don't have to remember to do it at the point of use. It will fix a swath of SVN 1.7 problems in one go. Its ok to double canonicalize things. SVN 1.7 still fails, still not worrying about that. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: path canonicalization uses SVN APIMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All tests pass with SVN 1.6. SVN 1.7 remains broken, not worrying about it yet. SVN changed its path canonicalization API between 1.6 and 1.7. http://svnbook.red-bean.com/en/1.6/svn.developer.usingapi.html#svn.developer.usingapi.urlpath http://svnbook.red-bean.com/en/1.7/svn.developer.usingapi.html#svn.developer.usingapi.urlpath The SVN API does not accept foo/.. but it also doesn't canonicalize it. We have to do it ourselves. [ew: commit title, fall back if SVN <= 1.6 fails to canonicalize] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * Git::SVN::Utils: remove irrelevant commentMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | The code doesn't use File::Spec. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: add join_paths() to safely concatenate pathsMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise you might wind up with things like... my $path1 = undef; my $path2 = 'foo'; my $path = $path1 . '/' . $path2; creating '/foo'. Or this... my $path1 = 'foo/'; my $path2 = 'bar'; my $path = $path1 . '/' . $path2; creating 'foo//bar'. Could have used File::Spec, but I'm shying away from it due to SVN 1.7's pickiness about paths. Felt it would be better to have our own we can control completely. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: factor out _collapse_dotdot functionMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The SVN API functions will not accept ../foo but their canonicalization functions will not collapse it. So we'll have to do it ourselves. _collapse_dotdot() works better than the existing regex did. This will be used shortly when canonicalize_path() starts using the SVN API. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: use SVN 1.7 to canonicalize when possibleMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | No change on SVN 1.6. The tests all pass with SVN 1.6 if canonicalize_url() does nothing, so tests passing doesn't have much meaning. The tests are so messed up right now with SVN 1.7 it isn't really useful to check. They will be useful later. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * git-svn: move canonicalization to Git::SVN::UtilsMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | So they can be used by others. I'd like to test them, but they're going to become SVN API wrappers shortly and those aren't predictable. No functional change. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * use Git::SVN{,::RA}->url accessor globallyMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | Note: The structure returned from Git::SVN->read_all_remotes() does not appear to contain objects, so I'm leaving them alone. That's everything converted over to the url and path accessors. No functional change. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * use Git::SVN->path accessor globallyMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | No functional change. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * Git::SVN::Ra: use accessor for URLsMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | | | Later it can canonicalize automatically. A later change will make other things use the accessor. No functional change. [ew: commit title, reformatted accessor to match existing style] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * Git::SVN: use accessor for URLs internallyMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | So later it can do automatic canonicalization. A later patch will make other things use the accessor. No functional change here. [ew: commit title] Signed-off-by: Eric Wong <normalperson@yhbt.net>
| * Git::SVN: use accessors internally for pathMichael G. Schwern2012-08-02
| | | | | | | | | | | | | | | | | | | | | | Then later it can be canonicalized automatically rather than everywhere its used. Later patch will make other things use it. [ew: commit title, reformatted accessor to match existing style] Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | git svn: reset invalidates the memoized mergeinfo cachesPeter Baumann2012-08-10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30), git-svn has maintained some private per-repository caches in .git/svn/.caches to avoid refetching and recalculating some mergeinfo-related information with every 'git svn fetch'. This memoization can cause problems, e.g consider the following case: SVN repo: ... - a - b - c - m <- trunk \ / d - e <- branch1 The Git import of the above repo is at commit 'a' and doesn't know about the branch1. In case of an 'git svn rebase', only the trunk of the SVN repo is imported. During the creation of the git commit 'm', git svn uses the svn:mergeinfo property and tries to find the corresponding git commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase only imports the current branch so commit 'e' is not imported. Therefore git svn fails to create commit 'm' as a merge commit, because one of its parents is not known to git. The imported history looks like this: ... - a - b - c - m <- trunk A later 'git svn fetch' to import all branches can't rewrite the commit 'm' to add 'e' as a parent and to make it a real git merge commit, because it was already imported. That's why the imported history misses the merge and looks like this: ... - a - b - c - m <- trunk \ d - e <- branch1 Right now the only known workaround for importing 'm' as a merge is to force reimporting 'm' again from SVN, e.g. via $ git svn reset --revision $(git find-rev $c) $ git svn fetch Sadly, this is where the behavior has regressed: git svn reset doesn't invalidate the old mergeinfo cache, which is no longer valid for the reimport, which leads to 'm' beeing imprted with only 'c' as parent. As solution to this problem, this commit invalidates the mergeinfo cache to force correct recalculation of the parents. During development of this patch, several ways for invalidating the cache where considered. One of them is to use Memoize::flush_cache, which will call the CLEAR method on the underlying Memoize persistency implementation. Sadly, neither Memoize::Storable nor the newer Memoize::YAML module introduced in 68f532f4ba888 could optionally be used implement the CLEAR method, so this is not an option. Reseting the internal hash used to store the memoized values has the same problem, because it calls the non-existing CLEAR method of the underlying persistency layer, too. Considering this and taking into account the different implementations of the memoization modules, where Memoize::Storable is not in our control, implementing the missing CLEAR method is not an option, at least not if Memoize::Storable is still used. Therefore the easiest solution to clear the cache is to delete the files on disk in 'git svn reset'. Normally, deleting the files behind the back of the memoization module would be problematic, because the in-memory representation would still exist and contain wrong data. Fortunately, the memoization is active in memory only for a small portion of the code. Invalidating the cache by deleting the files on disk if it isn't active should be safe. Signed-off-by: Peter Baumann <waste.manager@gmx.de> Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN::GlobSpec from git-svn.Michael G. Schwern2012-07-27
| | | | | | | | Straight cut & paste. That's the last class. * Make Git::SVN load it on its own, its the only thing that needs it. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Move Git::IndexInfo into its own file.Michael G. Schwern2012-07-27
| | | | | | Straight cut & paste. Didn't require any fixing. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN::Migration from git-svn.Michael G. Schwern2012-07-27
| | | | | | Straight cut & paste. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN::Log from git-svn.Michael G. Schwern2012-07-27
| | | | | | | | Straight cut & paste. Also noticed Git::SVN::Ra wasn't in the compile test. It is now. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Move initialization of Git::SVN variables into Git::SVN.Michael G. Schwern2012-07-27
| | | | | | | Also it can compile on its own now, yay! Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract Git::SVN from git-svn into its own .pm file.Michael G. Schwern2012-07-27
| | | | | | | | | | Except for adding the 1; at the end, this is a straight copy & paste. Tests still pass, but its doubtful Git::SVN will compile on its own without git-svn being loaded. Next commit will fix that. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Extract some utilities from git-svn to allow extracting Git::SVN.Michael G. Schwern2012-07-27
| | | | | | | | | | | | | | | | Put them in a new module called Git::SVN::Utils. Yeah, not terribly original and it will be a dumping ground. But its better than having them in the main git-svn program. At least they can be documented and tested. * fatal() is used by many classes. * Change the $can_compress lexical into a function. This should be enough to extract Git::SVN. Signed-off-by: Michael G. Schwern <schwern@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: use YAML format for mergeinfo cache when possibleJonathan Nieder2012-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30), git-svn has maintained some private per-repository caches in .git/svn/.caches to avoid refetching and recalculating some mergeinfo-related information with every "git svn fetch". These caches use the 'nstore' format from the perl core module Storable, which can be read and written quickly and was designed for transfer over the wire (the 'n' stands for 'network'). This format is endianness-independent and independent of floating-point representation. Unfortunately the format is *not* independent of the perl version --- new perl versions will write files that very old perl cannot read. Worse, the format is not independent of the size of a perl integer. So if you toggle perl's use64bitint compile-time option, then using 'git svn fetch' on your old repositories produces errors like this: Byte order is not compatible at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 380, at /usr/share/perl/5.12/Memoize/Storable.pm line 21 That is, upgrading perl to a version that uses use64bitint for the first time makes git-svn suddenly refuse to fetch in existing repositories. Removing .git/svn/.caches lets git-svn recover. It's time to switch to a platform independent serializer backend with better compatibility guarantees. This patch uses YAML::Any. Other choices were considered: - thawing data from Data::Dumper involves "eval". Doing that without creating a security risk is fussy. - the JSON API works on scalars in memory and doesn't provide a standard way to serialize straight to disk. YAML::Any is reasonably fast and has a pleasant API. In most backends, LoadFile() reads the entire file into a scalar anyway and converts it as a second step, but having an interface that allows the deserialization to happen on the fly without a temporary is still a comfort. YAML::Any is not a core perl module, so we take care to use it when and only when it is available. Installations without that module should fall back to using Storable with all its quirks, keeping their cache files in .git/svn/.caches/*.db Installations with YAML peacefully coexist by keeping a separate set of cache files in .git/svn/.caches/*.yaml. In most cases, switching between is a one-time thing, so it doesn't seem worth the complication to migrate existing caches. The upshot: after this patch, as long as YAML::Any is installed you can move your git repository between machines with different perl installations and "git svn fetch" will work fine. If you do not have YAML::Any, the behavior is unchanged (and in particular does not get any worse). Reported-by: Sandro Weiser <sandro.weiser@informatik.tu-chemnitz.de> Reported-by: Bdale Garbee <bdale@gag.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: make Git::SVN::RA a separate fileJonathan Nieder2012-06-10
| | | | | | | | | | | | | | | | | This slices off another 600 or so lines from the frighteningly long git-svn.perl script. The Git::SVN::Ra interface is similar enough to SVN::Ra that it is probably safe to ignore most of its implementation on first reading. (Documenting or moving functions that do not fit that pattern is left as an exercise to the interested reader.) [ew: rebased and fixed conflict against commit c26ddce86d7215b4d9687bd4c6b5dd43a3fabf31 (git-svn: platform auth providers are working only on 1.6.15 or newer)] Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: make Git::SVN::Editor a separate fileJonathan Nieder2012-06-10
| | | | | | | | | This makes the git-svn script shorter and less scary for beginners to read through for the first time. Take the opportunity to explain the purpose and basic interface of the Git::SVN::Editor class while at it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: make Git::SVN::Fetcher a separate fileJonathan Nieder2012-05-29
| | | | | | | | | | This patch removes a chunk of code (the Git::SVN::Fetcher consumer of libsvn's tree delta protocol) from git-svn.perl and documents its interface so the hurried reader does not have to read that code right away. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* git-svn: move Git::SVN::Prompt into its own fileJonathan Nieder2012-05-29
| | | | | | | | | | | | | | | | | | | | git-svn.perl is very long (around 6500 lines) and although it is nicely split into modules, some new readers do not even notice --- it is too distracting to see all this functionality collected in a single file. Splitting it into multiple files would make it easier for people to read individual modules straight through and to experiment with components separately. Let's start with Git::SVN::Prompt. For simplicity, we install this as a module in the standard search path, just like the existing Git and Git::I18N modules. In the process, add a manpage explaining its interface and that it is not likely to be useful for other projects to avoid confusion. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Git::I18N: compatibility with perl <5.8.3Ævar Arnfjörð Bjarmason2012-03-10
| | | | | | | | | | Change the Exporter invocation in Git::I18N to be compatible with 5.8.0 to 5.8.2 inclusive. Before Exporter 5.57 (released with 5.8.3) Exporter didn't export the 'import' subroutine. Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-28 18:11:25 +0000