Mark Phippard wrote:
> "Gale, David" <David.Gale@Hypertherm.com> wrote on 01/31/2006
> 01:39:18 PM:
>
>> I'd second this idea.
>>
>> Given:
>>
>> /foo
>> - file1
>> /bar
>>
>> svn link svn://example.com/foo/file1 svn://example.com/bar/file2
>>
>> Should produce:
>> /foo
>> - file1
>> /bar
>> - file2
>>
>> At which point, the following should be true:
>> svn co svn://example.com/
>> cd bar
>> <change file2>
>> svn ci
>> cd ../foo
>> svn stat -u
>> U file1
>>
>>
>> Any other design thoughts? Any votes against, or shall we pass this
>> on to the dev list?
>
> I wouldn't say that I am against it, but I think there are so many
> edge
> cases to consider that you have little chance of ever seeing someone
> try
> to implement it.
>
> First off, let me just say that your example does a nice job of
> expressing
> what you see as the requirements. But let's be realistic here. Once
> your
> repository is materialized into a working copy you have to start
> dealing
> with the realities and limitations of the local file system. In your
> example, how do you see the working copy code being able to see file1
> as
> having been changed, when it hasn't been?
The WC doesn't, until it checks the repository (hence the -u flag to svn
stat). My thought was that the repository would use a mechanism similar
to the cheap copies to track linked files, so updating one linked copy
updates them all, in the repository. The file system the WC is on
shouldn't make a difference.
> Now for a few quick edge cases:
>
> What if file1 and file2 are both modified in the working copy?
>
> What does svn delete of one of the files do? What if one is changed
> and
> the other deleted?
See, I knew there were things I hadn't thought of yet. :-) My initial
reaction would be to treat multiple changes to the same file similar to
instances of concurrent development, such that, in your edge cases, svn
would attempt to merge the changes together or raise a conflict. But
I'm not sure I like that idea--if there is a conflict, would both files
receive .mine files? Would they both need to be resolved? That could
get ugly in a hurry...
Another thought would be requiring the user to lock the file(s), but
that's not ideal either, for a variety of reasons.
Ok, I'm at a loss. I still think this'd be a useful feature, but you're
right, it's looking to have some major downsides, and thus isn't very
feasible. Ah, well.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 31 20:49:55 2006