summaryrefslogtreecommitdiff
path: root/t/t9104-git-svn-follow-parent.sh
AgeCommit message (Collapse)AuthorFilesLines
2007-09-21git-svn: handle changed svn command-line syntaxLibravatar Sam Vilain1-2/+4
Previously, if you passed a revision and a path to svn cp, it meant to look back at that revision and select that path. New behaviour is to get the path then go back to the revision (like other commands that accept @REV or -rREV do). The more consistent syntax is not supported by the old tools, so we have to try both in turn. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-21git-svn: fix test for trunk svn (commit message not needed)Libravatar Sam Vilain1-2/+1
The 'svn mv -m "rename to thunk"' was a local operation, therefore not needing a commit message, it was silently ignored. Newer svn clients will instead raise an error. Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-15/+15
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-13git-svn: don't attempt to minimize URLs by defaultLibravatar Eric Wong1-6/+7
For tracking branches and tags, git-svn prefers to connect to the root of the repository or at least the level that houses branches and tags as well as trunk. However, users that are accustomed to tracking a single directory have no use for this feature. As pointed out by Junio, users may not have permissions to connect to connect to a higher-level path in the repository. While the current minimize_url() function detects lack of permissions to certain paths _after_ successful logins, it cannot effectively determine if it is trying to access a login-only portion of a repo when the user expects to connect to a part where anonymous access is allowed. For people used to the git-svnimport switches of --trunk, --tags, --branches, they'll already pass the repository root (or root+subdirectory), so minimize URL isn't of too much use to them, either. For people *not* used to git-svnimport, git-svn also supports: git svn init --minimize-url \ --trunk http://repository-root/foo/trunk \ --branches http://repository-root/foo/branches \ --tags http://repository-root/foo/tags And this is where the new --minimize-url command-line switch comes in to allow for this behavior to continue working.
2007-02-23t910*: s/repo-config/config/g; poke around possible race conditionsLibravatar Eric Wong1-4/+5
Some of the repo-config => config renaming missed the git-svn tests; so I'm just renaming them to be consisten with the rest of the modern git. Also, some of the newer tests didn't have 'poke' in them to workaround race conditions on fast machines. This adds places where they can _possibly_ occur; but I don't have fast enough hardware to trigger them. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: enable follow-parent functionality by defaultLibravatar Eric Wong1-13/+13
--no-follow-parent disables and reverts it back to the old default behavior of not following parents (if you don't care for full history). Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: --follow-parent tracks multi-parent pathsLibravatar Eric Wong1-0/+7
We can have a branch that was deleted, then re-added under the same name but copied from another path, in which case we'll have multiple parents (we don't want to break the original ref, nor lose copypath info). Add a test for this, too, of course. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: just name the default svn-remote "svn" instead of "git-svn"Libravatar Eric Wong1-5/+5
It can be confusing and redundant, since historically the default remote ref (not remote itself) has been "git-svn", too. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: don't write to the config file from --follow-parentLibravatar Eric Wong1-1/+1
Having 'fetch' entries in the config file created from --follow-parent is wasteful because it can cause *future* of invocations to follow revisions we were never interested in in the first place. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: fix several fetch bugs related to repeated invocationsLibravatar Eric Wong1-3/+13
We no longer delete the top-level directory even if it got deleted from the upstream repository. In gs_do_update; we double-check that the path we're tracking exists at both endpoints before proceeding. We have also added additional protection against fetching revisions out-of-order. To simplify our internal interfaces, I've disabled passing the 'recursive' flag to the gs_do_{switch,update} wrapper functions since we always want it in git-svn. We also pass the entire Git::SVN object rather than just the path because it helped me debug. When printing progress, the refname is printed out to make it less confusing when multi-fetch is running. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: fetch tracks initial change with --follow-parentLibravatar Eric Wong1-1/+13
We were still skipping path information from get_log if we are tracking /r9270/drunk/subversion/bindings/..., but got something like this in the log: A /r9270/drunk (from /r9270/trunk:14) Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: stop using path names as refnames with --follow-parentLibravatar Eric Wong1-2/+4
Using path names as refnames breaks horribly if a user is tracking one large, toplevel directory, and a lower-level directory is followed from another project is a parent of another ref, as it will cause refnames such as: 'refs/remotes/trunk/path/to/stuff', which will conflict with a refname of 'refs/remotes/trunk'. Now we just append @$revno to the end of it the current refname. And if we have followed back to a grandparent, then we'll strip any existing '@$parent_revno' strings before appending our own '@$revno' string to it. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: correctly handle do_{switch,update} in deep directoriesLibravatar Eric Wong1-0/+31
The do_update or do_switch functions in SVN only allow for a single path component; so 'path/to/deep/dir' would be interpreted as 'path'. SVN 1.4.x has a reparent function that can let us change the session to use a higher-level root of the repository, so we can use that for do_switch (which still doesn't seem to work in SVN 1.4.3 (a fix was attempted, but they missed the rest of the typemap changes needed in trunk...)). On the do_update side, we can use set_path on higher level directories and set them to a newer revision so they don't get updated. We can't do this with do_switch, either, because the relative path we're tracking can change (directory moving into a child of itself). Because of these changes, we need to double check that our Fetch editor is correctly performing stripping on any prefixed paths from update, otherwise we'll just die() because that would be a bug. Added a test case which helped me notice and fix problems with do_switch, too. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: fix segfaults from accessing svn_log_changed_path_tLibravatar Eric Wong1-1/+0
svn_log_changed_path_t structs were being used out of scope outside of svn_ra_get_log (because I wanted to eventually be able to use git-svn with only a single connection to the repository). So now we dup them into a hash. This was fixed while making --follow-parent fetches more efficient. I've moved parsing of the command-line --revision argument outside of the Git::SVN module so Git::SVN::fetch() can be used in more places (such as find_parent_branch). Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: correctly track revisions made to deleted branchesLibravatar Eric Wong1-1/+10
git-svn has never been able to handle deleted branches very well because svn_ra_get_log() is all-or-nothing, meaning that if the max revision passed to it does not contain the path we're tracking, we miss all the revisions in the repository. Branches fetched using --follow-parent still do this sub-optimally (will be fixed soon). --follow-parent will soon become the default, so we will assume that when using get_log(); We will also avoid tracking revprops for revisions with no path-related changes since otherwise we just end up pulling logs to paths we don't care about. Also added a test for this to t9104-git-svn-follow-parent.sh and correctly commit the log message in the preceeding test (which conflicted with a filename). Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: add an odd test case that seems to cause segfaults over HTTPLibravatar Eric Wong1-0/+15
Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: --follow-parent now works on sub-directories of larger branchesLibravatar Eric Wong1-0/+17
This means that tracking the path of: /another-larger/trunk/thunk/bump/thud inside a repository would follow: /larger-parent/trunk/thunk/bump/thud even if the svn log output looks like this: -------------------------------------------- Changed paths: A /another-larger (from /larger-parent:5) -------------------------------------------- Note: the usage of get_log() in git-svn still makes a an assumption that shouldn't be made with regard to revisions existing for a particular path. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: allow --follow-parent on deleted directoriesLibravatar Eric Wong1-0/+12
Any operations on the index in Git::SVN that is not wrapped by tmp_index_do() is wrong. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: --follow-parent works with svn-remotes multiple branchesLibravatar Eric Wong1-0/+13
Bugs fixed: * We didn't allow manually (not using git-svn) init-ed remotes/fetch refspecs to be used before. It works now because that's what I did in this test. git-svn init should offer more control in the future. * correctly strip paths in the delta editor when using do_switch(). * Make the -i / GIT_SVN_ID option work correctly when doing fetch on a multi-ref svn-remote Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-23git-svn: fix --follow-parent to work with Git::SVNLibravatar Eric Wong1-2/+4
While we're at it, beef up the test because I was getting false-passes during development. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-02-12Work around Subversion race in git-svn tests.Libravatar Michael Spang1-0/+2
Some of the git-svn tests can fail on fast machines due to a race in Subversion: if a file is modified in the same second it was checked out (or in for that matter), Subversion will not consider it modified. This works around the problem by increasing the timestamp by one second before each commit. [jc: with "touch -r -d" replacement from Eric] Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Michael Spang <mspang@uwaterloo.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13git-svn: fix tests to work with older svnLibravatar Eric Wong1-0/+1
Some of the recent changes and shortcuts to the tests broke things for people using older versions of svn: t9104-git-svn-follow-parent.sh: v1.2.3 (from SuSE 10.0 as reported by riddochc on #git (thanks!)) required an extra 'svn up'. I was also able to reproduce this with v1.1.4 (Debian Sarge). lib-git-svn.sh: SVN::Repos bindings in versions up to and including 1.1.4 (Sarge again) do not pass fs-config options to the underlying library. BerkeleyDB repositories also seem completely broken on all my Sarge machines; so not using FSFS does not seem to be an option for most people. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-31git-svn: t/t91??-*: optimize the tests a bitLibravatar Eric Wong1-1/+0
This removes some unnecessary 'svn up' calls throughout t9103-git-svn-graft-branches.sh: * removed an 'svn log' call that was leftover from debugging * removed multiple git-svn calls with a multi-init / multi-fetch combination (which weren't tested before, either) * replaced `rev-list ... | head -n1` with `rev-parse ...` (not sure what I was thinking when I wrote that) All this saves about 9 seconds from a test run (53s -> 44s for 'make t91*') on my 1.3GHz Athlon Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-svn: remove support for the svn command-line clientLibravatar Eric Wong1-7/+0
Using the command-line client was great for prototyping and getting something working quickly. Eventually I found time to study the library documentation and add support for using the libraries which are much faster and more flexible when it comes to supporting new features. Note that we require version 1.1 of the SVN libraries, whereas we supported the command-line svn client down to version 1.0. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-06git-svn: migrate out of contribLibravatar Eric Wong1-0/+44
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: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>