Re: Compatibility between git.git and jgit
- From
- Ealdwulf Wuffinga <ealdwulf@googlemail.com>
- Date
- May 2, 2009, 16:56 UTC
- Message-ID
- <efe2b6d70905020956p3c99a5fbib85ba00ba842a08e@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.2.00.0905012032590.6741@xanadu.home>
On Sat, May 2, 2009 at 2:39 AM, Nicolas Pitre <nico@cam.org> wrote:
Show 6 quoted lines
> > A formal compatibility test suite would imply that every Git > reimplementation should be compatible with the reference C version. > You could add some tests in your test suite which are performed in > parallel using JGit and the C git, and make sure that the produced > results are identical, etc.
If at all possible, it would be a good idea to make it trivial for new tests in the usual git testsuite to be compatability tests (in a special mode, since it would probably slow them down drastically). Ie, we have special separate copy of all the git.git executables, which underneath run two different versions of git and check that they did the same thing. Or alternatively wait for the librarification of git.git to complete, and do it at the level of that API.
This may be hideously slow unless you have some kind of snapshotting filesystem underneath. (Ironically the one that springs to mind is built into vesta, another scm: http://www.vestasys.org. Vesta's filesystem-manipulation language would be ideal for this. Maybe you could copy it; it's LGPL).
It's less obvious how networking related tests could be automatically made into compatability tests.
Doing this would be a lot trickier than writing some new conformance tests, but once it was working, it would be a lot easier to keep track of new features. It may be too tricky to get to work, but it strikes me as worth thinking about.
Ealdwulf