You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Humm, Markus" <Ma...@de.ebmpapst.com> on 2012/03/01 16:35:32 UTC
Feature request: allow for relative working copy paths in
svn:externals definition
Hello,
I'm currently learning SVN as we're planning to use it here in the near future.
Some of our projects are structured like this (MS Windows):
D:\Source\Project1
D:\Source\Project2
D:\Source\CommomLibraries
Where Project1 and Project2 are individual projects but both rely on files
which reside in D:\Source\CommomLibraries and should reside there.
One could try to use svn:externals not to set this up properly so that a
Checkout of Project1 also checks out CommonLibraries and a update on Project1
also takes into account the changes you've made to CommonLibraries.
For me it seems that SVN 1.7.x currently cannot do this. What it could do is to
place the structure described above on the repository in the same way, but in
the working copy the COmmonLibraries folder would have to reside below each
Project folder:
D:\Source\Project1\CommonLibraries
D:\Source\Project2\CommonLibraries
But that is not what I want. What's even more:
I'm using Tortoise SVN 1.7.5 and this one managed to allow me to set up
svn:externals like I assumed would work. It even commited the structure
properly to the repository. But when I tried to checkout this project on
another computer I get a assertion from svn itsself.
In File
»D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c«,
Zeile 2890: Assert-Anweisung schlug fehl
(svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
The local path of my svn:externals was this: D:/u/svnexternaltest2/gemeinsamme_bibliotheken
If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead Tortoise would detect that it contains a .. Or is a absolute path. Obviously either Tortoises or SVN's absolute path detection loginc is not 100% fool proof as well.
Back to my original issue: is there a way to get the structure I want via svn:externals,
Or would such a feature be a candidate for a feature request so we can get this in the future? If it get's a feature request, what actions can I do to speed up ist implementation? (programming it/submitting patches is unfortunatelly out of the question)
I really would not need absolute paths, relative paths would be sufficient, even if these
only supported a single level (../ is sufficient for me).
Best regards
Markus Humm
EB-EV
Entwicklung Elektronik
ebm-papst Mulfingen GmbH & Co. KG
Bachmühle 2
74673 Mulfingen
Phone.: +49 (7938) 81 531
Fax: +49 (7938) 81 9531
mailto: Markus.Humm@de.ebmpapst.com
http://www.ebmpapst.com
GreenTech - Ein Zeichen, mit dem wir Zeichen setzen. A symbol that defines standards.
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Daniel Shahaf <da...@elego.de>.
Humm, Markus wrote on Fri, Mar 02, 2012 at 12:13:28 +0100:
> Hello,
>
> thanks for your answer.
>
> While it is nice that you have concerns about my security in case
> I should have to deal with malicious servers, 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
I agree. While the default should be to disallow any modifications
above the working copy root, I don't see a reason not to make it an
opt-in feature.
> What do I need to do to get this feature? Where do I need to lobby for
> it?
The best thing you could do is head over to the dev@ list, drive
a design discussion, get consensus on it, and ideally also be willing
to implement it (or to hire someone to do so):
http://subversion.apache.org/contributing#code-design
Alternatively, you could record your request in our issue tracker:
http://subversion.apache.org/reporting-issues.html
Re: Feature request: allow for relative working copy paths in svn:externals definition
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Andy Levy,
am Freitag, 2. März 2012 um 14:45 schrieben Sie:
> True symlinks don't even exist on XP.
But XP has junctions/reparse points which would be just as good as
symlinks on directory level as in this case needed. Creatable with
fsutils(?) and Sysinternals' junction.exe, which I would prefer.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Andy Levy <an...@gmail.com>.
On Fri, Mar 2, 2012 at 07:58, Humm, Markus <Ma...@de.ebmpapst.com> wrote:
> Hello,
>
>> > While it is nice that you have concerns about my security in case I should have to deal with malicious servers,
>> > 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.
True symlinks don't even exist on XP.
AW: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by "Humm, Markus" <Ma...@de.ebmpapst.com>.
Hello,
>>
>>>> We created a Junction inside D:\Test\Projekt1 named
>>>> D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>>>
>>> Can you do this the other way around? That is, make D:\Test\Common
>> the junction point, pointing to wherever your svn external is going to
>>> drop the files? And figure out what it is you really want to
>>> happen in the case where you want to check out D:\Test\Projek1 and
>>> D:\Test\Projek2 and they both have the same relationship to
>> D:\Test\Common but want different revisions to appear there.
>>
>> No, the other way round doesn't work, because d:\Test\Common cannot
>> point at the same time both to D:\Test\Projekt1\JunctionTest and
>> D:\Test\Project2\JunctionTest. We just tested this. The question now
>> is, why does SVN detect our hardlinked directory as special type of
>> directory and thus creates us pain? (as otherwise we'd have a solution
>> which could work for us)
>
> I think you are going to have a very, very confusing time if you do get the common directory to simultaneously be junctioned (either
> direction) to externals that can be pointed at different revisions.
> What is it you would like to happen in that case?
That is not a real problem for me, as I only work at Project1 XOR Project2 at any given time.
When I switch to the other project I have to update it first which would replace the common files.
Best regards
Markus Humm
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Mar 2, 2012 at 9:58 AM, Humm, Markus
<Ma...@de.ebmpapst.com> wrote:
>
>>> We created a Junction inside D:\Test\Projekt1 named
>>> D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>>
>> Can you do this the other way around? That is, make D:\Test\Common
> the junction point, pointing to wherever your svn external is going to
>> drop the files? And figure out what it is you really want to happen
>> in the case where you want to check out D:\Test\Projek1 and
>> D:\Test\Projek2 and they both have the same relationship to
> D:\Test\Common but want different revisions to appear there.
>
> No, the other way round doesn't work, because d:\Test\Common cannot
> point at the same time both to
> D:\Test\Projekt1\JunctionTest and D:\Test\Project2\JunctionTest. We just
> tested this. The question now is, why does SVN detect our hardlinked
> directory as special type of directory and thus creates us pain? (as
> otherwise we'd have a solution which could work for us)
I think you are going to have a very, very confusing time if you do
get the common directory to simultaneously be junctioned (either
direction) to externals that can be pointed at different revisions.
What is it you would like to happen in that case?
--
Les Mikesell
lesmikesell@gmail.com
AW: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by "Humm, Markus" <Ma...@de.ebmpapst.com>.
Hello,
>>
>> We created a Junction inside D:\Test\Projekt1 named
>> D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>
> Can you do this the other way around? That is, make D:\Test\Common
the junction point, pointing to wherever your svn external is going to
> drop the files? And figure out what it is you really want to happen
> in the case where you want to check out D:\Test\Projek1 and
> D:\Test\Projek2 and they both have the same relationship to
D:\Test\Common but want different revisions to appear there.
No, the other way round doesn't work, because d:\Test\Common cannot
point at the same time both to
D:\Test\Projekt1\JunctionTest and D:\Test\Project2\JunctionTest. We just
tested this. The question now is, why does SVN detect our hardlinked
directory as special type of directory and thus creates us pain? (as
otherwise we'd have a solution which could work for us)
Best regards
Markus Humm
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Mar 2, 2012 at 9:21 AM, Humm, Markus
<Ma...@de.ebmpapst.com> wrote:
>
> We created a Junction inside D:\Test\Projekt1 named
> D:\Test\Projekt1\JunctionTest which points to
> D:\Test\Common
Can you do this the other way around? That is, make D:\Test\Common
the junction point, pointing to wherever your svn external is going to
drop the files? And figure out what it is you really want to happen
in the case where you want to check out D:\Test\Projek1 and
D:\Test\Projek2 and they both have the same relationship to
D:\Test\Common but want different revisions to appear there.
--
Les Mikesell
lesmikesell@gmail.com
AW: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by "Humm, Markus" <Ma...@de.ebmpapst.com>.
Hello,
We tried a solution with junctions now (using a sysinternals junction
tool which works under XP already).
Server side in the repository all is well, but in the working copy it
doesn't work as intended as Tortoise SVN
gives us a faliure messaage on our checkin.
What did we do?
We have this structure:
D:\Test\Projekt1
D:\Test\Common
We created a Junction inside D:\Test\Projekt1 named
D:\Test\Projekt1\JunctionTest which points to
D:\Test\Common
so D:\Test\Projekt1\JunctionTest does exist as a hard link. Everything
you insert there
will turn up in D:\Test\Common and vice versa. Works fine with Windows.
Now we created some folders on the server:
/Projekt1/trunc
/Common/trunc
We defined a svn:externals on D:\Test\Projekt1 with these parameters:
Local directory is JunctionTest and URL on the server points to
/Common/trunc
Tortoise SVN accepted that.
We added everything below Projekt1 except JunctionTest to the repository
which worked fine
as the repro browser clearly shows.
We separately added everything from Common to the repository so it went
to /Common/trunc
In the repository (repro browser) we can see now that JunctionTest links
to /Common/trunk
But in the working copy we cannot get this to work. A commit on Projekt1
via Tortoise SVN
doesn't take the externals into account and a update on Projekt1 ends in
a failure message:
(translated from german)
Externals failed d:\Test\Projekt1\JunctionTest
Failure d:\Test\Projekt1\JunctionTest already exists and is no directory
Best regards
Markus Humm
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Mar 2, 2012 at 8:14 AM, Andreas Krey <a....@gmx.de> wrote:
> On Fri, 02 Mar 2012 14:54:38 +0000, Humm, Markus wrote:
> ...
>> In my eyes nothing beats the simplicity and understandability of
>> svn:externals with one single level deep relative paths
>> to a directory above.
>
> Exactly as long as you don't try to do
>
> svn checkout http://your/soft/ware/trunk dir-a
> svn checkout http://your/soft/ware/trunk dir-b
>
> in one and the same directory (namely $HOME, where I do this all the
> time).
>
I got the impression that he wants that to work with a single copy of
his commonlib pulled into the parallel directory like he had checked
it out there separately. But, that misses the point of versioning.
It is common practice for the externals to be tied to specific
branch/tag or peg revisions, and also common in development for one
project to require libs at a different version than another. So,
even if you ignore the danger to non-svn files, the workspaces have to
be self-contained to protect them from each other.
--
Les Mikesell
lesmikesell@gmail.com
Re: Feature request: allow for relative working copy paths in svn:externals definition
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 02 Mar 2012 14:54:38 +0000, Humm, Markus wrote:
...
> In my eyes nothing beats the simplicity and understandability of
> svn:externals with one single level deep relative paths
> to a directory above.
Exactly as long as you don't try to do
svn checkout http://your/soft/ware/trunk dir-a
svn checkout http://your/soft/ware/trunk dir-b
in one and the same directory (namely $HOME, where I do this all the
time).
> Software should adopt as good as possible to the
> existing workflow/structures. There should be no
> need to completely rearrange projects just to get what one wants only
'completely rearrange' is a bit harsh for putting the CommonFiles
external within instead of besides the tree checked out. Besides,
the very idea of letting a checkout/clone create files outside
of the target directory I specified is foreign to all other version
control systems I used so far.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Mar 2, 2012 at 7:54 AM, Humm, Markus
<Ma...@de.ebmpapst.com> wrote:
>>
>> 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.
>
> While I can see your security concerns my intention is to use this
> feature only in conjunction with locally hosted servers
> (same company, same site, all users know each others) and only a single
> hierarchy level deep. I already suggested to limit
> this to a single hierarchy level.
Which would need to permit the external part to do the same to be
useful. So you could keep going up.
>> 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.
>
> Because keeping everything under one tree ties things together wich do
> not have any relation other than via CommonFiles.
Then commit a tree that includes things the way you want. Or if they
really have no relationship, check them out separately.
> In my eyes nothing beats the simplicity and understandability of
> svn:externals with one single level deep relative paths
> to a directory above.
And in my eyes that is insanely dangerous.
> Software should adopt as good as possible to the
> existing workflow/structures. There should be no
> need to completely rearrange projects just to get what one wants only
> because some fear security issues which can be
> turned off with a single global "turn this feature off" switch in the
> client. Those who like can use it, the rest can
> ignore it as the default would be to have it off.
You don't have to re-arrange anything (even if your arrangement
doesn't make any sense...). You just need to commit a project at the
top level that puts your components at the relative positions below
where you want them.
--
Les Mikesell
lesmikesell@gmail.com,
AW: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by "Humm, Markus" <Ma...@de.ebmpapst.com>.
Hello,
>>
>>> > 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.
While I can see your security concerns my intention is to use this
feature only in conjunction with locally hosted servers
(same company, same site, all users know each others) and only a single
hierarchy level deep. I already suggested to limit
this to a single hierarchy level.
>>> > 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.
> 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.
Because keeping everything under one tree ties things together wich do
not have any relation other than via CommonFiles.
In my eyes nothing beats the simplicity and understandability of
svn:externals with one single level deep relative paths
to a directory above. Software should adopt as good as possible to the
existing workflow/structures. There should be no
need to completely rearrange projects just to get what one wants only
because some fear security issues which can be
turned off with a single global "turn this feature off" switch in the
client. Those who like can use it, the rest can
ignore it as the default would be to have it off.
Best regards
Markus Humm
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Mar 2, 2012 at 6:58 AM, Humm, Markus
<Ma...@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@gmail.com
AW: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by "Humm, Markus" <Ma...@de.ebmpapst.com>.
Hello,
> > While it is nice that you have concerns about my security in case I should have to deal with malicious servers,
> > 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.
> There are too many cases where non-root users have access to Subversion repositories for repositories that
> get run by, and manipulated by, the root user. The possibility of escalation attacks for *other* environments seems very large.
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...)
=> I'll request that on the developer mailing list as suggested.
Best regards
Markus Humm
EB-EV
Entwicklung Elektronik
ebm-papst Mulfingen GmbH & Co. KG
Bachmühle 2
74673 Mulfingen
Phone: +49 (7938) 81 531
Fax: +49 (7938) 81 9531
Markus.Humm@de.ebmpapst.com <ma...@de.ebmpapst.com>
http://www.ebmpapst.com <http://www.ebmpapst.com/>
GreenTech - <C:\Tmp\\attc7eb.gif> Ein Zeichen, mit dem wir Zeichen setzen. A symbol that defines standards.
________________________________
Von: Nico Kadel-Garcia [mailto:nkadel@gmail.com]
Gesendet: Freitag, 2. März 2012 13:13
An: Humm, Markus
Cc: Daniel Shahaf; users@subversion.apache.org
Betreff: Re: Feature request: allow for relative working copy paths in svn:externals definition
On Fri, Mar 2, 2012 at 6:13 AM, Humm, Markus <Ma...@de.ebmpapst.com> wrote:
Hello,
thanks for your answer.
While it is nice that you have concerns about my security in case I should have to deal with malicious servers,
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?
There are too many cases where non-root users have access to Subversion repositories for repositories that get run by, and manipulated by, the root user. The possibility of escalation attacks for *other* environments seems very large.
A colleague of mine who uses a similiar directory layout and currently uses CVS and would have to switch when our
SVN rollout happens now claimed that CVS supports this way of working (directory structure). If I'm not mistaken
SVN uses the claim "CVS done right". So it should support this, as this is a legitimate directory structure
And imposes no security problems in secure environments (eg. Our campus LAN with out local SVN server I administer).
Then write your own patch to disable the checks. For general deployment, I think it's begging for escalation attacks.
What do I need to do to get this feature? Where do I need to lobby for it?
I'm an old user, not a core developer, but this would seem to be a good place for general discussion I can see the escalation attacks in a more general environment, myself: I see too many places in environments where I work that an *accidental* such use could cause endless havoc by pre-populating a system directory, such as, say, /etc/nagios.
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Mar 2, 2012 at 6:13 AM, Humm, Markus <Ma...@de.ebmpapst.com>wrote:
> Hello,
>
> thanks for your answer.
>
> While it is nice that you have concerns about my security in case I should
> have to deal with malicious servers,
> 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?
There are too many cases where non-root users have access to Subversion
repositories for repositories that get run by, and manipulated by, the root
user. The possibility of escalation attacks for *other* environments seems
very large.
> A colleague of mine who uses a similiar directory layout and currently
> uses CVS and would have to switch when our
> SVN rollout happens now claimed that CVS supports this way of working
> (directory structure). If I'm not mistaken
> SVN uses the claim "CVS done right". So it should support this, as this is
> a legitimate directory structure
> And imposes no security problems in secure environments (eg. Our campus
> LAN with out local SVN server I administer).
>
Then write your own patch to disable the checks. For general deployment, I
think it's begging for escalation attacks.
What do I need to do to get this feature? Where do I need to lobby for it?
>
I'm an old user, not a core developer, but this would seem to be a good
place for general discussion I can see the escalation attacks in a more
general environment, myself: I see too many places in environments where I
work that an *accidental* such use could cause endless havoc by
pre-populating a system directory, such as, say, /etc/nagios.
AW: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by "Humm, Markus" <Ma...@de.ebmpapst.com>.
Hello,
thanks for your answer.
While it is nice that you have concerns about my security in case I should have to deal with malicious servers,
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.
A colleague of mine who uses a similiar directory layout and currently uses CVS and would have to switch when our
SVN rollout happens now claimed that CVS supports this way of working (directory structure). If I'm not mistaken
SVN uses the claim "CVS done right". So it should support this, as this is a legitimate directory structure
And imposes no security problems in secure environments (eg. Our campus LAN with out local SVN server I administer).
What do I need to do to get this feature? Where do I need to lobby for it?
Best regards
Markus Humm
EB-EV
Entwicklung Elektronik
ebm-papst Mulfingen GmbH & Co. KG
Bachmühle 2
74673 Mulfingen
Phone.: +49 (7938) 81 531
Fax: +49 (7938) 81 9531
mailto: Markus.Humm@de.ebmpapst.com
http://www.ebmpapst.com
GreenTech - Ein Zeichen, mit dem wir Zeichen setzen. A symbol that defines standards.
-----Ursprüngliche Nachricht-----
Von: Daniel Shahaf [mailto:danielsh@elego.de]
Gesendet: Freitag, 2. März 2012 10:23
An: Humm, Markus
Cc: users@subversion.apache.org
Betreff: Re: Feature request: allow for relative working copy paths in svn:externals definition
Stefan Sperling wrote on Thu, Mar 01, 2012 at 17:27:52 +0100:
> On Thu, Mar 01, 2012 at 04:35:32PM +0100, Humm, Markus wrote:
> > In File
> >
> > »D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subver
> > sion\libsvn_wc\wc_db.c«, Zeile 2890: Assert-Anweisung schlug fehl
> > (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
> >
> > The local path of my svn:externals was this:
> > D:/u/svnexternaltest2/gemeinsamme_bibliotheken
> >
> > If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead Tortoise would detect that it contains a .. Or is a absolute path. Obviously either Tortoises or SVN's absolute path detection loginc is not 100% fool proof as well.
>
> Yes, this is a bug. Coincidentally this problem was discussed just today.
> See http://svn.haxx.se/users/archive-2012-03/0012.shtml
The assert is a bug, but the error is not. The code does not permit either absolute paths or paths containing ".." elements for security reasons. (to not allow a malicious server to create files in arbitrary places in the filesystem --- i.e., not under the wc root)
ebm-papst Mulfingen GmbH & Co. KG
Sitz der Gesellschaft: Bachmuehle 2, D-74673 Mulfingen
Kommanditgesellschaft Sitz Mulfingen: Amtsgericht Stuttgart HRA 590344
Komplementaer: Elektrobau Mulfingen GmbH, Sitz Mulfingen, Amtsgericht Stuttgart HRB 590142
Geschaeftsfuehrung: Hans-Jochen Beilke (Vorsitzender), Thomas Borst, Hans Peter Fuchs, Dr. Bruno Lindl, Thomas Wagner
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Daniel Shahaf <da...@elego.de>.
Stefan Sperling wrote on Thu, Mar 01, 2012 at 17:27:52 +0100:
> On Thu, Mar 01, 2012 at 04:35:32PM +0100, Humm, Markus wrote:
> > In File
> > »D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c«,
> > Zeile 2890: Assert-Anweisung schlug fehl
> > (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
> >
> > The local path of my svn:externals was this: D:/u/svnexternaltest2/gemeinsamme_bibliotheken
> >
> > If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead Tortoise would detect that it contains a .. Or is a absolute path. Obviously either Tortoises or SVN's absolute path detection loginc is not 100% fool proof as well.
>
> Yes, this is a bug. Coincidentally this problem was discussed just today.
> See http://svn.haxx.se/users/archive-2012-03/0012.shtml
The assert is a bug, but the error is not. The code does not permit
either absolute paths or paths containing ".." elements for security
reasons. (to not allow a malicious server to create files in arbitrary
places in the filesystem --- i.e., not under the wc root)
Re: Feature request: allow for relative working copy paths in
svn:externals definition
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Mar 01, 2012 at 04:35:32PM +0100, Humm, Markus wrote:
> Hello,
>
> I'm currently learning SVN as we're planning to use it here in the near future.
> Some of our projects are structured like this (MS Windows):
>
> D:\Source\Project1
> D:\Source\Project2
> D:\Source\CommomLibraries
>
> Where Project1 and Project2 are individual projects but both rely on files
> which reside in D:\Source\CommomLibraries and should reside there.
>
> One could try to use svn:externals not to set this up properly so that a
> Checkout of Project1 also checks out CommonLibraries and a update on Project1
> also takes into account the changes you've made to CommonLibraries.
You could use this kind of structure if you make "Source" a working copy
of a folder that has 2 or 3 externals defined that pull in the desired
subfolders.
And there is an alternative to using externals. You can use the
shallow working copy depth feature instead.
Put the folders side-by-side into the repository:
/trunk/Project1
/trunk/Project2
/trunk/CommomLibraries
Then, either check out everything from /trunk, or check out sparse
working copies as follows:
svn co --depth empty URL/trunk Source
cd Source
svn update --set-depth infinity CommomLibraries
svn update --set-depth infinity Project1
or:
svn update --set-depth infinity Project2
This gives you the following working copy layout, with Project1
and Project2 being optionally excluded via depth:
D:\Source\Project1
D:\Source\Project2
D:\Source\CommomLibraries
If you'd like to automate depth configuration during checkout there
is a helper script available at
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py
It would be nice to have this kinf of "view" feature in Subversion's
core so that this would work without an external script.
> I'm using Tortoise SVN 1.7.5 and this one managed to allow me to set up
> svn:externals like I assumed would work. It even commited the structure
> properly to the repository. But when I tried to checkout this project on
> another computer I get a assertion from svn itsself.
>
> In File
> »D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c«,
> Zeile 2890: Assert-Anweisung schlug fehl
> (svn_dirent_is_ancestor(wcroot->abspath, local_abspath))
>
> The local path of my svn:externals was this: D:/u/svnexternaltest2/gemeinsamme_bibliotheken
>
> If I tried to use ../svnexternaltest2/gemeinsamme_bibliotheken instead Tortoise would detect that it contains a .. Or is a absolute path. Obviously either Tortoises or SVN's absolute path detection loginc is not 100% fool proof as well.
Yes, this is a bug. Coincidentally this problem was discussed just today.
See http://svn.haxx.se/users/archive-2012-03/0012.shtml