[Patch] Mercurial support

[Vlad Skvortsov]

Hi Mildred,

it's pleasure to know that you found our project useful! See my comments 
below.

Mildred wrote:
> Hi,
>
> I just discovered your project, and I find it very interesting. It's
> exactly what I need, that is a way to manage bugs and issues simply,
> locally.
>
> But because i don't want to set up a complicated subversion repository
> (if I like this project it's because I don't have to create an issue
> tracker server, it's not to create a subversion server) I quickly
> hacked support for mercurial, which is decentralized, and quick to set
> up.
>   

I understand that if you have the rest of your code in Hg repository, 
creating a separate SVN repo for issues makes no sense, but as a 
comment, I want to note that you don't necessarily need a "server". SVN 
can as well create local repositories accessible through file:// schema.

>  
> The patch for the version 0.7 is available here:
> http://aur.archlinux.org/packages/ditrack/ditrack/hg.patch
>   

I recognize the work you've done -- that's really impressive! though 
there are a few issues preventing us to adopt the patch (at least right 
away).

First, none of us core developers is familiar (even marginally) with Hg. 
We want to make releases as stable as it's reasonably possible, so we 
just can't accept a patch if none of us if comfortable with the changes. 
This leads to another issue: we heavily use unit testing to ensure no 
regression is introduced; and our test suite is tailored to the use of 
SVN. Ideally we want to test DITrack code against all available 
backends, but the current machinery is not suitable for this task; it 
needs to be improved. Another issue is that currently we are "almost" 
hitting the 0.8 alpha stage, so the code got changed since 0.7 quite a bit.

Though probably the main issue is related to the design of the system. 
Although DITrack is "distributed", it relies on the central server to 
serialize modifications to the database. Basically, if a change being 
committed to the server creates a conflict, it will be rejected by the 
server (and should be reapplied by the client -- which is not 
implemented in the current version yet).

However, we *do* want to support Hg (and other backends) in the future 
so certainly your help is appreciated. For now I suggest that you 
maintain the patch on your own (and I've opened i#200 so it won't get 
forgotten) and we will gradually modify our code so that Mercurial 
support fits more organically. If you could help us with your expertise 
in Hg, it'd speed things up; though I don't want to set any time 
expectations as currently the development pace is very slow (due to lack 
of our time).

> It seems to work, but I only tested few commands (remember I just
> discovered the project few hours ago, I don't have issues yet). If you
> want to test, you can just do:
>
> $ hg init
> $ dt-createdb --hg issues
> $ cd issues
> edit the files in etc/ as you want
> $ hg ci -m "added issue tracker"
> work on issues :)
>   

Ok, once you have enough confidence, let us know and we can link to your 
patch from ditrack.org.

>
> When the issue database is created, it add a file '.filesystem' that
> contains either 'svn' or 'hg'. That way the filesystem is
> automatically detected.
>
> You can also set the environment variable DITRACK_FILESYSTEM or specify
> the --fs command line option.
>
> Something still missing: because mercurial don't have properties like
> subversion, I couldn't implement ditrack:format subversion property
> that check the database format. Perhaps this could be moved to a file.
>   

Yeah, that has been fixed for 0.8 specifically to be backend-agnostic.

> And remember, this is completely untested. But perhaps in the days to
> come I'll use it and fix bugs that could be there.
>   

Thanks!

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com