> But in David's example he is running svn st from within the
> /foo folder of his working copy. The Subversion code would
> not even know that /bar existed without doing a ton of work
> that it does not have to do today.
Yeah. That's why I think it may be a lot easier to restrict repository
symlinks to just directories to start of with. Essentially the symlink
directory that is checked out would contain the normal .svn dir and would
behave as if you checked out the orginal directory manually.
> I was referring to the user modifying both files in their
> working copy. As you say, they are not symlinks, just copies
> so that can do this. Now they try to commit one or both,
> what happens? What if they do an update first, and it brings
> in changes to file1 (and therefore file2)? It now has to
> merge these changes, so in theory, file1 might be conflicted
> now and file2 perhaps was auto-merged.
No, the idea is that file2 doesnt really exists. Both working copies are
really just checking out file1. Think of file2 simply just an alias or a
reference. When you check in file2 it modifies file1. When you do status
against file2, you're comparing against file1.
>
> OK, I have local mods in file2 and I delete file1 (all in the
> same WC). Is
> file2 removed since it was a link?
>
Same behaviour as if someone deleted a file that you're currently working
on. Think of /foo/file1 and /bar/file2 as simply 2 checkouts of the same
file in the repository.
Duke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 31 21:03:38 2006