[Cvsnt] Next release features

Tony Hoyle tmh at nothing-on.tv
Sat Mar 9 15:13:44 GMT 2002


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



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook