[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Harrison, Andy]

Hi Tony,

I think this sounds like a good idea, however I have a couple of
concerns over some details. Most of our users use WinCVS as the front
end and so any new cvs option would initially be unavailable to them. If
this was implemented as proposed then we would also have to patch WinCVS
to use it. However, would it be possible to do it slightly differently,
so that instead of changing -j to -J, we instead stick with -j but add
another flag to indicate which version of -j we wish to use? This way I
could simply get the users to add this to their .cvsrc file as a
one-time operation, and then they could carry on as before. Ideally, I'd
like it added as an option on the server configuration, but I realise
that this would probably be more work.

Rgds,
Andy

--
Andy Harrison - Platform Software Engineer 
Anite Telecoms Ltd. Ancells Business Park, Fleet, Hampshire, GU51 2UZ,
UK
"No matter how bad things seem... 
...nothing could be worse than being used as a towel rail." - A.A. Milne


-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of Tony Eva
Sent: 15 January 2007 10:12
To: cvsnt at cvsnt.org
Subject: Re: [cvsnt] Mergepoint issues on 2.5.0.3 b2382

I've been staying out of this thread until now, even though I started
the original discussion back in June last year.  That's mainly because
Andreas and Andy are articulating my viewpoint better than I could, and
I support everything they have said so far in this thread 100%.

That said, it really looks like both sides are firmly entrenched in
their views and are not open to being persuaded.

On one hand, we (Andy, Andreas, me) fully understand how bidirectional
merges work, when to use them and when not to, and in fact we all *have*
used them for years without any data loss and want to continue to do so.
It is especially frustrating for us that CVS *used* to support this
functionality, and it was one of the biggest factors that caused us
(well, my group anyway) to make the migration from plain CVS to CVSNT;
so to have it removed again was a special irritation.

On the other hand, I can see that Tony Hoyle and Arthur believe strongly
that this functionality will cause problems.  We happen to disagree -
equally strongly! - but let that pass; I understand that March Hare has
to support their paying customers, they have to pick up the pieces, and
it's hard to explain to a paying customer why your product does
something when you don't actually believe yourself that it should be
doing it.

However, we are now facing the situation where at least three groups of
developers are heading off independently with home-brew patched versions
of CVSNT in order to get this previous capability restored.  This cannot
be a good thing.

So, I'd like to make the proposal (suggested earlier) that the
bidirectional mergepoint support is reinstated in the official CVSNT
2.5.0x stream, but under the -J option instead of -j (the latter would
retain its current one-way mergepoint function).  The help text for the
update command can have a note to say that the -J option should be used
with caution, and the manual can have text to describe its operation and
if necessary have a prominent warning note that the option should not be
used unless its function is fully understood.

However, I would very strongly resist the suggestion that a warning
message should be displayed whenever the -J option is used, for the
simple reason that it will be seen by non-CVS literate developers who
are following a standard laid-down process: they could be unecessarily
confused and spooked into trying to fix non-existent problems in their
merges.

Arthur: if a patch of this nature is developed, and submitted in the
cvsnt-dev list, are you (as CVSNT maintainer) prepared to accept it
(subject to the usual inspections and revisions)?

--
Regards
Tony Eva
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt


 Scanned for viruses by BlackSpider MailControl


A member of the Anite Group of companies. Please refer to www.anite.com for individual Anite company details. The contents of this e-mail and any attachments are for the intended recipient only. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. It may contain information which is confidential and/or covered by legal professional or other privilege. Contracts cannot be concluded with us nor legal service effected by email.  

Anite Group plc
Registered in England No.1798114
Registered Office: 353 Buckingham Avenue Slough Berks SL1 4PF United Kingdom
VAT Registration No. GB 787 418187

Scanned for viruses by BlackSpider MailControl.