[Patch] Mercurial support

[Mildred]

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.

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

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


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.

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


:)


Mildred

[Vlad Skvortsov]

Hi Mildred,

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

Post by Mildred
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.

Post by Mildred
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).

Post by Mildred
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
$ 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.

Post by Mildred
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.

Post by Mildred
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!

[Mildred]

Hi,

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

Post by Vlad Skvortsov
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.

Post by Vlad Skvortsov
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.

Post by Vlad Skvortsov
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)

Post by Vlad Skvortsov
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

[Luke Kenneth Casson Leighton]

if the same concept for "local comments" is applied - "local"
numbering - to "issues", then there can never be a conflict - ever.
reason: only when an issue is committed to the central repository will
it be given a real "global" number.
l.

[Vlad Skvortsov]

Post by Luke Kenneth Casson Leighton
if the same concept for "local comments" is applied - "local"
numbering - to "issues", then there can never be a conflict - ever.
reason: only when an issue is committed to the central repository will
it be given a real "global" number.

The concept *is* there, but we rely on Subversion in conflict
*detection*. I'm not sure if it's feasible with other [distributed]
version control systems. I'm not saying it's infeasible, I just don't know.

[Vlad Skvortsov]

Mildred wrote:

[skipped]

Post by Mildred
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
$ 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.

Yeah, that *looks* similar to Subversion, but my point is that we
ourselves can't drive the effort to adopt Hg as a backend. We do work
with Subversion on daily basis, so we can [probably] think of all
possible minor details and corner cases of using it as a backend; this
is obviously not true with respect to any other version control system.
I guess the best we can do is to make DITrack as backend-agnostic as
realistically possible and let people think through the details of
interfacing with other systems. In case if such an effort leads to
reasonably stable working code, we'll consider adopting it to the code base.

Post by Mildred

Post by Vlad Skvortsov
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.

Provided that the DITrack issue base is not altered manually (only
through DITrack clients / API), it's relatively easy to handle merge
errors. The tough part is to make sure that we *detect* such a conflict.
With Subversion I can't check in stuff in a directory unless I have the
latest revision of that directory. This is the property of Subversion
that we rely our design on.


[skipped]

Post by Mildred
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.

Alright, if that works for you -- perfect! :-)

Post by Mildred
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.

Yeah, we have; but not about replacing 'dt' with a GUI. Our approach is
to create APIs so that other people could build on top of that. There
have been a few steps in this direction: 'cat' and 'list' commands
support '--xml' option to format output as XML; 'act' supports '-n'
option to perform changes non-interactively. This should make writing
frontends to 'dt' easier.

Also, we keep working on Python API for DITrack; the web interface
client[1][2] makes use of that API. Though the API is still quite raw.

[1]: http://issues.ditrack.org/
[2]: http://svn.xiolabs.com/ditrack/src/trunk/webui/