Darcs support patch available

[palfrey@…]

Requesting Darcs support

[mark@…]

A patch has been published that adds darcs support:

http://lists.edgewall.com/archive/trac/2005-January/001467.html

[andrew@…]

Is there any chance of this patch being incorporated into Trac's mainline? Trac appears fantastic but the fact we use darcs instead of subversion has been holding up our deciding to use Trac. Cheers, AfC

[root@…]

after some... not wonderful experiences with svn, I would be quite interested in darcs support in svn - seems integrating the patch would be a very cool way to test multi-system support...

[zooko@…]

Hello, I'm just stopping by to say that trac sounds like a very nice tool, but I'm waiting until it is integrated with darcs.

Regards,

Zooko

[anonymous]

Me too.

[anonymous]

I'm ringing in on this too. Darcs is great!

[petru@…]

Just in case you're still wondering if people really want this:

Me Too :)

[mgood]

Please don't flood the ticket with "me too" comments. We know that people are interested in this, but for now there are other things that need to take priority. If you have some constructive feedback that would be helpful in implement this, or are interested in contributing a patch, please go ahead.

[gour@…]

Please don't flood the ticket with "me too" comments. We know that people are interested in this, but for now there are other things that need to take priority. If you have some constructive feedback that would be helpful in implement this, or are interested in contributing a patch, please go ahead.

That's fine. I'm just interested what is the status of above mentioned patch and/or whether Trac's architecture will/can change to serve different back-ends, i.e. there are other users wanting to have support for their favorite tool, and, atm, it looks that Trac is strongly tied to Subversion?

If it is too complicated to change Trac to be rcs-agnostic, then we're going to look for another tool :-(

Sincerely,
Gour

[melo-trac-tickets@…]

I've documented the setup that I'm using to integrate darcs and Trac.

You can find it here: http://www.simplicidade.org/notes/archives/2005/08/trac_darcs_im_i.html

It uses the tailor.py script to import darcs change sets into svn, so no patch required on the Trac side.

It's good enough for me, at least until Trac gets native darcs support in the 2.0 milestone.

[gour@…]

Hi!

Thanks a lot for your howto :-))

It's good enough for me, at least until Trac gets native darcs support in the 2.0 milestone.

I hope it will be for me too :-)

Where did you see that 2.0 may get it?

Sincerely, Gour

[melo-trac-tickets@…]

Use the Trac Roadmap and check 2.0. Also check VersioningSystemBackend.

It mentions support for other SCMs, so I'm assuming that when people start hacking on that feature, darcs should be supported, given that we already have a proof-of-concept patch.

[lele@…]

I'm working on a backend for darcs based on current trunk (0.9.x). You may browse my current effort at http://artiemestieri.tn.it/~lele/projects/trac+darcs, a darcs repository on its own.

[lele@…]

The backend seems usable now, see http://artiemestieri.tn.it/tailor/wiki/DarcsBackend for implementation details. That page also contains the simple patch against current /trunk that generalizes the repository access point, and thus is needed to add almost any other backend.

[gour@…]

The backend seems usable now, see http://artiemestieri.tn.it/tailor/wiki/DarcsBackend for implementation details. That page also contains the simple patch against current /trunk that generalizes the repository access point, and thus is needed to add almost any other backend.

This is wonderful!

What about integration of your backend into the main Trac trunk?

Sincerely,
Gour

[eblot]

I think it would be better not to add many backends to the main Trac trunk.

Trac is light, and if we start adding too many extensions to the main trunk, it will become too large (which means harder to maintain, extra dependencies most users don't need, and so forth).

Trac has a nice pluggable framework, to add this kind of extensions. I don't think most users need Darcs, so it'd better come as an extension rather than a mandatory module.

[Lele]

Good for that, but please, consider accepting at least the "generalization patch", nothing that will make Trac heavier, but allows an easy integration of other backends.

OTOH, I do not see how having more than one backend could make Trac more difficult to maintain: if well done, and current Darcs backend is from this POV, they don't need to be loaded except when the user select them.

Anyway, I'll keep my branch up-to-date.

[gour@…]

I think it would be better not to add many backends to the main Trac trunk. Trac is light, and if we start adding too many extensions to the main trunk, it will become too large (which means harder to maintain, extra dependencies most users don't need, and so forth).

Well, why not taking it as follows: let's make Trac independent of Subversion and let users choose the one they prefer.

Trac has a nice pluggable framework, to add this kind of extensions. I don't think most users need Darcs, so it'd better come as an extension rather than a mandatory module.

I disagree.

I installed Subversion on my Gentoo box just to be able to try & use Trac and all my other repositories are under darcs and by using tailor I pull from CVS repos.

So, by making Trac free of Subversion one could have e.g. Gentoo ebuild which will require either Subversion or Darcs (or some other VCS) based on the choice of use-flags, i.e. preferred VCS.

otoh, implementation of darcs back-end looks, imho, very clean and provides a nice framework for other back-ends.

Just see VersioningSystemBackend - it speaks for itself.

Why are there requests for so many back-ends?

Probably, it's not that "..most users do not need them.." :-)

Moreover, there is also #156 ;)

Sincerely,
Gour

[eblot]

Not adding Darcs to the main trunk does not mean keeping Subversion into the trunk. These are two distinct issues, and as you wrote: #156 deals with the latter one.

I'm no advocate to keep Subversion support in the main trunk.

I'd just like to keep various product extensions out of the trunk.
I'd prefer not to get support for Darcs, Monotone, CVS, PVCS, Clearcase, whatever, ... whenever I download and install Trac.

[cboos]

I'd prefer not to get support for ... whatever, ... whenever I download and install Trac.

That's not necessarily related to the fact that those different backends are part of the trunk or not: it is a mostly a packaging issue, and things could be made modular at that level, if this is needed at all.

Afterall we are just talking about python files, presumably one for each backend, each taking care of not introducing a hard dependency on any other package.

I'd just like to keep various product extensions out of the trunk.

Extensions are one thing, backends are another.

An extension must do with what is possible to do, given the specified set of interfaces defined in the core.

A backend, on the other hand, be it a DatabaseBackend or a VersioningSystemBackend, generally needs to be more intimately related to the core. Moreover, designing and improving a backend often requires to adapt the generic API, as it's rare to get the generic API right without having several backends to abstract upon

For example, see the recent contribution on the Monotone ticket, by Monotone's author #1492#change_4.

Another example would be adding Oracle support (#1874): that wouldn't be possible without also modifying the way the other backends build their queries. By the way, this already happened with Postgres support (multiple statements had to be split in multiple queries).

I think having the different backends in the trunk is better for maintenance reasons:

• when the usage pattern changes, each backend can be fixed according to the change
• if a backend requires the generic API to be modified, one can easily do so ; at the same time, the other backends can be fixed if needed.
• last but not least, the project gains a new committer in the person of the backend maintainer

[cboos]

See TracDarcs.