Re: Conflict file naming

[email protected] wrote:
> Daniel Serodio <[email protected]> writes:
>   
>> Ryan Schmidt wrote:
>>     
>>> On Jan 5, 2006, at 11:43, Troels Arvin wrote:
>>>       
>>>> When a conflict is detected during updates, Subversion creates a
>>>> number of
>>>> files, e.g.
>>>> foo.doc.mine
>>>> foo.doc.r63
>>>> foo.doc.r64
>>>>
>>>> Is it possible to tell the Subversion client to use other namings for
>>>> the .mine and before/after-revision files, e.g.:
>>>>
>>>> foo.mine.doc
>>>> foo.r63.doc
>>>> foo.r64.doc
>>>>         
>>> That sounds like a great idea to me, but I don't think Subversion
>>> currently gives you any control of that, nor does searching the issue
>>> tracker for "conflict" show me any relevant bug reports / feature
>>> requests.
>>>       
>> Sounds like a great idea to me too, can you file a RFE about it?
>>     
>
> I too thought we had an issue for this, but I can't find any.  Yes,
> please file an enhancement-request issue (pointing to this thread).
> Frankly, I don't think we even need a config control for this -- it
> ought to be the default behavior.
>
> Although of course, any examples in the book(s) and FAQ will need to
> be updated if we change this behavior.  Mmm, and worse, some programs
> might be depending on it.  In other words, the current practice of
> putting the Subversion-specific extension on the end might be
> considered an API of sorts.
>
> I've CC'd dev@ to see what people there think.
>
> -Karl
>
>   
I agree with this enhancement in principle, but the actual 
implementation would be a different story. 

One would have to be very careful on where they put the revision/mine 
strings because some people / systems require multiple ending extensions 
(example - .tar.gz) to be read as well.

Would it spoil the names (make them that much harder to find) if the 
extra tag is added to the front of the file name (example - 
r34.foo.tar.gz, mine.foo.tar.gz)?  My argument against this method is 
that now all of the conflicting files are spread out in the directory 
based on revision numbers / "mine".

So then the next option is to try to concatenate the revision text as 
the first extension after the file name (example - foo.r34.tar.gz, 
foo.mine.tar.gz, etc).  But then it becomes harder to read.  Do we need 
to educate our users better for this scenario?  Personally - I like this 
option best.  If I ever find any documents in the working copy that 
start as "mine.xxx.xxx.xxx" I will know that there was a conflict somewhere.

My 2 cents.

Regards,
Frank