CVS support

See #T2643.

Replying to athomas:

See #T2643.

Yep, I saw this. But this ticket is resolved as 'wontfix' and it's not good. I could reopened that one or create new. I decided to create new. I hope you are not goin to resolve this ticket as 'wontfix'

for what it's worth +1

Probably no one is going to touch this .. but still, a big Vote for this .. Please .. please ... (Gift for 2007 from Trac ? ;-)

Please, oh please, make Trac work with CVS!

Yes. Please. To have both (svn and cvs from inside one trac...) or also multiple svn...

Indeed CVS support would be very important. Actually I was surprised to see that trac only supported SVN as many projects use CVS.

Just to get the ball rolling.

+1 ;-)

Replying to athomas:

See #T2643.

I also would like the ball to get rolling :-)

+1

well, cvs would be really cool to cover many projects that use cvs and don't want to migrate big parts of there scm infrastructure just to be able to use trac.

for instance, at my company, we'd like to use trac, but now recognized that there's no cvs support, so it's not an option any more, which i think is a pitty 'cause trac can do many things viewcvs and fisheye etc can't.

++

Another voter for "CVS support" - Trac & CVS would be just great. Anybody heard of a .NET port of TRAC ?

yes, agree

And another vote from here. Particularly great would be support for CVSNT-specific CVS-enhancements too, e.g. bugids. CVSNT also has a plugin system that could be used for capturing repository events (among other things).

+1 for CVS support. Thanks!

+1 vote

need cvs support too. thanks!

Rather than just gleefully shouting 'yes please, me too', which I'm inclined to do, I thought I'd ask a few questions first.

1. Why is cvs not supported?
2. What are the technical hurdles involved in hacking a CVS backend?
3. Does anyone have a workaround, like somehow mirroring a CVS repository to SVN?

Creative answers on a postcard please...

1. good question, I guess most people have just svn running. And cvs is file based versioning, whereas svn does grouping. So a version number related to a complete set of files.

2. guess the file handling against the version.

(but there are also other versioning systems hacked into trac... so why not cvs -> I don't know)

3. Yes, sure you CAN go from svn to cvs...

BUT: there are a few tools around the globe that are only working with cvs repositories...

4. Also a thing that would be nice is to have multiple repositories. svn, cvs,... or even multiple svn

Perhaps CVSps can help with question 2.

The reason for 3 was that I will find it very hard to persuade the boss to make a switch away from CVS any time soon, yet I really want Trac for our source. If I could automatically mirror commits to our CVS repository into a SVN or other vc repository (even at hourly/daily intervals), then I could use Trac on top of that. Then I could demo Trac with all of its beguiling features as a wedge to finally switch us over to a modern vcs and integrated ticketing system (we still use JitterBug?!).

4 would be good too, I agree. There must be a ticket in here for that somewhere though.

Replying to daveappendix:

2. What are the technical hurdles involved in hacking a CVS backend?

The biggest issue is that CVS has no concept of a changeset like every other system. This makes it hard to present in a unified manner. Sure, you can try to use timestamps to reconstruct the what commits happened together, but then this is getting much more complicated than a simple binding.

The biggest issue is that CVS has no concept of a changeset like every other system.

CVSNT has atomic commits and a custom RCS field called commitid that is returned by cvs log and can also be used in lieu of revision numbers or tags for repo queries. And this is only in addition to the more meaningful bugids.