Added --ignore-nodate to allow 'git svn fetch' to import revisions
from Subversion which have '(no date)' listed as the date of the
revision.  By default 'git svn fetch' will crash with an error
when encountering such a revision.  The user may restart the fetch
operation by adding --ignore-nodate if they want to continue tracking
that repository.

I'm not entirely sure why a centralized version control system such
as Subversion permits revisions to be created with absolutely no
date/time associated with it but it apparently is possible as one
of the Subversion repositories that I'm tracking with 'git svn'
created such a revision on '(no date)' and by '(no user)'.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Excessive use of global variables got me into trouble.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is a high-level wrapper around the 'commit-diff' command
and used to produce cleaner history against the mirrored repository
through rebase/reset usage.

It's basically a more polished version of this:

for i in `git rev-list --no-merges remotes/git-svn..HEAD | tac`; do
	git-svn commit-diff $i~1 $i
done
git reset --hard remotes/git-svn
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

SVN seems to have a problem with https:// repositories from
time-to-time when doing multiple, sequential commits.  This
problem is not consistently reproducible without the patch,
but it should go away entirely with this patch...
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This version of the splitter (that only affects SVN:: library
users) works when one only has limited read-permissions to
the repository they're fetching from.

Updated from the original patch to workaround some SVN bug
somewhere, which only seems to happen against file://
repositories...  Here's the diff against the original patch I
submitted:

@@ -1159,8 +1159,8 @@ sub repo_path_split {
 	}

 	if ($_use_lib) {
-		$SVN = libsvn_connect($full_url);
-		my $url = $SVN->get_repos_root;
+		my $tmp = libsvn_connect($full_url);
+		my $url = $tmp->get_repos_root;
 		$full_url =~ s#^\Q$url\E/*##;
 		push @repo_path_split_cache, qr/^(\Q$url\E)/;
 		return ($url, $full_url);

Somehow connecting to a repository with the full url makes the
returned SVN::Ra object act strangely and break things, so now
we just drop the SVN::Ra object that we made our initial
connection with.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I'm not sure if anybody has hit this (besides me), but this
fixes the problem where I ran into while attempting to import a
small repo at the root level:  I ended up with all the commits, but
with no file/tree changes at all throughout the entire history.

Also, fix a warning if the commit message is not defined for revision 0.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This bugfix applies to users of the svn command-line client only.

We no longer muck with newlines when killing keyword expansion.
This tended to generate unintended diffs in commits because svn
revert -R would destroy the manual EOL changes we were doing. Of
course, we didn't need the EOL munging in the first place, as
svn seems to do it for us even in the text-base files.

Now we set the mtime and atime the files changed by keyword
expansion killing to avoid triggering a change on svn revert,
which svn still seems to want to do.

Thanks to Seth Falcon for reporting this bug.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Log output from SVN doesn't list all the new files that were
added if a new directory was copied from an existing place in
the repository.  This means we'll have to do some extra work and
traverse new directories ourselves.

This has been updated from the original patch to defer traversed
adds until all removals have been done.  Please disregard the
original.

Thanks to Ben Williamson for the excellent bug report and
testing.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Unlike other git-svn commands, commit-diff is intended to
operate without needing any additional metadata inside .git
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The only visible change is that git-blame doesn't understand
"--compability" anymore, but it does accept "--compatibility" instead,
which is already documented.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Also, allow messages from tags to be used as
commit messages.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Allow NO_SVN_TESTS to be defined to skip git-svn tests.  These
tests are time-consuming due to SVN being slow, and even more so
if SVN Perl libraries are not available.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Thanks to Santi <sbejar@gmail.com> for the bug report and explanation:
> /path/to/repository/project/file
> /path/to/repository/project-2/file
<...>
> you end up with a project with the following files:
>
> file
> -2/file
Signed-off-by: NEric Wong <normalperson@yhbt.net>

	git-svn init url://to/the/repo local-repo

will create the local-repo dirrectory if doesn't exist yet and
populate it as expected.

Original patch by Luca Barbato, cleaned up and made to work for
the current version of git-svn by me (Eric Wong).
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Slower connections can make git-svn look as if it's doing
nothing for a long time; leaving the user wondering if we're
actually doing anything.  Now we print some file progress just
to assure the user that something is going on while they're
waiting.

Added the -q/--quiet option to users to revert to the old method
if they preferred it.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

--follow-parent:
  This is especially helpful when we're tracking a directory
  that has been moved around within the repository, or if we
  started tracking a branch and never tracked the trunk it was
  descended from.

  This relies on the SVN::* libraries to work.  We can't
  reliably parse path info from the svn command-line client
  without relying on XML, so it's better just to have the SVN::*
  libs installed.

  This also removes oldvalue verification when calling update-ref

  In SVN, branches can be deleted, and then recreated under the
  same path as the original one with different ancestry
  information, causing parent information to be mismatched /
  misordered.

  Also force the current ref, if existing, to be a parent,
  regardless of whether or not it was specified.

--no-metadata:
  This gets rid of the git-svn-id: lines at the end of every commit.

  With this, you lose the ability to use the rebuild command.  If
  you ever lose your .git/svn/git-svn/.rev_db file, you won't be
  able to fetch again, either.  This is fine for one-shot imports.

  Also fix some issues with multi-fetch --follow-parent that were
  exposed while testing this.  Additionally, repack checking is
  simplified greatly.

  git-svn log will not work on repositories using this, either.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is intended for interoperability with git-svnimport.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The 'graft-branches' command can now analyze tree matches for
merge detection after commits are done, when --branch or
--branch-all-refs options are used.

We ensure that tree joins (--branch and --branch-all-refs
options) during commit time only add SVN parents that occurred
before the commit we're importing

Also fixed branch detection via merge messages, this manner of
merge detection (a la git-svnimport) is really all fuzzy, but at
least it actually works now :)

Add some new tests to go along with these fixes, too.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Tested on a plain Ubuntu Hoary installation
using subversion 1.1.1-2ubuntu3

1.1.x issues I had to deal with:

* Avoid the noisy command-line client compatibility check if we
  use the libraries.

* get_log() arguments differ (now using a nice wrapper from
  Junio's suggestion)

* get_file() is picky about what kind of file handles it gets,
  so I ended up redirecting STDOUT.  I'm probably overflushing
  my file handles, but that's the safest thing to do...

* BDB kept segfaulting on me during tests, so svnadmin will use FSFS
  whenever we can.

* If somebody used an expanded CVS $Id$ line inside a file, then
  propsetting it to use svn:keywords will cause the original CVS
  $Id$ to be retained when asked for the original file.  As far as
  I can see, this is a server-side issue.  We won't care in the
  test anymore, as long as it's not expanded by SVN, a static
  CVS $Id$ line is fine.

While we're at making ourselves more compatible, avoid grep
along with the -q flag, which is GNU-specific. (grep avoidance
tip from Junio, too)
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Trying to open an interactive editor in the console while stdout is
being piped to the parent process doesn't work out very well.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When tracking directories with nearly all of its files at
the most nested levels, --rmdir would accidentally go too
far when deleting.

Of course, we'll add a test for this condition, too.

Makefile: automatically run new tests as they appear in t/
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We will now automatically fetch the refs/remotes/git-svn ref
from origin and store a Pull: line for it.

--remote=<origin> may be passed if your remote is named something
other than 'origin'

Also, remember to make GIT_SVN_DIR whenever we need to create
.rev_db
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Tested on a plain Ubuntu Warty installation
using subversion 1.0.6-1.2ubuntu3

svn add --force was never needed, as it only affected
directories, which git (thankfully) doesn't track

The 1.0.x also didn't support symlinks(!), so allow NO_SYMLINK
to be defined for running tests
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Revisions with long commit messages were being skipped, since
the 'git-svn-id' metadata line was at the end and git-log uses a
32k buffer to print the commits.

Also the last 'git-svn-id' metadata line in a commit is always
the valid one, so make sure we use that, as well.

Made the verbose flag work by passing the correct option switch
('--summary') to git-log.

Finally, optimize -r/--revision argument handling by passing
the appropriate limits to revision
Signed-off-by: NEric Wong <normalperson@yhbt.net>

This means we'll have a loose object when we encounter a symlink
but that's not the common case.

We also don't have to worry about svn:eol-style when using the
SVN libraries, either.  So remove the code to deal with that.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Share the repack counter between branches when doing
multi-fetch.

Pass the -d flag to git repack by default.  That's the
main reason we will want automatic pack generation, to
save space and improve disk cache performance.  I won't
add -a by default since it can generate extremely large
packs that make RAM-starved systems unhappy.

We no longer generate the .git/svn/$GIT_SVN_ID/info/uuid
file, either.  It was never read in the first place.

Check for and create .rev_db if we need to during fetch (in case
somebody manually blew away their .rev_db and wanted to start
over.  Mainly makes debugging easier).

Croak with $? instead of $! if there's an error closing pipes

Quiet down some of the chatter, too.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

repo_path_split() is already pretty fast, and is already
optimized via caching.

We also don't need to create an exclude file if we're
relying on the SVN libraries.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

This is a very intrusive change, so I've beefed up the tests
significantly.  Added 'full-test' a target to the Makefile,
to test different possible configurations.  This is intended
for maintainers only.  Users should only be concerned with
'test' succeeding.

We now have a very simple custom database format for handling
mapping of svn revisions => git commits.  Of course, we're
not really using it yet, either.

Also disabled automatic branch-finding on new trees for now.
It's too easily broken.  revisions_eq() function should be
helpful for branch detection.

Also removed an extra assertion in fetch_cmd() that wasn't
correctly done.  This bug was found by full-test.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

This means we no longer have to deal with having bloated SVN
working copies around and we get a nice performance increase as
well because we don't have to exec the SVN binary and start a
new server connection each time.

Of course we have to manually manage memory with SVN::Pool
whenever we can, and hack around cases where SVN just eats
memory despite pools (I blame Perl, too).  I would like to
keep memory usage as stable as possible during long fetch/commit
processes since I still use computers with only 256-512M RAM.

commit should always be faster with the SVN library code.  The
SVN::Delta interface is leaky (or I'm not using it with pools
correctly), so I'm forking on every commit, but that doesn't
seem to hurt performance too much (at least on normal Unix/Linux
systems where fork() is pretty cheap).

fetch should be faster in most common cases, but probably not all.
fetches will be faster where client/server delta generation is
the bottleneck and not bandwidth.  Of course, full-files are
generated server-side via deltas, too.  Full files are always
transferred when they're updated, just like git-svnimport and
unlike command-line svn.  I'm also hacking around memory leaks
(see comments) here by using some more forks.

I've tested fetch with http://, https://, file://, and svn://
repositories, so we should be reasonably covered in terms of
error handling for fetching.

Of course, we'll keep plain command-line svn compatibility as a
fallback for people running SVN 1.1 (I'm looking into library
support for 1.1.x SVN, too).  If you want to force command-line
SVN usage, set GIT_SVN_NO_LIB=1 in your environment.

We also require two simultaneous connections (just like
git-svnimport), but this shouldn't be a problem for most
servers.

Less important commands:

show-ignore is slower because it requires repository
access, but -r/--revision <num> can be specified.

graft-branches may use more memory, but it's a
short-term process and is funky-filename-safe.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

This quick feature should make it easy to look up svn log
messages when svn users refer to -r/--revision numbers.

The following features from `svn log' are supported:

  --revision=<n>[:<n>] - is supported, non-numeric args are not:
			 HEAD, NEXT, BASE, PREV, etc ...
  -v/--verbose         - just maps to --raw (in git log), so
			 it's completely incompatible with
			 the --verbose output in svn log
  --limit=<n>          - is NOT the same as --max-count,
			 doesn't count merged/excluded commits
  --incremental        - supported (trivial :P)

New features:

  --show-commit        - shows the git commit sha1, as well
  --oneline            - our version of --pretty=oneline

Any other arguments are passed directly to `git log'
Signed-off-by: NEric Wong <normalperson@yhbt.net>

New commands:

graft-branches - The most interesting command of the bunch.  It
detects branches in SVN via various techniques (currently
regexes and file copies).   It can be later extended to handle
svk and other properties people may use to track merges in svk.
Basically, merge tracking is not standardized at all in the SVN
world, and git grafts are perfect for dealing with this
situation.

Existing branch support (via tree matches) is only handled at
fetch time.

The following tow were originally implemented as shell scripts
several months ago, but I just decided to streamline things a
bit and added them to the main script.

multi-init - supports git-svnimport-like command-line syntax for
importing repositories that are layed out as recommended by the
SVN folks.  This is a bit more tolerant than the git-svnimport
command-line syntax and doesn't require the user to figure out
where the repository URL ends and where the repository path
begins.

multi-fetch - runs fetch on all known SVN branches we're
tracking.  This will NOT discover new branches (unlike
git-svnimport), so multi-init will need to be re-run (it's
idempotent).

Consider these three to be auxilliary commands (like
show-ignore, and rebuild) so their behavior won't receive as
much testing or scrutiny as the core commands (fetch and
commit).
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Signed-off-by: NEric Wong <normalperson@yhbt.net>

This should help keep disk usage sane for large imports.

--repack takes an optional argument for the interval, it
defaults to 1000 if no argument is specified.

Arguments to --repack-flags are passed directly to git-repack.
No arguments are passed by default.

Idea stolen from git-cvsimport :)
Signed-off-by: NEric Wong <normalperson@yhbt.net>

While we're at it, read_repo_config has been added and
expanded to handle case where command-line arguments are
optional to Getopt::Long
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Since GIT_SVN_ID usage is probably going to become more
widespread <evil grin>, we won't run the chance of somebody
having a GIT_SVN_ID name that conflicts with one of the default
directories that already exist in $GIT_DIR (branches/tags).
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Sometimes I don't feel like downloading an entire tree again when
I actually decide a branch is worth tracking, so some users can
get around it more easily with this.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

By breaking the pipe read once we've seen a commit twice.

This should make -B/--branch-all-ref faster and usable on a
frequent basis.

We use topological order now for calling git-rev-list, and any
commit we've seen before should imply that all parents have been
seen (at least I hope that's the case for --topo-order).
Signed-off-by: NEric Wong <normalperson@yhbt.net>

This should make life easier for all those who type:

	`git-rev-parse --symbolic --all | xargs -n1 echo -b`

every time they run git-svn fetch.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

The repo-config key is 'svn.copysimilarity'
Signed-off-by: NEric Wong <normalperson@yhbt.net>

If new revisions are fetched, that implies we haven't merged,
acked, or nacked them yet, and attempting to write the tree
we're committing means we'd silently clobber the newly fetched
changes.
Signed-off-by: NEric Wong <normalperson@yhbt.net>