Let me summarise a bit. I guess we are mainly discussing two questions:
1. Can link following be useful?
2. Can link following be dangerous?
As to the first question, I think my scenario illustrates that pretty
well: two repositories, A and B, and a file bib that I would like to
commit to both of them. I cannot refer from A to B and back because of
access restrictions and because I wouldn't like the health of one
repository to depend on the other.
3 candidate solutions might be considered:
- use file links - this is very flexible and does not require any
special setup. Also it doesn't change anything from the point of view of
the other users, which for me is a very good thing (why should I bother
them with my problems?)
- use externals. This would require finding and setting up a third
repository C. This would also impose restrictions on where I can place
bib: as soon as I commit it to C, I cannot have it in A's or B's folders
any more, and this is very unnatural (because obviously it belongs to
both A's and B's folders, otherwise I wouldn't want to commit it there).
- use current svn handling of symlinks (store the symlink and try to
reproduce it in all working copies). This doesn't work in my situation,
because the symlink would have to point outside of the repository.
I'd say, the link following approach is the only one that solves the
problem without introducing any extra inconvenience, so it is indeed useful.
Now to the second question. I would not go into details of how svn
works, but instead answer the question by reducing the situation with
symbolic links to the situation without them. For instance, in the
following example, two scenarios are equivalent:
Scenario 1: I have a symbolic link from A's working copy to a file in
B's working copy. I do update on A and this changes a file in B's
working copy.
Scenario 2: I have two identical files x1 and x2 in A and B. I do
update on A, then I open x1 and x2 in a text editor and manually copy
any new changes from x1 to x2.
The outcomes of both scenarios are exactly the same and scenario 2 is
perfectly legitimate, so scenario 1 must be legitimate as well. To
generalise: Any bad thing that can happen with symbolic links, can
happen without them. Give me a situation where symbolic links lead into
a bad situation and I will describe how exactly this situation can be
reached without using them.
Thus symbolic links pose no more danger than is already there.
Now to some of your questions:
Blair Zajac wrote:
> It seems to be a workaround for the lack of a repository that
> everyone has rights to.
I won't argue about what to call it. My view is that it solves the
problem without having any drawbacks, so even if it is a "workaround",
it is a good one.
Les Mikesell wrote:
> Would you want an
> update to follow the symlink and produce a surprising change in the
> other working copies that have no other relationship?
Yes, that is exactly what I want. This is why I am using the symlink.
I'd only say that the change would not be surprising, as it is intended.
> And when you
> commit that other working copy, how is subversion supposed to check that
> the target of the symlink changed?
I'm sorry, I don't understand. Generally, it sees that the contents
changed at exactly the same times as it happens with regular files.
> he specific case that makes me itch is this:
>
> - UserA has commit access to repository A but not repository B.
> - He checks out a copy of bib from A, makes a change and commits.
> - Bib-A and Bib-B are now not identical.
> - You update your WC-A and WC-B. What happens?
If I update my WC-A first, the file in WC-B changes. Now if I update
WC-B, exactly the same things happen as if I manually edited the file
before the update.
> Really I think a lot of what's going on here is caused by a deeper
> problem; you have a rule about data integrity that you want to enforce:
> "bib must be the same in all repositories".
I don't have the constraint "bib must be the same in all repositories
at all times". All I want is that all changes to bib get propagated to
both repositories eventually without me having to do anything extra. As
I said above, the symlink is equivalent to a magick genie who notices
that one file changed and immediately copies all changes to the other file.
> What happens if
> your working copy gets corrupted and you have to do a fresh check-out?
Say svn goes berserk on A and writes junk into bib. Then junk is also
in the copy of bib in B. That's how symbolic links work.
> What if you go on vacation and other people want to keep working with
> the file?
If someone updates the file in A, I'll come back, update WC-A, get the
change, then commit WC-B and propagate the change into B. If it happens
that the file has been altered in B as well, I'll have to merge the changes.
Best,
Misha
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374441
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-22 16:00:23 CEST