user/sven/git.git/perl, branch v1.8.0.2

git svn: work around SVN 1.7 mishandling of svn:special changes

2012-10-10T20:02:33Z

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 Signed-off-by: Eric Wong

git-svn: keep leading slash when canonicalizing paths (fallback case)

2012-10-05T22:52:52Z

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 Signed-off-by: Eric Wong

Git::SVN: rename private path field

2012-10-05T22:48:12Z

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 Signed-off-by: Eric Wong

git-svn: use path accessor for Git::SVN objects

2012-10-05T22:48:12Z

The accessors should improve maintainability and enforce consistent access to Git::SVN objects. Signed-off-by: Eric Wong Reviewed-by: Jonathan Nieder

Make git-svn branch patterns match complete URL

2012-10-05T22:48:12Z

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 Signed-off-by: Eric Wong

git-svn.perl: keep processing all commits in parents_exclude

2012-10-05T22:48:12Z

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 Reviewed-by: Sam Vilain Signed-off-by: Eric Wong

git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip

2012-10-05T22:48:12Z

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 Reviewed-by: Sam Vilain Signed-off-by: Eric Wong

Merge branch 'ms/git-svn-1.7'

2012-08-22T18:51:20Z

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: reset invalidates the memoized mergeinfo caches

2012-08-10T19:53:18Z

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 Signed-off-by: Steven Walter Signed-off-by: Eric Wong

git-svn: remove ad-hoc canonicalizations

2012-08-02T21:46:06Z

[ew: commit title] Signed-off-by: Eric Wong