Rehul,
I've
removed bug-cvs from the list of recipients since I do not think it is related
to this discussion.
I've
forwarded your comments on the patch to our development manager, but I would
suggest that the CVSNT forum is a better place for a discussion on
features/patches for CVSNT.
The
thread you referenced as "CVSNT repository corruption" is an unsubstantiated
reprort by a non-contributor using extremely old versions of the software (all
of which we tested and didn't cause this problem) - which is far more likely a
"user error" than anything else. The SVN repository corruption problems
documented are in the SVN bug database and are confirmed by the SVN developers
as real bugs.
As for
the reported stress test problems, as indicated on the CVSNT list we have run
similar tests with many more clients and have found no problem, and as requested
you have not supplied any traces or other debugging information for us to assist
you. We have also offered to inspect your test set if you give us access,
and you have not taken us up on that offer.
Finally as previously advised most of the answers to
your questions about CVSNT are answered in the FAQ, eg:
"Where
can I download stable releases of CVSNT"?
"Are
the commercial releases of CVSNT the same as the free ones?"
Finally if you have any "stability issues/freezes" with
an open source product please report it including the essential
debugging information rather than complaining:
Regards,
Arthur
Barrett
Hello Arthur :
See response
below:
Arthur Barrett wrote:
Rahul and Patrick,
T
In particular your original patch was not suitable for inclusion in
CVSNT (or probably for cvs 1.12) as it has a hardcoded list of keywords,
Like what ? The keywords[] array in kwfilecmp.c is
same as
used by CVS src base. It could be refactored but then kwdiff
standalone
utility needs to link with more code ...anyways let me focus on
the major points
you raise below ..
which neither CVS nor CVSNT use. The solution you provided was also
considered to be overcomplex - a much simpler algorithm could be used
very easily by patching the RCS compare routines themselves... all
keywords for example exist on a single line ($Log$ is a special case but
wouldn't be handled by this version either)... In our opinion you could
simply pair a strcmp with a call to expand_keywords and it'd work very
simply, without introducing new untested algorithms into the stable
codebase.
It seems like you are misunderstanding the algorithm. Its
not expanding the
keyword rather un-expanding them to be able to ignore
spurious keyword
differences at commit time. Pair of strcmp obviosuly
don't make sense as the client may have
put bytes in keywords that will
not match with anything on server-side. In other
words the patch
"canonicalizes" the keywords instead of strcmp'ing them. Will be happy
to
explain the algorithm in more details if you still have confusion.
Except for $log$ it
takes care of every conceivable differences in keywords
that could cause a spurious
commit to occur.
As for subversion being an alternative for commercial software
development, there was a recent thread on that subject ("Missing CVS
Windows Client") that I advise you read carefully since it referenced
cases of repository corruption in SVN with both the file and database
In another thread that I posted on in the CVSNT forum
http://www.cvsnt.org/pipermail/cvsnt/2006-February/023707.html
http://www.cvsnt.org/pipermail/cvsnt/2006-February/023713.html
it
appears CVSNT has more stability issues to work out compared to CVS and
Subversion.
No one from CVSNT-dev has been able to point to a
stable version that can be
used for conducting stress tests. In our labs we
continuously run stress tests
on various CM backends supported by our
products (http://www.wandisco.com).
Many of these
stress tests are rigged to crash servers at random points in time.
Barring
minor issues, CVS and SVN seem to be fairly solid, CVSNT has had more
issues.
Recent threads on CVSNT have posted about repo
corruption:
http://www.cvsnt.org/pipermail/cvsnt/2006-February/023742.html
backends. The CVSNT project endeavours to deliver open source
I am still confused about the CVSNT open source model.
For example in this
post - http://www.cvsnt.org/pipermail/cvsnt/2006-February/023724.html
you
seem to indicate the commercially supported customers get a
different/stable
set of bits than the open source bits. The last build that
we picked up was from your
company site and you mention in the above post
that it was "rejected" for
commercial support customers yet it was
the version available for download as
open source/free version.
versioning tools that facilitates good CM process. Hence ACL's, Audit,
Mergepoints (Merge Tracking), True Rename (not copy+delete), Unicode
Sure you have an impressive sounding list of features.
But it will
be even better if they worked without the stability
issues/freezes.
filenames, Unicode Merge etc. None of those features are yet to make it
into SVN:
http://subversion.tigris.org/roadmap.html
If you are interested in contacting the CVSNT project then please
contact the newsgroup:
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
or
news://news.cvsnt.org/support.cvsnt
Please read this FAQ before submitting a support request:
http://march-hare.com/cvspro/faq/faq2.asp#2z
Regards,
Arthur Barrett
-----Original Message-----
From: address@hidden
[mailto:address@hidden] On
Behalf Of Rahul Bhargava
Sent: 11 February 2006 11:41
To: Patrick Richardson
Cc: address@hidden; address@hidden
Subject: Re: [patch #4573] Fix for keyword expansion problem/mis-feature
during commit
Sorry to hear that Patrick. Indeed, Subversion implements the same
behavior as the proposed patch. Subversion allows keywords properties
to be specified to a file. Changes to keyword data are not even
transmitted to server as the local sandbox maintains a copy which is
diff'd against for spurious changes (keywords). Merging and updates
also do
not generate
conflicts with keywords in Subversion. The kwdiff algorithm we had
submitted in the patch can
enable all these features that Subversion supports. Its a pity that the
patch was rejected
by CVS maintainers. The algorithm defined in the patch could have been
also used to
reduce the footprint of a CVS server process when doing RCS
diff/compare, that was also
not considered useful.
We have made the patch public, it can be downloaded from -
http://support.wandisco.com/index.php?_m=downloads&_a=viewdownload&downl
oaditemid=9&nav=0
I am also cc'ing info-cvs mailing list, so that other CVS users wanting
Subversion like behavior could
use/modify the patch.
Patrick Richardson wrote:
Follow-up Comment #17, patch #4573 (project cvs):
It is really unfortunate that this bug will not be fixed. There has
been no response to the case I made two and a half months ago FOR
fixing the bug. It absolutely blows my mind that the CVS maintainers
will not even consider implementing this patch as a non-default
option.
Since it looks like the CVS maintainers will never fix this problem, I
had to recommend to my company that other alternatives should be
evaluated, and if a suitable alternative is found, we should switch.
After a careful evaluation of several open-source and commercial
alternatives, we have decided to switch to Subversion.
Yes - the Subversion team got it right. Keyword expansion is
Subversion works as CVS would IF the proposed patch were incorporated.
_______________________________________________________
--
Rahul Bhargava,
SCM Solutions
WANdisco,Inc.
Pleasanton, CA
http://www.wandisco.com