[Patch] Mercurial support

[Vlad Skvortsov]

Mildred wrote:

[skipped]

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

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.

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

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

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

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