[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking UI comments

From: Jonathan <jonathan.michael.stewart_at_us.army.mil>
Date: 2004-10-15 02:55:25 CEST

Mark Phippard wrote:
> Ben Sewell <Ben.Sewell@ricardo.com> wrote on 10/14/2004 12:08:53 PM:
>
>
>>Mark Phippard <mailto:MarkP@softlanding.com> wrote on 14 October 2004
>
> 16:35:
>
>>>I assumed
>>>that this was one of the reasons Subversion didn't use extensions in
>
> the
>
>>>first place.
>>
>>Presumably a file originally named index.mine.html, when clashing, would
>
> get
>
>>called index.mine.mine.html & index.mine.r1234.html (rather than
>>index.mine.html.r1234 as is the alternative suggested earlier)
>
>
> What I meant, was what happens if you have a conflict in file index.html
> and for some reason, you actually have a real file named index.mine.html
> in the same folder?
>
>
>>>Would there be any value, especially in the hijack scenario, of using
>
> less
>
>>>techy names, such as:
>>>
>>>filename.mine.ext
>>>filename.base.ext
>>>filename.new/theirs/modified/conflict.ext
>>
>>Or perhaps
>>
>>filename.mine.ext
>>filename.base.ext
>>filename.<UID of user who last committed>.ext
>
>
> What if the user name is base or mine?

Just a point no one seems to have brought up yet with this, what if the
extension is a 2 parter like .tar.gz for example? I have not checked
but I think on windows you can treat that as a "single" extension and if
you do filename.mine.ext it would become something like
filename.tar.mine.gz which seems like a not so good idea to me.
Prepending the "mine" etc would seem to work better, if we don't want to
put it on the end of the file to avoid breaking file associations.

Jonathan

>
> Mark
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 02:55:53 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.