Edgewall Software
Modify

Opened 14 years ago

Closed 12 years ago

#638 closed enhancement (wontfix)

Darcs support patch available

Reported by: palfrey@… Owned by: Christopher Lenz
Priority: normal Milestone:
Component: version control Version: none
Severity: normal Keywords: darcs
Cc: root@… green@…
Release Notes:
API Changes:

Description

Requesting Darcs support

Attachments (0)

Change History (26)

comment:1 Changed 14 years ago by daniel

Milestone: 2.0Someday

comment:2 Changed 14 years ago by mark@…

Summary: Darcs supportDarcs support patch available

A patch has been published that adds darcs support:

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

comment:3 Changed 14 years ago by 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

comment:4 Changed 14 years ago by root@…

Cc: root@… added
Keywords: tickets checkins commits tracking added

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…

comment:5 Changed 13 years ago by 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

comment:6 Changed 13 years ago by anonymous

Me too.

comment:7 Changed 13 years ago by anonymous

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

comment:8 Changed 13 years ago by petru@…

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

Me Too :)

comment:9 Changed 13 years ago by Matthew Good

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.

comment:10 Changed 13 years ago by 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

comment:11 Changed 13 years ago by 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.

comment:12 Changed 13 years ago by 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

comment:13 Changed 13 years ago by 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.

comment:14 Changed 13 years ago by 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.

comment:15 Changed 13 years ago by 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.

comment:16 Changed 13 years ago by 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

comment:17 Changed 13 years ago by Emmanuel Blot

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.

comment:18 Changed 13 years ago by 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.

comment:19 Changed 13 years ago by 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

comment:20 Changed 13 years ago by Emmanuel Blot

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.

comment:21 Changed 13 years ago by Christian Boos

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

comment:22 Changed 13 years ago by Christopher Lenz

Component: generalversion control
Owner: changed from Jonas Borgström to Christopher Lenz

comment:23 Changed 13 years ago by anonymous

Cc: root@… added; root@… removed

comment:24 Changed 12 years ago by sid

Keywords: darcs added; tickets checkins commits tracking removed

comment:25 Changed 12 years ago by sid

Version: none

comment:26 Changed 12 years ago by Christian Boos

Resolution: wontfix
Status: newclosed

See TracDarcs.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christopher Lenz.
The resolution will be deleted.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.