Misha Aizatulin wrote:
> Let me summarise a bit. I guess we are mainly discussing two questions:
>
> 1. Can link following be useful?
>
And please consider this in the normal context of subversion where
multiple people are committing changes and updating. And the scenarios
where the target workspaces do and don't exist.
> 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?)
>
From subversion's point of view there is no difference between 'you'
and the 'other users'. If you delete your workspace and check it back
out, you must get back exactly what you committed, even if you are
checking out to a different location. If someone else checks it out
they must get exactly what you committed. If subversion replaces your
symlink with the contents of the target in your new checkout, your setup
won't work the way you expect any more. If subversion tries to restore
both the symlink and the target it may not have write access to the
target location - in fact the target location may not even exist
relative to this new checkout.
> - 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).
>
Externals are the right way to handle the scenario you propose and if
you need different access controls for these files, that configuration
really belongs in the repository rather than being a accident related to
where you put multiple copies of the file. . I'm getting the feeling
that you just don't want to do the work to set it up to provide the
functionality you need. With externals, you get your choice of where
you actually edit and commit the common content. It can be from one of
the external references but it doesn't have to be - and you can have
different access control in case commit access should have different
restrictions from the other repositories.
> - 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.
>
>
And I'd say you haven't fully considered what would have to happen in an
update or a new checkout.
> 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.
>
>
What does that mean for someone who has deleted their working copy of
B? Or has the locations arranged differently?
> 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.
Scenario 1 only makes sense if you have both A and B working copies in
known locations. The point of using subversion is that you can get
back what was committed. Suppose you delete your working copies of A
and B and check them back out in different locations. How can
subversion possibly reproduce what you had and now expect to have back?
> 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.
>
Any update or new checkout will do a bad thing if it follows symlinks.
You haven't described any write access through them at all.
>
>> 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.
>
Look at any update or new checkout scenario to see the drawbacks.
Perhaps your usage is unusual in that you only commit from a single
workspace that itself is never updated. That is very unusual and
shouldn't become a requirement.
>> 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.
>
>
OK, but that requires the workspace copies to be in known locations. It
would be very, very surprising to me if a subversion checkout or update
ever created or modified files in places unpredictable to me.
>> 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.
>
>
Subversion is a two-way street. It expects commits to come in from
workspaces in any location and it expects update requests to duplicate
those changes to workspaces in other locations. If someone commits a
change to this file and you do an update, subversion would have to
decide whether to replace your symlink with the updated file contents
(as you seem to want to happen to other people) or to follow the
symlink and update the target, which would be problematic on a security
level. Do you really want other people to be able to commit symlink
targets that will try to write in arbitrary locations outside of your
working copy tree? Either of these choices would be surprising.
>> 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.
>
>
This seems to depend on WC-B existing, doesn't it? What happens if it
doesn't?
> 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.
>
>
Depending on magick genies usually turns out badly, at least in the
movies. If you really want separate copies, make and commit separate
copies that work naturally for both read and write access. If you
really want a single copy, fix your repository access control so
everyone can get a single copy. Either of these will give you a setup
that you can reproduce with new checkouts instead of relying on magic.
--
Les Mikesell
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374499
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-22 19:04:00 CEST