Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Brian Smith wrote: > What I would like to do is create a seperate shared library that CVS > client applications (like WinCVS, TortoiseCVS, and the command-line CVS > client) can all use. The benefit is that applications written in other > languages (e.g. Java, C++, and scripting languages) would be easier to > integrate with the client. Also, there would be no need for CVS client > applications to communicate between themselves and cvs.exe with > (sometimes ugly) IPC mechanisms. That used to exist (wincvs 1.2 used it) but it's actually better to use the cvs.exe and pipe to it. cvs has only one entrypoint anyway so a library is overkill. > This would also entail seperating the front-end of the client code from > the back-end. This eperation would also be a good opportunity to support > internationalizing the client. It sounds like you're talking about a total rewrite - this would take at least 12 months and would need a lot more people working on the project... It's not even on the roadmap yet. >> teach cvs what a directory is (medium) >> mergepoint tracking (medium) > > > Could you explain these two? You can't implement a directory rename without having cvs record some kind of directory history. Also it would be nice to be able to add/remove directories properly in the same way files work. Mergepoint tracking is needed because the way branches work in cvs at the moment is a pain - it always merges from the original branchpoint so it means as you work on a branch you get more and more conflicts with the trunk until it becomes unusable. A mergepoint stops you having to duplicate merges that you have already done, so you can maintain a branch for long periods of time. It's a requirement if distributed repositories get implemented, because they'd be branches that could exist for months/years. > I would add repository integrity checking and atomic commits. I have an > idea for how to implement atomic commits that might not be that hard. cvs is pretty atomic anyway - it locks everything, makes sure the commit can succeed, then does it, then unlocks. Without abandoning RCS there probably isn't a better way to do it. Tony _______________________________________________ Cvsnt mailing list Cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs