Svn mergeinfo appearing on sub-directories
Morning, Recently, when any user merges up from trunk to their topic branch, svn appears to do it directory by directory for immediate sub-directories of the branch root, so each sub-directory gets explicit mergeinfo. [X:\XYZ.11650]svn merge http://svn.example.net/ABCD/Source/trunk --- Merging r38851 through r39538 into 'Automation': UAutomation\TestingDashboard\TestingDashboard.sln ... --- Merging r38851 through r39541 into 'Tools': ... Up to around 6 months ago this would not have been noticed, however we have had so many problems with mergeinfo that there is now a hook that prevents mergeinfo going anywhere other than the "branch" roots. The hook is working fine, the problem is that svn is doing this, when there seems to be no apparent reason. I understand that this would happen if the user did not have read access to one of the sub-directories in the source tree, but this is not the case. I have compared a svn ls -R using the file protocol with the same using the http protocol, just to be sure, and there is no difference. It could also happen if the target wc was not at infinite depth, but that's not the case either, nor switched sub-dirs, or anything similar. There is no sub-tree mergeinfo on the trunk. What other problem could be causing this? Cheers, jamie === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===
svn copy (server-side) into existing folder
Hi, I am using svn 1.6.16 on MS Windows. D:\svn copy http://server/svnrepo/trunk/base/install http://server/svnrepo/tags/test_1.0.0 -m test D:\svn copy http://server/svnrepo/trunk/base/install http://server/svnrepo/tags/test_1.0.0 -m test D:\svn copy http://server/svnrepo/trunk/base/install http://server/svnrepo/tags/test_1.0.0 -m test svn: Path 'test_1.0.0/install' already exists I would expect that the second try gives svn: Path 'test_1.0.0' already exists (as in svn 1.5.5) If I create at first the folder it is as expected: D:\svn mkdir http://server/svnrepo/tags/test_1.0.0 -m test D:\svn copy http://server/svnrepo/trunk/base/install http://server/svnrepo/tags/test_1.0.0 -m test D:\svn copy http://server/svnrepo/trunk/base/install http://server/svnrepo/tags/test_1.0.0 -m test svn: Path 'test_1.0.0/install' already exists Hartmut
Re: svn copy (server-side) into existing folder
On Jun 8, 2011, at 04:50, Schroeder, Hartmut wrote: > I am using svn 1.6.16 on MS Windows. > > D:\svn copy http://server/svnrepo/trunk/base/install > http://server/svnrepo/tags/test_1.0.0 -m test This creates tags/test_1.0.0 as a copy of trunk/base/install > D:\svn copy http://server/svnrepo/trunk/base/install > http://server/svnrepo/tags/test_1.0.0 -m test This copies trunk/base/install into tags/test_1.0.0 > D:\svn copy http://server/svnrepo/trunk/base/install > http://server/svnrepo/tags/test_1.0.0 -m test > svn: Path 'test_1.0.0/install' already exists This tries to copy trunk/base/install into tags/test_1.0.0 again but can't because it's already there. This behavior is consistent with the unix cp command and should therefore not be unexpected. > I would expect that the second try gives > svn: Path 'test_1.0.0' already exists > (as in svn 1.5.5) Really? 1.5 behaved differently? That's strange.
RE: Two-Site Subversion Repository Setup Ideas
"Actually, I don't think we know that. The security based refusal to allow electronic communications between the systems will hamper *any* multi-homed development effort. We need to find out the extent of that restriction to give good advice." The restrictions are due to government classification. The code is a classified code and secure communications are not setup between the two sites. Hence the need for transfers via media.
Re: svn copy (server-side) into existing folder
On Wed, 08 Jun 2011 05:16:42 +, Ryan Schmidt wrote:
...
> This behavior is consistent with the unix cp command and should therefore not
> be unexpected.
It is not unexpected, but stupid. As 'svn cp' is also the tool to
create tags, it is rather strange that you can just do
svn cp ${base}/trunk ${base}/tags/1.0.0
(that is, create a tag) twice in a row with any warning whatsoever,
and ending up with an extra 'trunk' dir in the tag.
Has bitten us more than once.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: svn copy (server-side) into existing folder
On Wed, Jun 8, 2011 at 1:01 PM, Andreas Krey wrote:
> On Wed, 08 Jun 2011 05:16:42 +, Ryan Schmidt wrote:
> ...
>> This behavior is consistent with the unix cp command and should therefore
>> not be unexpected.
>
> It is not unexpected, but stupid. As 'svn cp' is also the tool to
> create tags, it is rather strange that you can just do
>
> svn cp ${base}/trunk ${base}/tags/1.0.0
>
> (that is, create a tag) twice in a row with any warning whatsoever,
> and ending up with an extra 'trunk' dir in the tag.
>
> Has bitten us more than once.
To avoid that, you could have a pre-commit hook refuse any commits
inside tags, to make tags really unchangeable things.
--
Johan
Re: Two-Site Subversion Repository Setup Ideas
On Wed, Jun 8, 2011 at 6:23 AM, Randolph, Christian [USA] wrote: > "Actually, I don't think we know that. The security based refusal to allow > electronic communications between the systems will hamper *any* multi-homed > development effort. We need to find out the extent of that restriction to > give good advice." > > The restrictions are due to government classification. The code is a > classified code and secure communications are not setup between the two > sites. Hence the need for transfers via media. Thanks. If media is allowed, you can use git to transfer git working copies from site to site, and do merges from the git repositories. I'd be very concerned about the security of the media, but that's a different kind of problem. Git working copies can also be used, with gitsvn, to merge their differences to whichever backend Subversion repository they can connect tol. Someone will have to do the merges carefully, to avoid conflicts, especially when both sites are working in the same code segments..
Re: svn copy (server-side) into existing folder
On Wed, Jun 8, 2011 at 7:18 AM, Johan Corveleyn wrote:
> On Wed, Jun 8, 2011 at 1:01 PM, Andreas Krey wrote:
>> On Wed, 08 Jun 2011 05:16:42 +, Ryan Schmidt wrote:
>> ...
>>> This behavior is consistent with the unix cp command and should therefore
>>> not be unexpected.
>>
>> It is not unexpected, but stupid. As 'svn cp' is also the tool to
>> create tags, it is rather strange that you can just do
>>
>> svn cp ${base}/trunk ${base}/tags/1.0.0
>>
>> (that is, create a tag) twice in a row with any warning whatsoever,
>> and ending up with an extra 'trunk' dir in the tag.
>>
>> Has bitten us more than once.
>
> To avoid that, you could have a pre-commit hook refuse any commits
> inside tags, to make tags really unchangeable things.
+1 for sanity. Only site admins with local file access or other
authorized permissions should be able to edit tags.
RE: svn copy (server-side) into existing folder
> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: 08 June 2011 13:28
> To: Johan Corveleyn
> Cc: Andreas Krey; Ryan Schmidt; Schroeder, Hartmut;
> users@subversion.apache.org
> Subject: Re: svn copy (server-side) into existing folder
>
> On Wed, Jun 8, 2011 at 7:18 AM, Johan Corveleyn
> wrote:
> > On Wed, Jun 8, 2011 at 1:01 PM, Andreas Krey wrote:
> >> On Wed, 08 Jun 2011 05:16:42 +, Ryan Schmidt wrote:
> >> ...
> >>> This behavior is consistent with the unix cp command and
> should therefore not be unexpected.
> >>
> >> It is not unexpected, but stupid. As 'svn cp' is also the tool to
> >> create tags, it is rather strange that you can just do
> >>
> >> svn cp ${base}/trunk ${base}/tags/1.0.0
> >>
> >> (that is, create a tag) twice in a row with any warning whatsoever,
> >> and ending up with an extra 'trunk' dir in the tag.
> >>
> >> Has bitten us more than once.
> >
> > To avoid that, you could have a pre-commit hook refuse any commits
> > inside tags, to make tags really unchangeable things.
>
> +1 for sanity. Only site admins with local file access or other
> authorized permissions should be able to edit tags.
>
...as this is something I have been meaning to do for a while, can someone
point me to a suitable script for a windoze environment? All the sample
scripts I find seem to be *nix shell scripts...
Many thanks (and apologies for the almost hi-jack)
~ mark c
Re: svn copy (server-side) into existing folder
On Jun 8, 2011, at 14:33 , Cooke, Mark wrote:
>> -Original Message-
>> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
>> Sent: 08 June 2011 13:28
>> To: Johan Corveleyn
>> Cc: Andreas Krey; Ryan Schmidt; Schroeder, Hartmut;
>> users@subversion.apache.org
>> Subject: Re: svn copy (server-side) into existing folder
>>
>> On Wed, Jun 8, 2011 at 7:18 AM, Johan Corveleyn
>> wrote:
>>> On Wed, Jun 8, 2011 at 1:01 PM, Andreas Krey wrote:
On Wed, 08 Jun 2011 05:16:42 +, Ryan Schmidt wrote:
...
> This behavior is consistent with the unix cp command and
>> should therefore not be unexpected.
It is not unexpected, but stupid. As 'svn cp' is also the tool to
create tags, it is rather strange that you can just do
svn cp ${base}/trunk ${base}/tags/1.0.0
(that is, create a tag) twice in a row with any warning whatsoever,
and ending up with an extra 'trunk' dir in the tag.
Has bitten us more than once.
>>>
>>> To avoid that, you could have a pre-commit hook refuse any commits
>>> inside tags, to make tags really unchangeable things.
>>
>> +1 for sanity. Only site admins with local file access or other
>> authorized permissions should be able to edit tags.
>>
> ...as this is something I have been meaning to do for a while, can someone
> point me to a suitable script for a windoze environment? All the sample
> scripts I find seem to be *nix shell scripts...
Try svnperms.py. The trunk version works with 1.6 just fine.
http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/svnperms.py
http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/svnperms.conf.example
The example config file shows how to lock down a tags directory.
You can call svnperms.py with a simple batch file (pre-commit.bat).
[[[
set repos=%1
set txn=%2
set path=%path%;C:\Python26
set path=%path%;C:\Program Files (x86)\<<>>\bin
python %repos%\hooks\svnperms.py -r %repos% -t %txn%
]]]
Regards,
Steve
>
> Many thanks (and apologies for the almost hi-jack)
>
> ~ mark c
--
Stephen Butler | Senior Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
RE: svn copy (server-side) into existing folder
> -Original Message-
> From: Stephen Butler [mailto:sbut...@elego.de]
> Sent: 08 June 2011 13:49
> To: Cooke, Mark
>
> On Jun 8, 2011, at 14:33 , Cooke, Mark wrote:
>
> >> -Original Message-
> >> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> >> Sent: 08 June 2011 13:28
> >> To: Johan Corveleyn
> >> Cc: Andreas Krey; Ryan Schmidt; Schroeder, Hartmut;
> >> users@subversion.apache.org
> >> Subject: Re: svn copy (server-side) into existing folder
> >>
> >> On Wed, Jun 8, 2011 at 7:18 AM, Johan Corveleyn
> >> wrote:
> >>> On Wed, Jun 8, 2011 at 1:01 PM, Andreas Krey
> wrote:
> On Wed, 08 Jun 2011 05:16:42 +, Ryan Schmidt wrote:
> ...
> > This behavior is consistent with the unix cp command and
> >> should therefore not be unexpected.
>
> It is not unexpected, but stupid. As 'svn cp' is also the tool to
> create tags, it is rather strange that you can just do
>
> svn cp ${base}/trunk ${base}/tags/1.0.0
>
> (that is, create a tag) twice in a row with any warning
> whatsoever,
> and ending up with an extra 'trunk' dir in the tag.
>
> Has bitten us more than once.
> >>>
> >>> To avoid that, you could have a pre-commit hook refuse any commits
> >>> inside tags, to make tags really unchangeable things.
> >>
> >> +1 for sanity. Only site admins with local file access or other
> >> authorized permissions should be able to edit tags.
> >>
> > ...as this is something I have been meaning to do for a
> while, can someone point me to a suitable script for a
> windoze environment? All the sample scripts I find seem to
> be *nix shell scripts...
>
> Try svnperms.py. The trunk version works with 1.6 just fine.
>
>
http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/svnp
erms.py
>
http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/svnp
erms.conf.example
>
> The example config file shows how to lock down a tags directory.
> You can call svnperms.py with a simple batch file (pre-commit.bat).
>
> [[[
> set repos=%1
> set txn=%2
>
> set path=%path%;C:\Python26
> set path=%path%;C:\Program Files (x86)\<<>>\bin
>
> python %repos%\hooks\svnperms.py -r %repos% -t %txn%
> ]]]
>
> Regards,
> Steve
>
> >
> > Many thanks (and apologies for the almost hi-jack)
> >
> > ~ mark c
>
Fantastic, thanks very much (again)!
~ mark c
svnsync and hooks on the mirror
Hello all. I tried searching and could not find any answers to this question, but I apologize if this has come up before and I missed it. This is in regard to behavior of an svnsync mirror repository (not the master) in 1.6.11. The mirroring is up and running fine, with commits on the master correctly appearing on the mirror. So my question is this: which hooks on the mirror are expected to execute during the process? The pre-commit hook obviously does since that stops anyone other then the svnsync user from committing, but I am not seeing a peep out of the post-commit hook. I am not sure if it simply does not run or if I have an error I should be running to ground. In our setup it would be nice if the mirror was able to run a few maintenance scripts for each mirrored commit. Thank you for any help that can be passed back along.
hook permissions, visualsvn, windows
I have VisualSVN 2.1.9 running on a Windows Server 2008. I have dumped and loaded a repository from a soon to be retiring Windows Server 2003 machine running VisualSVN 2.1.4. I copied a working hook (post-commit.bat) from the old machine to the new and as far as I can tell, the permissions everywhere are set as they should be. Clearly, however, something is not right because the hook does not run. I get no error message in the VisualSVN Server area of the Event Viewer, so I'm not even sure the hook is firing. The repository is being updated (from Dreamweaver client). The hook file, which is meant to update a checked out version of a web site located where the web server expects it, has the following three lines (not counting comments, also, the last two lines below are one line in the hook): REPOS="$1" REV="$2" "C:\Program Files (x86)\VisualSVN Server\bin\svn" update "$REPOS" D:/websites/wwwsite1 Running the command from the command prompt works so it still could be a permissions thing. However, the VisualSVN user has full permissions to all the repository directories as well as the directory that the hook is meant to update (D:/websites/wwwsite1). Any ideas? -- Henry Hartley
Mixed authentication and WebSVN on same host
Hello everyone! I've been struggling with a configuration problem for a few days and I can't seem to find an acceptable solution. I'll try to explain as clearly as I can! The host I've set up for SVN repositories is svn.eratech.ca. I'd really like to have visual access to my repositories from anywhere, so I've set up WebSVN as well. Here is the configuration for apache's virtual host (which is the only one of my host that's SSL-enabled, if it's relevant): NameVirtualHost *:443 > > ServerAdmin p...@fusi0n.org > ServerName svn.eratech.ca > DocumentRoot /usr/share/websvn > DirectoryIndex wsvn.php index.php > Alias /templates /usr/share/websvn/templates > Alias / /usr/share/websvn/wsvn.php/ > > Options -Indexes +FollowSymlinks +MultiViews > *Satisfy Any > Require valid-user* > AuthType Digest > AuthName "Subversion Repositories" > *AuthUserFile /var/repos/.svnpasswd.htdigest* > AuthDigestDomain / /repos > > > DAV svn > SVNListParentPath on > SVNParentPath /var/repos > *AuthzSVNAccessFile /var/repos/.svnpasswd* > *Satisfy Any > Require valid-user* > AuthType Digest > *AuthDigestDomain / /repos* > AuthName "Subversion Repositories" > *AuthUserFile /var/repos/.svnpasswd.htdigest* > SSLRequireSSL > > ErrorLog /var/www/eratech.ca/svn/logs/error.log > LogLevel warn > CustomLog /var/www/eratech.ca/svn/logs/access.log combined > SSLEngine on > SSLCertificateFile /etc/ssl/svn.eratech.ca.crt > SSLCertificateKeyFile /etc/ssl/svn.eratech.ca.key > SSLCertificateChainFile /etc/ssl/PositiveSSL.ca-bundle > > So, as you can see, I have WebSVN running on / requests and Subversion intercepting the requests made to /repos. The problem I have with that is related to the user authentication. I have read that mixed authentication (anonymous vs "registered") is possible with authz and that's what I tried implementing. However, the problem I'm having now is that Apache does *not* ask users for credentials presumably due to the "Satisfy Any" statement. Unless I am mistaken, that is how Authz work - to grab usernames off Apache's authentication and associate it with the ACL specified in AuthzSVNAccessFile... well, that's not working. I've tried many combinations to no avail... so is there someone who has configured something similar? Thanks for your time!! -- - pL No trees were killed to send this message, but a large number of electrons were terribly inconvenienced.
Re: hook permissions, visualsvn, windows
Henry Hartley wrote: >I have VisualSVN 2.1.9 running on a Windows Server 2008. >[...] >The hook file, which is meant to update a checked out version of a web site >located >where the web server expects it, has the following three lines (not counting >comments, >also, the last two lines below are one line in the hook): > >>REPOS="$1" >>REV="$2" >>"C:\Program Files (x86)\VisualSVN Server\bin\svn" update "$REPOS" >> D:/websites/wwwsite1 that doesn't look like a windows batch file to me. You sure that runs from the windows command line? Doing so on win xp gives me errors about the "REPOS=$1" and "REV=$2" lines. And the when I correct the syntax the call to svn results in svn trying to update $REPOS (literally!) and D:/Websites/wwwsite1 Anyway, the syntax of the update command is: svn up no repository url/path required/allowed. -- Lorenz
