-
Notifications
You must be signed in to change notification settings - Fork 0
Further Work
The following is a list of the things that I would like to add to the software and what I will work on when I get the chance.
Add a fully automated test suite for validating the software. A framework (using Perl's Test::Harness) has already been setup and given very simple tests. Next it needs to handle actual diffs, comparing the svn diff(1) output to git-svn-diff(1) for verification. Such a test would need to clone a SVN repo from scratch to ensure that changes in git-svn(1) do not affect git-svn-diff(1).
With SVN and git, one can only diff between existing revisions or an existing revision and the working copy (and, of course, with the index). However, git allows commits that are not publicly available and thus, from SVN's point of view, one could have a diff between 2 working copies.
The goal is to handle these situations intelligently rather than always abort, as is currently the case. We could always allow it, but that has it's own set of problems. I propose having several levels from which to choose, noted below:
Default. Abort if any diff is made where the <since> commit is not in the SVN repository. This is the safest path, but less helpful.
Allow a diff to be shown iff it can be applied to the BASE revision as it stands. That is, if HEAD is a commit in git-svn but not SVN and HEAD~2 is equivalent to BASE. We can show the diff for HEAD if and only iff it can be applied to the BASE without first applying HEAD~; otherwise abort.
This can be further refined into 2 cases:
- Files are disjoint:
HEAD~andHEADdo not modify the same files. - Chunks are disjoint:
HEAD~andHEADdo not modify the same sections of the file.
In the second case, we need to decide if we fix the chunk headers (i.e. @@ -l,n +j,m @@) so that they could be applied directly to BASE, or to leave them alone so we can apply to HEAD~.
Always show SVN-style diff, regardless.