Hi,
I have several times had the same situation - a need for simple symlinking
to a file or directory, and following it on commit/checkout. I didn't really
understand what the fuss was about. "So many other unix tools has a
follow-symlinks option."
Misha wrote:
> 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.
What happens if a user commits a symlink? Will they now be followed on
subsequent checks out?
As Mikesell asks:
> 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?
Hmmm, that could indeed be dangerous. OK, the repo could be set to forbid
users to commit symlinks, or you could label particular symlinks as locked
and OK-to-follow, the rest just normal unfollowed symlinks.
If symlinked directories are allowed too, two repositories could share one
such directory - then what about the .svn folders? Now, that is not so easy
to fix! Of course, you can also symlink to mother-directory, creating a
circular issue, or more advanced cross-links. This standard problem exists
for all unix-tools, but they may have a simpler job, like aborting at a
certain depth, "too deep", leaving the user with half the work done.
While it could probably all be overcome somehow - see "man tar" below, OMG!
- well, if the need is not enough (and that seems to be the case), adding
complexity to anything is usually a bad idea.
Hopefully this is a part of a correct understanding of why it is not so
easy, so I can go to sleep truly wiser, and be justified in no longer
feeling that the SVN developers simply forgot the --follow-symlinks option.
Best,
Frank
man tar:
...
Archive entries can exploit symbolic links to restore files to
other directories. An archive can restore a symbolic link to
another directory, then use that link to restore a file into
that
directory. To guard against this, tar checks each extracted
path
for symlinks. If the final path element is a symlink, it will
be
removed and replaced with the archive entry. If -U is
specified,
any intermediate symlink will also be unconditionally removed.
If neither -U nor -P is specified, tar will refuse to extract
the
entry.
To protect yourself, you should be wary of any archives that come from
untrusted sources. You should examine the contents of an archive with
tar -tf filename
before extraction. You should use the -k option to ensure that tar
will
not overwrite any existing files or the -U option to remove any pre-
existing files. You should generally not extract archives while
running
with super-user privileges. Note that the -P option to tar disables
the
security checks above and allow....
Zzzzzzz....
On Wed, Jul 22, 2009 at 8:58 PM, Misha Aizatulin <avatar_at_hot.ee> wrote:
> 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].
>
--
Soren "Frank" Munch
CEO, U5com Co Ltd
~~~~~~~~~~~~~~~~~~~~~~~~
U5com Co Ltd
- productive corporate networks
and web-systems since '97
2/22 Iyara Building 7th floor, #705
Chan Road
Thungwatdorn, Sathorn
10120 Bangkok
Thailand
web: www.u5.com
email: sfm_at_u5.com
phone: +66-2-678-7500(-1)
mobile: +66-81-431-3040
fax: +66-2-678-8400
~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374529
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-22 20:49:05 CEST