Commit Graph

20 Commits

Author SHA1 Message Date
Eric Wong
1b67bef256 git-svn: cleanup sprintf usage for uppercasing hex
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>
2013-01-24 10:21:23 +00:00
Jonathan Nieder
52de6fa2c7 Git::SVN: rename private path field
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>
2012-10-05 22:48:12 +00:00
Steven Walter
14d3ce1120 git-svn.perl: keep processing all commits in parents_exclude
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>
2012-10-05 22:48:12 +00:00
Steven Walter
f271fad266 git-svn.perl: consider all ranges for a given merge, instead of only tip-by-tip
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>
2012-10-05 22:48:12 +00:00
Junio C Hamano
9d305e5e70 Merge branch 'ms/git-svn-1.7'
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
2012-08-22 11:51:20 -07:00
Peter Baumann
61b472ed8b git svn: reset invalidates the memoized mergeinfo caches
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 68f532f4ba 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>
2012-08-10 19:53:18 +00:00
Michael G. Schwern
5eaa1fd086 git-svn: remove ad-hoc canonicalizations
[ew: commit title]

Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02 21:46:06 +00:00
Michael G. Schwern
705b49cb81 git-svn: canonicalize newly-minted URLs
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>
2012-08-02 21:46:05 +00:00
Michael G. Schwern
d2fd119c4f git-svn: introduce add_path_to_url function
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>
2012-08-02 21:46:03 +00:00
Michael G. Schwern
9c27a57b2d git-svn: replace URL escapes with canonicalization
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>
2012-08-02 21:46:01 +00:00
Michael G. Schwern
93c3fcbe4d git-svn: attempt to mimic SVN 1.7 URL canonicalization
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>
2012-08-02 21:46:00 +00:00
Michael G. Schwern
565e56c2cc Git::SVN{,::Ra}: canonicalize earlier
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>
2012-08-02 21:45:56 +00:00
Michael G. Schwern
ca475a61f8 git-svn: add join_paths() to safely concatenate paths
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>
2012-08-02 21:44:04 +00:00
Michael G. Schwern
b1ea6c3829 use Git::SVN{,::RA}->url accessor globally
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>
2012-08-02 21:42:59 +00:00
Michael G. Schwern
6a8d999ed4 use Git::SVN->path accessor globally
No functional change.

[ew: commit title]

Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-08-02 21:42:58 +00:00
Michael G. Schwern
06ee19e8e5 Git::SVN: use accessor for URLs internally
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>
2012-08-02 21:42:47 +00:00
Michael G. Schwern
5578ed744d Git::SVN: use accessors internally for path
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>
2012-08-02 21:42:45 +00:00
Michael G. Schwern
3d9be15fc2 Extract Git::SVN::GlobSpec from git-svn.
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>
2012-07-27 22:36:19 +00:00
Michael G. Schwern
5c71028fce Move initialization of Git::SVN variables into Git::SVN.
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>
2012-07-27 22:14:54 +00:00
Michael G. Schwern
29499c0b27 Extract Git::SVN from git-svn into its own .pm file.
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>
2012-07-27 22:14:53 +00:00