Commit Graph

10 Commits

Author SHA1 Message Date
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
10c2aa5928 Move Git::IndexInfo into its own file.
Straight cut & paste.  Didn't require any fixing.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-27 22:36:17 +00:00
Michael G. Schwern
b772cb9994 Extract Git::SVN::Migration from git-svn.
Straight cut & paste.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
2012-07-27 22:36:14 +00:00
Michael G. Schwern
b74fda1c9b Extract Git::SVN::Log from git-svn.
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>
2012-07-27 22:36:06 +00:00
Michael G. Schwern
c2768fa152 Extract some utilities from git-svn to allow extracting Git::SVN.
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>
2012-07-27 22:14:50 +00:00
Jonathan Nieder
68f532f4ba git-svn: use YAML format for mergeinfo cache when possible
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>
2012-06-10 08:47:53 +00:00
Jonathan Nieder
9f7ad1479d git-svn: make Git::SVN::RA a separate file
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 c26ddce86d
 (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>
2012-06-10 08:47:50 +00:00
Jonathan Nieder
8f9facfe94 git-svn: make Git::SVN::Editor a separate file
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>
2012-06-10 08:45:56 +00:00
Jonathan Nieder
a6180325e8 git-svn: make Git::SVN::Fetcher a separate file
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>
2012-05-29 00:17:59 +00:00
Jonathan Nieder
c102f4cf72 git-svn: move Git::SVN::Prompt into its own file
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>
2012-05-29 00:17:59 +00:00