[cvsnt-dev] Re: Suggestion for CVS edit

Julian Brierley julianBrierley at hotmail.com
Mon Jun 28 23:40:34 BST 2004

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:
> Julian Brierley wrote:
>> My experimental code, which is a hack of a recent snapshot of 
>> CVSNT_2_0_x, seems to show such an approach is feasible although there 
>> are many scenarios still to test.
>> Does anyone have any views on the desirability of such a change? Have 
>> I overlooked something? Are there any better approaches?
> Did you ever get anywhere with this?
> The biggest problem is that the clients expect the edit information to 
> be global.  Edit -c also is a simple check to see if 'editors' returns 
> any output... it'd have to be much more complex for tag/branch support.
> It'd probably be best to junk the existing fileattr format and start 
> again with a new one (it has other problems eg. you can't edit a file 
> with '+' in the filename).  As long as the client/server communication 
> is compatible then that shouldn't cause any problems.
> Tony
Yes I did and it seems to work as expected - at least for my testing of 
local and client/server edit, unedit and commit operations.

I used the revised fileattr _editors format mentioned previously. For 
the experiment I limited the code changes by continuing to pass the old 
val format into notify_do and assembled the new one in editor_set. This 
needs to be tidied up.

As you say Edit -c needed to check for an editor of the same tag. Commit 
-c for a tag and sandbox match. notify_do now needs the val parameter to 
do an unedit of the correct branch.

There is one call to notify_do where I was unable to supply the val 
parameter - the one from RCS_unlock. I could not see in what 
circumstances a clear of an edit would be required from this call - can 
you enlighten me?

Several other functions needed to be aware of the new branchtag. 
fileattr_modify had to be made case insensitive because of the pathname 
in the attribute key - this change might be undesirable in other cases?

What sort of fileattr format did you have in mind?


More information about the cvsnt-dev mailing list