Jonathan wrote:
>>> 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.
That's a good point. Of course, if the "mine" is prepended to the
filenames, then the various versions of an affected file will not be
listed together in a sorted directory listing. The nice thing about
using a suffix (or an infix) is that all the versions of the same file
are easily visible together.
Although the .tar.mine.gz example is weird, I think it's probably better
than using a prefix. Ideally, the user should be able to find the
affected files easily, but I think prefixes would make this harder.
Unless the prefixes would be close to each other in a directory listing,
e.g. "svn-base" and "svn-mine" instead of "base" and "mine"? They still
wouldn't be listed along with the original file, so that wouldn't fully
solve the problem.
There seem to be drawbacks to any filename-munging solution. Especially
since there is never a guarantee of avoiding a name collision. What if
"filename.ext", "filename.ext.mine", and "filename.ext.2" are all under
version control? Which file does "filename.ext.2.mine" correspond to?
Hmm, I wonder how this is currently handled...
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
Received on Fri Oct 15 09:16:52 2004