[Patch] Mercurial support

[Mildred]

Hi,

Thanks for your answer, I'm glad to see my patch is appreciated.

> 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.

Well, for the moment I don't have much code versionned with Mercurial.
The project I contribute the most are all using Subversion. But for
local mini projects, I now use Mercurial, in order to avoid setting up
a repository or having m code in two places at once (my working cop and
my repository). For local projects I think it's more relevant to have
everything at the same place.


> 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.

I agree that for now, it's too early for you to accept my patch (and I
wasn't expecting so). I think mercurial isn't that different from
subversion and other version managing systems. If you want to see how
it works, just install mercurial and you can try the following commands
in a dedicated directory:

	$ hg help CMD	help about CMD
	$ hg init	initialize the repository
	$ hg add FILE	add FILE to the working copy
	$ hg rm FILE	remove FILE
	$ hg commit	commit to the repository (locally)

	(you don't have to try it now, just to show how how similar it
	is to Subversion)

And I don't think you need to know more about it. As you can see for
usual operations, it's pretty similar to subversion. Perhaps the thing
you have to know is that Mercurial doesn't track directories. A
directory exists in the repository only because it contains versionned
files. So it doesn't makes much sense to add directories
non-recursively.

About the soon to be available 0.8 version, I know about that when I
created the patch, but I don't think this is going to be a problem
since my changes are not so intrusive. The patch can be easily ported I
think.

> 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).

Even if Mercurial can be used with a centralized server, I think this
may be a problem. The question is to know what to do when there is a
merge conflict. But I think this can be solved, because first I think
that Mercurial can use external programs to solve merge conflicts (it
would be dt merge or something like that).
It would involve renumbering issues and comment that conflict most
probably.

But for the moment, it's not really a problem for me since I just
wanted a local bug tracker (and I have no need yet to share it)


> 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).

Don't speed up too much :) Actually, I don't have much time either. So
I wouldn't be able to work on DITrack more than an hour or two for the
months to come ... For now, I think a patch is still the best solution.



Last think (completely unrelated). Have you been thinking about a GUI ?
I think it won't be much work and in some cases it could be better than
the command line.




Thanks

Mildred


-- 
Mildred Ki'lya
E-Mail:	mildred593(at)online.fr

Site:	<http://mildred632.free.fr/>
XMPP:	<mildred at jabber.fr> (GoogleTalk, Jabber)

GPG:	197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]