Re: Good strategies for incorporating an external code drop
Am 08.11.2011 21:30, schrieb KARR, DAVID: Subversion works fine when developers have access to the SVN repo. I'm working on a project where one of the developers for one of the projects doesn't have access to our network. When he makes changes he sends me a zip file with the new contents of the project. When I incorporate his changes, I've been going through a somewhat manual process, doing a "diff -cr" between the old and new, copying in files that have changes, copying in new files with "Only in" and deleting files with "Only in". Is there an easier way to do this? There is a section in the docs called "verdor branches", which mentions a script for loading changes from an (unversioned) file tree into a repository, which would make your manual process easier. What it doesn't do is to preserve changes made by other developers, it owerwrites them. That said, there might be a few alternative approaches. Firstly, the developer could send you patches instead of the whole zip folder. He could create these patches using "svn diff" from an SVN working copy. That would require that he can update his working copy now and then though, or that you send him a fresh checkout. This working copy could be the result of merging his latest changes instead of using his version to overwrite everything, so that other peoples' changes are preserved. That said, it is tedious, so patches will tend to contain more than a single change, which makes it more difficult understanding the history afterwards. Also, trying to find that one change in a week's worth of work that broke something is hairy if there are no intermediate steps. For that reason, I would suggest a distributed version control system instead, one where you can create changes offline in separate steps and then sync them when you are connected again. Tools like commit-queue and svk help with that, using Mercury or git you can create bridges, too. I'd try to make SVN access available though, in the long run that is probably the better solution. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: svn version in other format
Am 09.11.2011 07:59, schrieb sureshkumar nandakumar: I need SVN branch all the files along with all the versions in zip or tar format. I Know using svn dump, we can take svn branch all the files along with versions. But it can be read only if we load any SVN repository. Instead of loading the dump files in some other repository, I want to get all the files along with all the version in tar or zip format. If I extract tar or zip file in any location which is not related to SVN, I should find all the files along with all version. Hi! To be honest, I don't understand your description of what you want to do. It would also be better to ask how to achieve something instead of asking for a specific (possibly bad) way to do something. Understanding the goals often helps giving better advices. That said, if I understand you correctly, you want to store zip files and tar files of certain versions (I guess the tags of your code) in the repository. You can do that easily, just put them in there. However, I don't get why you would want to dump/load a repository. If you want to get at older revisions in the repository, you have been missing that this is always possible, just specify the "-r" option for update or checkout. These are basics, btw, so you should really reread the documentation! Cheers! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
RE: svn version in other format
> -Original Message- > From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] > Sent: 09 November 2011 08:43 > To: users@subversion.apache.org > Subject: Re: svn version in other format > > Am 09.11.2011 07:59, schrieb sureshkumar nandakumar: > > I need SVN branch all the files along with all the versions > > in zip or tarformat. > > > > I Know using svn dump, we can take svn branch all the files > > along with versions. > > > > But it can be read only if we load any SVN repository. > > > > Instead of loading the dump files in some other repository, > > I want to get all the files along with all the version in > > tar or zip format. > > > > If I extract tar or zip file in any location which is not > > related to SVN, I should find all the files along with all > > version. > > Hi! > > To be honest, I don't understand your description of what you > want to do. It would also be better to ask how to achieve > something instead of asking for a specific (possibly bad) way > to do something. Understanding the goals often helps giving > better advices. > > That said, if I understand you correctly, you want to store > zip files and tar files of certain versions (I guess the tags > of your code) in the repository. You can do that easily, just > put them in there. I think the OP wants a way to package up the complete history of e.g. a branch in e.g. a zip file and be able to unzip that somewhere outside subversion and still see all the history. Quite why is a mystery. > However, I don't get why you would want to dump/load a > repository. If you want to get at older revisions in the > repository, you have been missing that this is always > possible, just specify the "-r" option for update or > checkout. These are basics, btw, so you should really > reread the documentation! > > Cheers! > > Uli My short answer to the OP is: there is no simple way to do this. It is not something that subversion is designed for. You could do it by hand with quite a lot of effort (writing a script would probably help). Like Uli said, perhaps if you tell us why we might be able to help better. ~ mark c
Re: Subversion repository config problem
"Tony Butt" writes: > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote: >> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100: >> > I tried to edit the log message of a commit made with svn+ssh://, using >> > http:// access, and failed. Now the strange thing, after changing a >> > different commit message for a test (using http:// access only, >> > successsfully), drafting this email, and re-checking the revprops file >> > in question, it was now owned by www-data - the apache user. >> > >> >> We make rev files read only intentionally. I don't remember offhand >> how revprop files would be affected, but in any case those are never >> changed either --- we only ever rename(2) new versions on top of old >> ones. >> >> And, anyway, I really don't understand your bottom line. Are you saying >> the new behaviour is non backwards compatible? That it should be >> changed? Or just that it's surprising? > The new behaviour is slightly different, and slightly incompatible in > our corner case. It was more surprising than anything else, and I wanted > to check that I didn't need to tweak the repository config in some way > to allow for this - possibly some subtlety with umasks that I was not > aware of. The fact that the files are read-only should have no effect on Subversion operations. It should be possible to use svn+ssh and http access simulataneously provided the repository Unix permissions are correct: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.multimethod -- Philip
Re: svn version in other format
Hi Uli, Thanks for your reply. Here I am explain my clarification in details. Our Clients are using Latest SVN in our domain. They are using Red hat Linux & They are accessing svn repository using Tortoise Client. They have multiple branches in SVN repository. Each branches They have around 1000 files. My question is, Apart from dump command, I would like to take tar of SVN branch files along with all the reversions. Why because, we have two version control tools. Subversion is using our Clients and We are using Base Clearcase which was installed in AIX server. We have to merge Subversion braches and tags, whatever changes done by Client, the same changes we needs to be merge with Clearcase. I have read many article like svn2cc,Clearsvn,CM bridge and Git. All saying that it is not possible with AIX server installed Clearcase. And also, we have CollabNet support, I had a call with them, but my bad luck, they are not familiar to advice. I did many follow ups, I didn’t get any proper advice. That’s why I am seeking your advice. If it is possible please guide me, how can get this done. If it is not possible, please lead me any other alternate solution. Please advice to me accordingly………. On Wed, Nov 9, 2011 at 12:29 PM, sureshkumar nandakumar < suresh1256...@gmail.com> wrote: > Hi, > > > I need SVN branch all the files along with all the versions in zip or tar > format. > > I Know using svn dump, we can take svn branch all the files along with > versions. > > > > But it can be read only if we load any SVN repository. > > Instead of loading the dump files in some other repository, I want to get > all the files along with all the version in tar or zip format. > > > > If I extract tar or zip file in any location which is not related to SVN, > I should find all the files along with all version. > > Can anyone please advice to me, how can get this done. > > > Your advice is more useful to me. > > Regards, > N.Suresh > >
[1.7.1] UUID error replacing local file with file external
I have a local file in a WC. I have svn-deleted the local file and re-added it as a file external from elsewhere (to the same WC location using the immediate parent's svn:externals). However, on update I now get an error along the lines of: Updating 'tools': Fetching external item into 'tools/mksrn.pl': svn: warning: W170009: Repository UUID 'a16ec33f-10fa-4864-f3e0-c4d0f3191a87' doesn't match expected UUID 'fc8517da-9189-6699-81a6-a7dc70dab01f' At revision 499. svn: E205011: Failure occurred processing one or more externals definitions [expected UUID is the local repo, the other is the remote one] Annoyingly I tried to re-create this with a dummy/example pair of repos, and it all worked swimmingly. Any ideas as to how I can fix my WC? I'm not scared of a little (but I do mean little) SQL ... NB - real work done via TortoiseSVN on Windows, [working] test attempted on Linux. Update error text above copied from Linux attempt to do same update on broken WC. -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Re: [1.7.1] UUID error replacing local file with file external
Around about 09/11/11 11:39, Neil Bird typed ... Annoyingly I tried to re-create this with a dummy/example pair of repos, and it all worked swimmingly. Actually a typo. meant it wasn't reproducing the situation. The attached script mostly reproduces the problem. I've got my repo. into a state where it simply *won't* pull this file in, from any level under any name. And it's not my WC that's a stuffed, a fresh checkout gives the same error (ditto the attached test). Am I just doing something wrong? -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit svnerr.sh Description: Bourne shell script
Re: [1.7.1] UUID error replacing local file with file external
On 09.11.2011 12:39, Neil Bird wrote: I have a local file in a WC. I have svn-deleted the local file and re-added it as a file external from elsewhere (to the same WC location using the immediate parent's svn:externals). However, on update I now get an error along the lines of: Updating 'tools': Fetching external item into 'tools/mksrn.pl': svn: warning: W170009: Repository UUID 'a16ec33f-10fa-4864-f3e0-c4d0f3191a87' doesn't match expected UUID 'fc8517da-9189-6699-81a6-a7dc70dab01f' Isn't this the expected behaviour regarding the current state of the svn:externals implementation? I am quoting the svnbook here (http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html): File externals cannot refer to files from other repositories. A file external's URL must always be in the same repository as the URL that the file external will be inserted into. Regards Stefan
RE: Good strategies for incorporating an external code drop
-Original Message- From: KARR, DAVID [mailto:dk0...@att.com] Sent: 08 November 2011 20:31 To: users@subversion.apache.org Subject: Good strategies for incorporating an external code drop Subversion works fine when developers have access to the SVN repo. I'm working on a project where one of the developers for one of the projects doesn't have access to our network. When he makes changes he sends me a zip file with the new contents of the project. When I incorporate his changes, I've been going through a somewhat manual process, doing a "diff -cr" between the old and new, copying in files that have changes, copying in new files with "Only in " and deleting files with "Only in ". Is there an easier way to do this? I'd try and change it so he does have access, restricted to just subversion if that's the issue. Then you can use permissions to lock him down to a specific dev branch. Much easier.
Re: [1.7.1] UUID error replacing local file with file external
Neil Bird writes: > Am I just doing something wrong? You are trying to make a file external point to a file in a different repository, that is not supported. -- Philip
Re: [1.7.1] UUID error replacing local file with file external
Around about 09/11/11 14:27, Stefan Podskubka typed ... Isn't this the expected behaviour regarding the current state of the svn:externals implementation? Gah, you are, indeed, correct, and I'd even *read* that before, but forgotten! Thanks (to you & Philip) for correcting my numptiness! -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Dear "Users",
It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
tree conflict when a -reintegrate merge is done back to trunk.
The same merge done with svn 1.6.17 smoothly passes as a normal
deletion.
See below a simple "script" to replicate the bug:
# svn, version 1.7.1 (r1186859)
REPO=${HOME}/TestRepo
svnadmin create $REPO
svn mkdir -m "init" file://$REPO/trunk file://$REPO/branches
svn co file://$REPO wc
touch wc/trunk/file
ln -s file wc/trunk/link
svn add wc/trunk/file wc/trunk/link
svn ci -m "link" wc
svn cp -m "branch 1.0" file://$REPO/trunk file://$REPO/branches/1.0
svn up wc
svn rm wc/branches/1.0/link
svn ci -m "rm link" wc
svn merge --reintegrate ^/branches/1.0 wc/trunk
--- Merging differences between repository URLs into 'wc/trunk':
C wc/trunk/link
--- Recording mergeinfo for merge between repository URLs into
'wc/trunk':
U wc/trunk
Summary of conflicts:
Tree conflicts: 1
The same when executed with svn, version 1.6.17 (r1128011)
#Only the last command differs
svn merge --reintegrate ^/branches/1.0 wc/trunk
--- Merging differences between repository URLs into 'wc/trunk':
Dwc/trunk/link
Is this really a bug? Or am I doing something wrong?
Regards
Christian Asmussen
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
RE: Error when updating
Thanks, Philip. Looking forward to it. Now it takes me quite some extra time to work with SVN. -Wabe > From: philip.mar...@wandisco.com > To: wabekoelm...@hotmail.com > CC: users@subversion.apache.org > Subject: Re: Error when updating > Date: Thu, 3 Nov 2011 16:09:58 + > > Wabe W writes: > > > So, we just have to update the server and see if the problem is solved? > > It's issue 4048, it may get fixed in a 1.7.x release: > http://subversion.tigris.org/issues/show_bug.cgi?id=4048 > > -- > Philip
Re: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
On Wed, Nov 09, 2011 at 04:13:56PM +0100, christian.asmus...@ubs.com wrote:
> Dear "Users",
>
>
>
> It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
> tree conflict when a -reintegrate merge is done back to trunk.
>
> The same merge done with svn 1.6.17 smoothly passes as a normal
> deletion.
>
>
>
> See below a simple "script" to replicate the bug:
>
>
>
> # svn, version 1.7.1 (r1186859)
>
> REPO=${HOME}/TestRepo
>
> svnadmin create $REPO
>
> svn mkdir -m "init" file://$REPO/trunk file://$REPO/branches
>
> svn co file://$REPO wc
>
> touch wc/trunk/file
>
> ln -s file wc/trunk/link
>
> svn add wc/trunk/file wc/trunk/link
>
> svn ci -m "link" wc
>
> svn cp -m "branch 1.0" file://$REPO/trunk file://$REPO/branches/1.0
>
> svn up wc
>
> svn rm wc/branches/1.0/link
>
> svn ci -m "rm link" wc
>
> svn merge --reintegrate ^/branches/1.0 wc/trunk
>
> --- Merging differences between repository URLs into 'wc/trunk':
>
>C wc/trunk/link
>
> --- Recording mergeinfo for merge between repository URLs into
> 'wc/trunk':
>
> U wc/trunk
>
> Summary of conflicts:
>
> Tree conflicts: 1
>
>
>
> The same when executed with svn, version 1.6.17 (r1128011)
>
> #Only the last command differs
>
> svn merge --reintegrate ^/branches/1.0 wc/trunk
>
> --- Merging differences between repository URLs into 'wc/trunk':
>
> Dwc/trunk/link
>
>
>
> Is this really a bug? Or am I doing something wrong?
>
>
>
> Regards
>
> Christian Asmussen
Thanks very much. Yes, this is a bug and I can reproduce it with
the current trunk code.
Can you file an issue in our tracker so this doesn't fall through the
cracks? See http://subversion.apache.org/issue-tracker.html Cheers!
RE: 1.7.1 working copies - verification
-Original Message- From: Markus Schaber [mailto:m.scha...@3s-software.com] Sent: Tuesday, November 08, 2011 1:40 AM To: Floeder, Joe; users@subversion.apache.org Subject: AW: 1.7.1 working copies - verification Hi, Joe, Von: joe.floe...@sungard.com [mailto:joe.floe...@sungard.com] > How do know I have a 1.7.1 working copy? Can I tell by looking at the > working copy on the file system? The older version had .svn directories and > the entries file. What does the new working copy look like? Normally, 1.7 working copies only have .svn directories in the top level of the working copy. (Externals and nested WCs are different cases.) This should be enough for a first-glance 1.7.X vs. 1.0.X-1.6.X disambiguation. > We are running 1.7.1 and 1.6.17 on two different servers - right now I am not > sure I am connecting to the correct svnserve process. As both the 1.6.X and 1.7.X clients can connect to both 1.6.X and 1.7.X servers, and the server repository format did not change between 1.6.X and 1.7.X, so I'm not sure which problem you want to describe me with that sentence. Markus Hi Markus Daniel Scahaf answered my question on an earlier reply saying "look for **/.svn/wc.db." Now I see that 1.7.1 working copies only have one .svn folder and the sqlite database file wc.db is in that folder. After I realized this, I discovered that we were sourcing in a path to an older version of svn in our unix shell script 'wrappers'. I changed the environment variable assignment to version 1.7.1 and now I get the newer version of the working copy. Thanks. Joe
RE: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic links
Issue created http://subversion.tigris.org/issues/show_bug.cgi?id=4052
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 09 November 2011 17:57
To: Asmussen, Christian
Cc: users@subversion.apache.org
Subject: Re: Bug (svn 1.7.1) with reintegrate merge and deleted symbolic
links
On Wed, Nov 09, 2011 at 04:13:56PM +0100, christian.asmus...@ubs.com
wrote:
> Dear "Users",
>
>
>
> It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
> tree conflict when a -reintegrate merge is done back to trunk.
>
> The same merge done with svn 1.6.17 smoothly passes as a normal
> deletion.
>
>
>
> See below a simple "script" to replicate the bug:
>
>
>
> # svn, version 1.7.1 (r1186859)
>
> REPO=${HOME}/TestRepo
>
> svnadmin create $REPO
>
> svn mkdir -m "init" file://$REPO/trunk file://$REPO/branches
>
> svn co file://$REPO wc
>
> touch wc/trunk/file
>
> ln -s file wc/trunk/link
>
> svn add wc/trunk/file wc/trunk/link
>
> svn ci -m "link" wc
>
> svn cp -m "branch 1.0" file://$REPO/trunk file://$REPO/branches/1.0
>
> svn up wc
>
> svn rm wc/branches/1.0/link
>
> svn ci -m "rm link" wc
>
> svn merge --reintegrate ^/branches/1.0 wc/trunk
>
> --- Merging differences between repository URLs into 'wc/trunk':
>
>C wc/trunk/link
>
> --- Recording mergeinfo for merge between repository URLs into
> 'wc/trunk':
>
> U wc/trunk
>
> Summary of conflicts:
>
> Tree conflicts: 1
>
>
>
> The same when executed with svn, version 1.6.17 (r1128011)
>
> #Only the last command differs
>
> svn merge --reintegrate ^/branches/1.0 wc/trunk
>
> --- Merging differences between repository URLs into 'wc/trunk':
>
> Dwc/trunk/link
>
>
>
> Is this really a bug? Or am I doing something wrong?
>
>
>
> Regards
>
> Christian Asmussen
Thanks very much. Yes, this is a bug and I can reproduce it with the
current trunk code.
Can you file an issue in our tracker so this doesn't fall through the
cracks? See http://subversion.apache.org/issue-tracker.html Cheers!
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
merge problem. impossible to revert deleted file
Hi, Think I found a problem with svn 1.7.1 on Windows, where after a merge and a tree conflict (annoying, since both dirs have same name), I ended up with a file with status deleted (for unknown reason), and it seems impossible to revert (undelete) this file. I made a batch script where I believe I managed to reproduce the problem: ---start script--- REM change this to the dir you are running the script from set wd=c:/temp/test svnadmin create repo svn mkdir file:///%wd%/repo/trunk -m test svn co file:///%wd%/repo/trunk trunk1 svn co file:///%wd%/repo/trunk trunk2 svn copy trunk1 file:///%wd%/repo/branch -m branch svn co file:///%wd%/repo/branch branch pushd branch md dir1 pushd dir1 echo > file2.txt popd svn add * svn commit -m test popd pushd trunk1 svn update md dir1 pushd dir1 echo > file1.txt popd svn add * svn commit -m test popd pushd trunk2 svn merge file:///%wd%/repo/branch@4 REM tree conflict svn resolve --accept=working dir1 svn up REM Updating '.': REMA dir1\file1.txt REM It says dir1\file1.txt is added, but it's nowhere to be seen dir dir1 svn status dir1 svn resolve --accept=working dir1 svn revert dir1\file1.txt REM Nope, file is still deleted. Impossible to undelete it. popd popd ---end script--- Another small issue: svn merge don't seem to like backslash in file urls: C:\temp\test\trunk2>svn merge file:///C:\temp\test\trunk2/repo/branch@4 svn: E180001: Unable to connect to a repository at URL 'file:///C:%5Ctemp%5Ctest %5Ctrunk2/repo/branch' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file:///C:%5Ctemp%5Ctest%5Ctrunk2/repo/ branch' Otoh, svn co and svn mkdir etc. seems to work with backslash in file urls. thanks, Gunnar Dalsnes
Re: Subversion repository config problem
On Wed, 2011-11-09 at 10:00 +, Philip Martin wrote: > "Tony Butt" writes: > > > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote: > >> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100: > >> > I tried to edit the log message of a commit made with svn+ssh://, using > >> > http:// access, and failed. Now the strange thing, after changing a > >> > different commit message for a test (using http:// access only, > >> > successsfully), drafting this email, and re-checking the revprops file > >> > in question, it was now owned by www-data - the apache user. > >> > > >> > >> We make rev files read only intentionally. I don't remember offhand > >> how revprop files would be affected, but in any case those are never > >> changed either --- we only ever rename(2) new versions on top of old > >> ones. > >> > >> And, anyway, I really don't understand your bottom line. Are you saying > >> the new behaviour is non backwards compatible? That it should be > >> changed? Or just that it's surprising? > > The new behaviour is slightly different, and slightly incompatible in > > our corner case. It was more surprising than anything else, and I wanted > > to check that I didn't need to tweak the repository config in some way > > to allow for this - possibly some subtlety with umasks that I was not > > aware of. > > The fact that the files are read-only should have no effect on > Subversion operations. It should be possible to use svn+ssh and http > access simulataneously provided the repository Unix permissions are > correct: > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.multimethod > I have configured the repository permissions and wrapper script as outlined in the aubversion 1.6 reference. I just checked, and that is essentially unchanged in the current 17. manual. I also rechecked my config - * group set to svn throughout * group write permissions set wherever there are owner write permissions * setgid bit set on the relevant directories to preserve group ownerships correctly I tried the command line propedit this morning to set the log message, and found some more useful information returned. The short story is that there is NOT a subversion problem, but rather 2 problems with some of my hooks. The first problem is that the hooks log information to files in /tmp, which did not have the correct group set. This was causing my initial symptoms. The second problem is that we run trac, and (as recommended by the trac project) use post-commit hooks to log repository changes into the trac timeline. This fails when svn+ssh:// is used, as the process owner does not have permission to use trac-admin in that way. Thanks for your responses, and my apologies for the noise! Tony Butt CEA Technologies
Unable to delete directory in repository, server version 1.7.1
Hello! Can you delete directories in your subversion repository? Yes, really? You lucky bas! Joke:) Anyway, joke aside, the following is no laughing matter. It seems that upgrade from 1.6.17 to 1.7.1 exhibits some "undocumented features":) Apparently server version 1.7 parses permissions differently than 1.6, namely it does not allow me to delete directories I have write access to. This is my authz file: - [/project] user1 = r [/project/sys] user1 = rw - This seems to give user1 the read permissions to /project/* dir and rw permission for /project/sys, right? Let's see. As user1, I can do this: svn mkdir svn://server.org/project/sys/dir Then I can create /project/sys/dir/a file, and remove that file, commiting every step successfully to the repo. What I CAN NOT DO is remove (empty!) directory that I have just created: # svn rm svn://server.org/project/sys/dir svn: Access denied If I change authz file to only this (remove read-only permission to upper path): - [/project/sys] user1 = rw - then I can delete the directory I have created. To summarize: It seems that subversion parses and merges repository/path permissions correctly for following operations: checkout, commit-to-add-dir, commit-add-file, commit-to-delete-file. Operation commit-to-delete-dir does not seem to follow the same pattern. Has anybody experienced similar behaviour? Can someone confirm this bug? Or explain this feature? :) SVN version is 1.7.1 (both client and server) b.
RE: Subversion repository config problem
> The second problem is that we run trac, and (as recommended > by the trac project) use post-commit hooks to log repository > changes into the trac timeline. This fails when svn+ssh:// > is used, as the process owner does not have permission to > use trac-admin in that way. ...as a trac user (but being a windoze shop, not svn+ssh) I was wondering, is this a fundamental trac problem or a local configuration issue? If it is trac then it should be reported to trac-users too... ~ mark c
RE: Subversion repository config problem
On Thu, 2011-11-10 at 06:59 +, Cooke, Mark wrote: > > > The second problem is that we run trac, and (as recommended > > by the trac project) use post-commit hooks to log repository > > changes into the trac timeline. This fails when svn+ssh:// > > is used, as the process owner does not have permission to > > use trac-admin in that way. > > ...as a trac user (but being a windoze shop, not svn+ssh) I was wondering, is > this a fundamental trac problem or a local configuration issue? If it is > trac then it should be reported to trac-users too... Normally your svn+ssh process runs as the user who's credentials were supplied. Trac-admin does not allow general users to do much of anything on a linux box, not sure about windows. I would say it was a fundamental trac problem, resulting from a collision of 2 sets of assumptions for security. That is, svnserve will run as a local, authenticated user for security, audit trail, etc. trac-admin will only update the timeline (or make any other change) if it is superuser (or somesuch). There might be a way to configure trac-admin to allow anyone to make those changes, but that exposes the trac installation to greater risk. Sigh - I will just strongly suggets to our engineers that they use http:// protocol only, most do already. Tony > > ~ mark c
