[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request: allow for relative working copy paths in svn:externals definition

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Fri, 2 Mar 2012 07:42:00 -0600

On Fri, Mar 2, 2012 at 6:58 AM, Humm, Markus
<Markus.Humm_at_de.ebmpapst.com> wrote:
>
>> > While it is nice that you have concerns about my security in case I should have to deal with malicious servers,

Not just malicious servers. With a scheme that lets you splatter
files anywhere, anyone who can commit can accidentally or
intentionally kill everyone else's machines.

>> > I would prefer to have a choice. Maybe some setting wich allows me, based on the server URL (or if that's too
>> > complicated for a start), to allow ../ in local externals paths or disallow this. With such a setting, SVN would
>> > seamlessly allow us to use our current directory layout while maintaining the benefits of atimic checkins.
>
>> Excuse me, but given the layout requirements you seek, can you get away with symlinks?
>
> I'm not sure symlinks under XP are powerfull enough and the use of them is not easy enough for my colloeagues.
> I'd really prefer a externals based solution.

And these people are going to be able to figure out what happened when
critical OS or personal files are overwritten? On an OS that won't
prevent it?

> That is why I suggested a setting controlling this. The default could be to disallow it. You can misuse nearly
> everything! So nearly everything in the world should be disallowed. I also suggested that limiting this relative addressing
> to a single level in the hierarchy (means only ../ instead of ../../) would be sufficient for must users and still keeping
> a good deal of the security. And if you could enable this for individual "domains" only one can still limit it for local
> servers only. If properly implemented it will only do good for those needing it and no harm (unless misconfigured, but
> that can be said for most configuration options in most software...)

What is wrong with keeping everything under one tree? If you are too
lazy to re-arrange the paths for includes and linkage searches in your
compiler project/build files, treat each thing that you want in
parallel directories as a component and make your subversion main
project files have nothing but the externals that drop the components
in the right place - which incidentally gives you a nice single place
to control the branch/tag versions of each thing that you use.

-- 
  Les Mikesell
     lesmikesell_at_gmail.com
Received on 2012-03-02 14:42:33 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.