[Cvsnt] Next release features

Brian Smith brian-l-smith at uiowa.edu
Sat Mar 9 17:07:40 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.


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



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