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.
Tony Hoyle wrote: > 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 > > 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. Correct me if I'm wrong, but I thought that the problem with WinCVS's DLL is that it wasn't kept in sync with changes/fixes in cvs.exe's functionality. But, if cvs.exe depended on such the same library then that wouldn't be such a problem. There are certain parts of cvs.exe that have to be re-implemented by every client, in particular parsing and/or modifying the files in the "CVS" subdirectories. And now that you are allowing people to store settings in the registry, having an API for storing/retrieving settings would be helpful. I think that at least those things could be factored out. But, I will have to see how easy it is to do that. I definitely don't want to rewrite the whole thing. >> 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. I was talking about atomicity as it is defined in the ACID principle: if one part of the commit fails, then the whole commit should fail. Currently, you can do a partial commit (say, if a network error occurs in the middle of the commit). I was thinking of a very simple method that requires minimal changes to CVS but I'm not sure if it will work: * Everytime an RCS file is modified, that modification has to be stamped with a changeset marker, some identifier/number that uniquely identifies the commit. The same identifier thus gets written to every RCS file that is changed during a single commit, and no two commits will ever have the same changeset marker. * After every RCS file modification is made, then the changeset marker gets appended to a changeset log file. * When examining an entry in the RCS file, you can see if that change was part of a valid commit by looking up the matching changeset marker in the changeset log file. If the changeset log file doesn't contain the marker, then the entry must have been part of a non-committed change and so should be ignored/overwritten. * Code that interprets RCS files will have to be changed to skip over the invalid entry. Since invalid entries would always be overwritten by the next commit to the file (which would likely occur right away), there can be at most one invalid entry per RCS file, and nearly always there will not be any invalid entry. * Current code that interprets RCS file--but wasn't modified to understand the changeset markers--would still "work" in the same way that they work now. But modified code would always show a valid view of the repository. - Brian _______________________________________________ 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