RE: How do I enforce a minimum client version when hosted via httpd
Hi, Stephen Connolly wrote: > I remember reading before about a hack/trick that allows you > to ensure that the client is at least mergeinfo aware when the > repository is served via Apache httpd. You can have a start-commit hook. It can reject commits from clients that don't have the "mergeinfo" capability. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html > A better trick would allow blocking clients less than 1.6.13 from connecting ;-) Subversion sends it's version in the User-Agent string. You can test that in your Apache config file. (But this is probably a bad idea unless it's an internal SVN server that's locked down by corporate policy). http://httpd.apache.org/docs/2.2/howto/access.html#env Bear in mind that some people may not be using the official Subversion client. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Path based authorization
Hi, Robert Johnson wrote: > I'm not sure this is a bug or the documentation is wrong, > or I'm misunderstanding the concept. > > In the SVN doc: > > Section 6.5 Path-Based Authorization > > [paint:/projects/paint] > > jane = r > > @paint-developers = rw > > > > Another important fact is that the first matching rule > > is the one which gets applied to a user. In the prior > > example, even though Jane is a member of the paint-developers > > group (which has read/write access), the jane = r rule > > will be discovered and matched before the group rule, > > thus denying Jane write access. Older versions of the SVN book were wrong. The latest version has corrected this. See: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h tml Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SVN Keywords...
http://subversion.apache.org/faq.html#version-value-in-source Kind regards, Jon -Original Message- From: BRM [mailto:bm_witn...@yahoo.com] Sent: 26 October 2010 20:56 To: SubVersion Users Subject: SVN Keywords... I have a series of projects that operate as service daemons; all the projects have a simple main.cpp that loads another class that does the actual work. So I never have to touch main.cpp except when I go to make a release, and then only to update a couple things: version numbers and dates. I'd like to try to automate the data modifications a little bit more; and while SVN has the $Date$ keyword, aka $LastChangedDate$; that's not quite correct for what I want to do - svn after, all svn won't detect a change if there are no actual modifications on the file (e.g. "touch somefile.cpp" won't result in a delta in svn), at least as explained in the svn red book[1]. Would it be possible to have a $LastCommitDate$, and perhaps a $LastCommitRevision$ that is not file specific but name space specific, since SVN operates on name spaces (e.g. ^/some/svn/path) instead of files ( ^/some/svn/path/some.file.with.extension)? Or perhaps $LastUrlCommit...$. In either case the specified name space should likely be the URL/namespace where the file is located, perhaps with an option to have the base URL when it was checked out/exported. This could be provided using arrays, for example $LastCommitDate[0]$ could be the base URL while $LastCommitDate[1]$ is the URL of the file. For the svn:externals use-case, the URL would be related to the external, not to the project pulling the URL in. So suppose the following: Project located at /myproject/trunk, pulls in an svn:external from /myotherproject/tags as lib1; the proposed keyword set would apply to /myproject/trunk only for files that actually exist in the repository under that URL, while the proposed keywords for the files checked out/exported to lib1, which are located under /myotherproject/tags, would apply the URL of the external - /myotherproject/tags and not /myproject/trunk. While I understand the logic present in the $GlobaRevision$ section on in the SVN Redbook[1], there is also some problems with the suggested resolution when trying to do the same thing on multiple platforms, namely and especially MS Windows where processing of 'svnversion' output is impossible with standard tools on the platform to say the least. Ben [1]http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.key words.html __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Revisions not in chronological order
Giulio Troccoli wrote: >> From: Chris Evans [mailto:chris.ev...@gresearch.co.uk] >> My repository is made up of a load of folder loaded from >> cvs2svn dumps. >> These were loaded individually and have overlapping date ranges. >> When doing an "svn load" it looks like SVN assigns each >> commit to the next revision, regardless of the date the >> commit occurred. >> >> As a result the rage of revisions created for each of the >> loads have overlapping dates and the revisions of the >> repository are not chronological. > >This is expected behaviour if have loaded two or more dumps into the same repository. > >I seem to remember there is a tool out there to merge dumps >file, but I don't remember the name. I don't even know if >it would merge them in chronological order or not. Google >it and see what you can find. http://svn.borg.ch/svndumptool/ Haven't tried it myself, but it claims to do what you want. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Tree conflict: Add/Add on directory
Hi,
I'm having trouble resolving a tree conflict.
I'm working on a feature branch, and I regularly merge from trunk to the
branch. In my latest merge, I got a tree conflict because a directory
("playback") has been added both to trunk and to my branch, with
different contents. I want to get rid of my version and use the one
from trunk.
This should be trivial, but it isn't:
$ svn resolve --accept theirs-full playback
svn: warning: Tree conflicts can only be resolved to 'working' state;
'playback' not resolved
So I thought I'd delete the directory and use "svn cp" to copy the
branch version into my working copy. The delete worked:
$ svn st --depth=empty playback
D C playback
> local add, incoming add upon merge
And I can easily get the URL I need to copy from:
$ svn info playback
URL: http://svnserver/repos/branches/feature/wherever/playback
...
Tree conflict: local add, incoming add upon merge
Source left: (dir)
http://svnserver/repos/trunk/wherever/playback@2373
Source right: (dir)
http://svnserver/repos/trunk/wherever/playback@3515
But the copy doesn't work:
$ svn cp http://svnserver/repos/trunk/wherever/playback@3515 .
svn: Path 'playback' already exists
(I also tried "svn cp
http://svnserver/repos/trunk/wherever/playback@3515 playback", but that
put it in the wrong place (playback/playback/ rather than just
playback/) and seemed to get my working copy in a bugged state,
requiring non-SVN "rm" and "svn cleanup" to get it working again).
I guess I could split the commit into two - if I did a first commit for
the rest of the merge and to delete the "playback" directory, I'd
probably be able to use "svn cp" and do a second commit to re-add it
with the right contents. This seems like a very ugly hack.
Any ideas how to resolve this properly?
Kind regards,
Jon
**
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: restricting sub-directory permissions
Hi, Gabriel Ricardo wrote: > I cannot figure out how to restrict permissions on a sub-directory. > What I want is to have anonymous read/write access to everything > except a sub-directory, where only two users have read/write and > everyone else has no access (read or write). I've done a lot of This looks relevant: http://blogs.open.collab.net/svn/2007/03/authz_and_anon_.html >> Since anonymous users can checkout the tree, Apache never bothers >> to query you for authentication credentials. And you can't force >> Subversion to transmit authentication credentials when Apache >> hasn't asked for them. There are workarounds documented in the blog post. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: sync bug -> corrupted proxy repo
Hi, Andersen, Krista [mailto:krista.ander...@itg.com] wrote: > Twice I have seen one of my proxy repositories become corrupted due > to an apparent bug in the svnsync sync process. Has anyone else > seen this type of behavior from Subversion? This is probably caused by issue 3546 [1][2]. This is a race condition - if you have several sync processes running at the same time then the mirror can get corrupted. You had three commits which were 1 second apart, so your hook script started 3 copies of svnsync within 2 seconds. I think this is the first practical report of this bug; previous discussion was theoretical. > Here is a comparison the output of the svn log -v for the offending > revisions (324,325) on both the corrupted and non-corrupted proxy > repo. It looks like rev 323 got mirrored twice (as mirror revs 323 and 324), then rev 324 was mirrored (as mirror rev 325). > I am a bit concerned about the stability of Subversion since this > is the second time in two months that I have had to fix this issue. > Is there a patch or something to prevent this in the future? Suggested workaround: Change your hook scripts to use the lockf or lockfile tools[3] to ensure that only one instance of svnsync runs at once. Kind regards, Jon [1] http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3C2 0091127115356.gc9...@jack.stsp.name%3e [2] http://subversion.tigris.org/issues/show_bug.cgi?id=3546 [3] http://mail-archives.apache.org/mod_mbox/subversion-dev/200911.mbox/%3C2 0091127132659.ge9...@jack.stsp.name%3e ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: malformed file problem -- version 1.5.7
Hi, James D. Parra [mailto:jam...@musicreports.com] wrote: > Is there a way that I can repair this? No idea, sorry. But: > Is there a way to roll back to revision 11529 and start there? Try svnadmin dump with the -r parameter to dump just the revisions you want to keep, then svnadmin load to load them into a new repository. Any checkouts of r11529 or earlier should be OK; if you have a later checkout then you'll need to delete it and re-checkout. > Should I remove all the revision number files greater that 11529 Hand-editing the repository sounds like a bad idea*... you might get rid of this corruption but introduce a different corruption. Using dump/load should give you a valid repository. Kind regards, Jon [*] It's number zero on the "Subversion Worst Practices" guide: http://www.red-bean.com/fitz/presentations/2007-07-27-OSCON-svn-worst-pr actices.pdf ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: sync bug -> corrupted proxy repo
Hi, Ryan Schmidt wrote: > But Subversion blocks the commit until the post-commit is done. That particular SVN client will be blocked. But if you have two users committing at the same time, or if a user runs "svn" twice in parallel, then the post-commit hook will be run in parallel. Here's how I tested this. I created a new repository with a post-commit hook that takes 30 seconds to run. I then checked that it works, and that a normal commit took 30 seconds. I then did two commits in parallel, and that took 30 seconds. This shows that the post-commit hook is running in parallel - if it had been run in series, then it would have taken 60 seconds for 2 commits. (I also checked the output of "ps" and observed the two "post-commit" processes running). ~$ mkdir svnscratch ~$ cd svnscratch/ ~/svnscratch$ svn --version | head -n1 svn, version 1.6.8 (dev build) ~/svnscratch$ svnadmin create repo ~/svnscratch$ cat >repo/hooks/post-commit #! /bin/bash sleep 30 ~/svnscratch$ chmod a+x repo/hooks/post-commit ~/svnscratch$ time repo/hooks/post-commit real0m30.004s user0m0.000s sys 0m0.008s ~/svnscratch$ time svn mkdir -m "Test" file://`pwd`/repo/trunk Committed revision 1. real0m30.030s user0m0.008s sys 0m0.008s ~/svnscratch$ time ( svn mkdir -m "Test" file://`pwd`/repo/branches & svn mkdir -m "Test" file://`pwd`/repo/tags ) Committed revision 2. Committed revision 3. real0m30.069s user0m0.004s sys 0m0.020s ~/svnscratch$ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: sync bug -> corrupted proxy repo
Hi, > I am assuming that if the commits must start at least one > second apart - then the sync from the post-commit hook > would not be able to reach a race condition. > Is this a reasonable assumption? No, the bug is worse than that. Suppose there are 3 commits: - At time 12:00:00, a commit starts sync process #1. The sync takes 6 seconds. - At time 12:00:02, a commit starts sync process #2. This blocks due to sync process #1's lock. - At time 12:00:04, a commit starts sync process #3. This blocks due to sync process #1's lock. - At time 12:00:06, sync process #1 finishes. Sync processes #2 and #3 both try to take the lock; due to the bug they may _both_ succeed in taking the lock. Chaos ensues. I suggest you use the "flock(1)" tool. [1]. This is installed as a standard part of Debian (it's in the util-linux package). Something like this, in your post-commit hook: --- cut here - start --- #!/bin/sh /usr/bin/flock --wait 1200 \ -x /var/lock/svn_sync_lock \ /usr/local/bin/svnsync sync --non-interactive \ http://mirrorserver.example.com/svn & --- cut here - end --- You will need to make the /var/lock/svn_sync_lock file and ensure it's writable by the user your post-commit hook is running as. "flock" is a mature, tested piece of code to handle locking. It will ensure that only one copy of svnsync is running at a time. That way, the race condition in svnsync is avoided. Kind regards, Jon [1] http://www.google.co.uk/search?q=man+flock%281%29 -Original Message- From: Andersen, Krista [mailto:krista.ander...@itg.com] Sent: 15 January 2010 22:29 To: Jon Foster; users@subversion.apache.org Cc: ssi-svn_admin Subject: RE: sync bug -> corrupted proxy repo Thank you Jon, for your explanation and workaround. Are there any "best practices" that we can advise our dev groups to follow to avoid this problem? Otherwise, your suggestions seem to indicate I would have to run the sync on a cronjob and not with the hook script. That is something we would like to avoid. So I have added a start time comparison and sleep in a start-commit hook instead. Do you see any reason why this would cause other problems? I am assuming that if the commits must start at least one second apart - then the sync from the post-commit hook would not be able to reach a race condition. Is this a reasonable assumption? #!/usr/bin/sh # START-COMMIT HOOK # kanderse Jan 13, 2010 # The start-commit hook is invoked before a Subversion txn is created # in the process of doing a commit. # This script checks the start time and compares with the start time # of the previous commit. It will cause a commit to wait one second if # the last commit was started less than one second earlier. # The purpose of this wait is to prevent known issue 3546 [1][2]. # a race condition involving multiple sync processes running at # the same time that result in a corrupted proxy. REPOS="$1" USER="$2" DATE1=`cat /$REPOS/hooks/start-time.txt` # previous start time DATE2=`/usr/local/bin/date +%s` # record current start time echo $DATE2 > /$REPOS/hooks/start-time.txt # echo $DATE2 $DATE1 `expr $DATE2 - $DATE1` if [ `expr $DATE2 - $DATE1` -lt 1 ] then sleep 1 # to prevent sync race that results in sync duplication and corrupted proxy fi # All checks passed, so allow the commit. exit 0 Krista Andersen Global Development Infrastructure Investment Technology Group, Inc. 400 Corporate Pointe, 8th Floor Culver City, CA 90230 Direct: 213.270.7570 -Original Message- From: Jon Foster [mailto:jon.fos...@cabot.co.uk] Sent: Wednesday, January 13, 2010 5:13 AM To: Andersen, Krista; users@subversion.apache.org Cc: ssi-svn_admin Subject: RE: sync bug -> corrupted proxy repo Hi, Andersen, Krista [mailto:krista.ander...@itg.com] wrote: > Twice I have seen one of my proxy repositories become corrupted due > to an apparent bug in the svnsync sync process. Has anyone else > seen this type of behavior from Subversion? This is probably caused by issue 3546 [1][2]. This is a race condition - if you have several sync processes running at the same time then the mirror can get corrupted. You had three commits which were 1 second apart, so your hook script started 3 copies of svnsync within 2 seconds. I think this is the first practical report of this bug; previous discussion was theoretical. > Here is a comparison the output of the svn log -v for the offending > revisions (324,325) on both the corrupted and non-corrupted proxy > repo. It looks like rev 323 got mirrored twice (as mirror revs 323 and 324), then rev 324 was mirrored (as mirror rev 325). > I am a bit concerned about the stability of Subversion since this > is the second time in two months that I have had to fix this issue. > Is there a patch or something to prevent this in the future? Suggested workaround: Change your hook s
RE: subversion-1.6.9 build error [reproducible]
Hi, ^M is CR. Given the output of "cat", it looks like the file contained: > > > /* This file is automatically generated from > > > * subversion/libsvn_fs_fs/rep-cache-db.sql > > > * Do not edit it directly, but edit the source file and rerun 'make' > > > */ > > > > > > #define REP_CACHE_DB_SQL \ > > > "^M "\ > > > "pragma auto_vacuum = 1;^M "\ > > > "^M "\ > > > "^M "\ > > > "create table rep_cache (hash text not null primary key,^M "\ > > > "revision integer not null,^M "\ > > > "offset integer not null,^M "\ > > > "size integer not null,^M "\ > > > "expanded_size integer not null);^M "\ > > > "" If the compiler is tolerant of dodgy line breaks*, and accepts a bare CR as a Mac-style line break, then the file is invalid C. This is because it starts: > #define REP_CACHE_DB_SQL \ > " (Note that the #define ends here) > "\ > "pragma auto_vacuum = 1; > "\ etc. This is consistent with the compiler error messages. Does subversion/libsvn_fs_fs/rep-cache-db.sql have Windows style CR-LF line breaks? And does the Python script that reads it assume it has native (UNIX style) line breaks? ... Ok, I've just managed to reproduce this and confirmed my speculation above. Reproduction recipe: On Linux: > > > > 1. Get the source code subversion-1.6.9; Using the ZIP file, not the tar.gz. > > > > 2. Run 'autogensh' without error; > > > > 3. Run 'configure' without error; > > > > 4. Run 'make' with below error: Jiang: The ZIP file is only intended for building on Windows. If you're building on Linux, you should use the TAR.GZ or TAR.BZ2 files. (They are subtly different, and that difference caused the build error). Kind regards, Jon (* Such tolerance is usually a good thing; e.g. if I use Pythonwin to edit a file, it leaves existing UNIX-style line breaks alone but any new line breaks will be Windows style). -Original Message- From: Hyrum K. Wright [mailto:hyrum_wri...@mail.utexas.edu] Sent: 26 January 2010 06:58 To: Jiang Li Cc: users@subversion.apache.org Subject: Re: subversion-1.6.9 build error Glad to hear that you finally got it working. Was the problem the ^M characters? If so, I wonder if it is specific to your platform, or more general. But the entire episode does make me wonder why we require people building to generate these files locally. I'll take a look at the pre-build system and see what I can find out. -Hyrum On Jan 25, 2010, at 5:27 PM, Jiang Li wrote: > Hi Hyrum, > > You are an expert, I am able to compile v1.6.9 successfully. > > Here is my update. > > 1. I tried again by downloading subversion-deps-1.6.9 and compiled again, but with the same problem. > 2. I double check the file subversion/libsvn_fs_fs/rep-cache-db.h with 'vi' editor, I found that there are extra '^M' characters in this file. Using 'cat' will not show this. So this is the problem caused by auto-generation. I removed the extra '^M', then run 'make', it works. > > Thanks again! > Jiang Li > > > > > 2010/1/25 Jiang Li > Hyrum, > > Thanks! Tomorrow I will download Subversion 1.6.9 dependency package for a try. > > I suspect the problem was caused by not using that package. I will update you the result. > > I will go offline now. Thanks again for your help! > > > Jiang Li > > 2010/1/25 Hyrum K. Wright > > On Jan 25, 2010, at 8:55 AM, Jiang Li wrote: > > > Hyrum, > > > > No luck. The file will be re-generated again after running 'make'. > > As it should be. > > > 2010/1/25 Hyrum K. Wright > > Can you try just removing the file and then running 'make' again? > > > > On Jan 25, 2010, at 8:48 AM, Jiang Li wrote: > > > > > Hi Hyrum, > > > > > > Thank you so much for your quick reply! > > > > > > Here is all the content of file subversion/libsvn_fs_fs/rep-cache-db.h. > > > > > > Just for your information, I just downloaded subversion 1.6.6 and I was able to compile this version successfully. I am fine with v1.6.6, but I will try to compile 1.6.9 tomorrow for a last try. This is late in my evening. I appreciate your any suggestion. > > > > > > > > > $ cat rep-cache-db.h > > > /* This file is automatically generated from > > > * subversion/libsvn_fs_fs/rep-cache-db.sql > > > * Do not edit it directly, but edit the source file and rerun 'make' > > > */ > > > > > > #define REP_CACHE_DB_SQL \ > > > "\ > > > "\pragma auto_vacuum = 1; > > > "\ > > > "\ > > > "\create table rep_cache (hash text not null primary key, > > > "\revision integer not null, > > > "\offset integer not null, > > > "\size integer not null, > > > "\expanded_size integer not null); > > > "" > > > > > This does not look like the correct contents of the file (there aren't any terminating " characters on each line, for instance). > > The longer term solution is for us to
RE: file *.a ignored
Hi, Soft [mailto:s...@gmx.ch] wrote: > On Windows we use Tortoise 1.5.9 and Subclipse in Eclipse. [...] > Lets say I move a file to a working copy with the extension *.a. It gets > immediately marked as ignored. [...] > I did remove the comment on the global-ignores line. It didn't help. *.a > files are still marked as ignored. Can you try adding the files using "svn add" on the command-line? If that works, I suggest you ask on the Tortoise and Subclipse mailing lists, as it might be client-specific. Those mailing lists are here: http://tortoisesvn.tigris.org/ds/viewForumSummary.do?dsForumId=4061 http://subclipse.tigris.org/ds/viewForumSummary.do?dsForumId=1047 Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Where is the latest SVN 1.6.9 binary for stable debian?
Hi, Pat Farrell wrote: > My debian server is running Lenny, the latest and greatest debian. > > The svn version is svn, version 1.5.1 (r32289) > I'd like to be running 1.6.9 > I can't find the .deb files, or better, a good repository to add to my > /etc/apt sources.list. 1.6.4 is available in the backports.org repository: http://www.backports.org/dokuwiki/doku.php?id=instructions http://packages.debian.org/lenny-backports/subversion But they don't have a 1.6.9 package yet. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org
Hi, Pete Hatton wrote: > Anyone know the unsubscribe information for the old list? I don't know the "official" procedure, but here's what I did: 1) Go to http://subversion.tigris.org/ 2) Log in using the Login link at the top right corner of the page. (The login page has a "Forgot your password" link that will allow you to set a new password, if you forgot your old one). 3) Go to the old Users mailing list page. The links seem to have vanished from the Subversion web site, but I fould it via Google: http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=1065 4) Click the link that says "My subscription settings" 5) Untick the box that says "Subscribed" and click the "Save Changes" button. 6) If you're also subscribed to the "dev" list, go to this URL: http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=462 Then repeat steps 4 and 5. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: "svn log" via svnserve is letting me see things it shouldn't, but "svn ls" works as I expect
Hi, Stefan Sperling wrote: > On Wed, Mar 03, 2010 at 03:01:22PM -0600, Reid Priedhorsky wrote: > > In particular, log messages to files not in > > /cyclingproject/public should not be available. > > Log message are not per file. They are per revision. > They aren't tied to any particular path. > Off-hand I cannot think of a way to prevent them from being seen. But the documentation for how authz works says: http://svn.apache.org/viewvc/subversion/trunk/notes/authz_policy.txt?ann otate=859714 > == > WHAT USERS SHOULD EXPECT FROM PATH-BASED AUTHZ > == > [...] > 2. LOG MESSAGES > > Log information may be restricted, based on readability of > changed-paths. > > * If the target of 'svn log' wanders into unreadable territory, > then log output will simply stop at the last readable revision. > If the log is tracing backwards through time, as the plain > "svn log" command does, the target will appear to be added > (without history) in that revision. > > * If a revision returned by 'svn log' contains a mixture of > readable/unreadable changed-paths, then the log message is > suppressed, along with the unreadable changed-paths. Only > the revision number, author, date, and readable paths are > displayed. > > * If a revision returned by 'svn log' contains only unreadable > changed-paths, then only the revision number is displayed. Is this documentation wrong? Or doesn't it apply for some reason? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: 403 Forbidden in response to COPY request
Hi, Anton Prowse wrote: [...] > [/trunk/specialfile] > user2 = [...] > when I authenticate as user2 I receive the following error > when trying to create a branch from the trunk of "repos1": > Server sent unexpected return value (403 Forbidden) in > response to COPY request for '/repos/repos1/!svn/bc/999/trunk' user2 is trying to copy /trunk/specialfile to somewhere where he'd be able to read it. So Subversion blocks it. In order to create a branch from trunk, you need read access to trunk and every file inside it. Perhaps /trunk/specialfile can be moved somewhere else, so you can remove this restrictive permission? (This may require you to dump the repository and use "svndumpfilter" to get rid of the historical revisions of /trunk/specialfile). Kind regards, Jon -- (Please direct all replies to the mailing list) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SVN respository expiry date
Hi, Arthur Chan wrote: > I am requesting SVN checkin time from my previous company. ... > However, they told me that SVN only store logs for 3 months > by default so that all my commit time were lost. There are 2 different places you can get "commit time" information. First, there are the logs from Subversion. These are reliable (no-one apart from the system administrator could forge them). They are optional - you don't have to generate them. If you do generate them, then it's up to you to decide how long to store them for. They can log all activity, including commits, checkouts, and updates. I suspect the logs are what your company is talking about, and it's quite plausible for them to be stored for only 3 months. Secondly, there is the "svn:date" revision property in the repository. These may or may not be reliable, depending on whether your repository has a "pre-revprop-change" hook that allows them to be changed. (By default, they cannot be forged by anyone other than the system administrator. But if your system administrator installs a "pre-revprop-change" hook that allows it, then any committer can change them to any value, without leaving an audit trail). They are generated automatically by Subversion, you can't (easily) turn them off. Subversion will store them forever (or until someone changes or deletes them). These only tell you the commit time, they won't tell you about checkouts or updates. Kind regards, Jon -- (Please direct all replies to the mailing list) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: merging repositories
Hi,
Tobias wrote:
> I have a project with two different repositories,
> that I want to merge into one common repository.
Would "svndumptool merge" do what you want?
http://svn.borg.ch/svndumptool/
(I haven't tried it, it's just something I found and
bookmarked when investigating Subversion)
> The simplest way would surely be to say:
> $ svnadmin dump Base/ base.dmp
> $ svnadmin dump Develop/ develop.dmp
> $ svnadmin load --parent-dir "Base/" Merged/ < base.dmp
> $ svnadmin load --parent-dir "Develop/" Merged/ < develop.dmp
> However, this does not semantically respect the correct time order
>[...]
> Will "svnadmin load" keep the commit dates
Yes. They're just a revision property.
> and if so, what would be the outcome of, say,
> "svn update -r {someDate}"?)
Undefined (and unpredictable). My understanding is that this
does a binary search, which will go haywire if your dates
aren't monotonically increasing. So you can't use it on
such repositories.
Kind regards,
Jon
--
(Please direct all replies to the mailing list)
**
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent those
of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
RE: Multiple Lines for groups in authz conf file
Hi, > I'm using mod_authz to specify permissions in svn. Is there a way > to list the group members on multiple lines instead of just a > single line? For example, instead of: > > [groups] > developers=joe, frank, bob > > I would like to have something like: > > [groups] > developers= > joe, > frank, > bob > > Will this work? The reason is that one of the groups is very > large, and it's messy to have all the users on one line. In Subversion's configuration files, leading whitespace indicates a continuation line. So you could do: [groups] developers = joe, frank, bob Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Can I not use svnadmin load with a remote repository?
Andy Levy wrote: > David Bartmess wrote: > > My company has done a preliminary spec for moving from CVS to > > Subversion, using the python script cvs2svn. The cvs2svn script > > works fine, but when I try to do an svnadmin load of the dump > > file created, using the Assembla https URL, it complains that > > it can't find a "format" file. > > > > After quite a bit of web searching, I think I see the problem. > > The path for the destination of where to load the dumpfile > > contents seems to have to be a file path, not a URL. Is this > > right? Or am I missing something? > > svnadmin requires local filesystem access for everything it does. Yep. Your SVN host (Assembla) might be able to take your dump file and load it for you - try asking them or filing a support request. If they won't do that, then you can work around this by: 1) Create a new empty repository on your hard disk. 2) Use svnadmin load to load the dump file into your local repository. (Note: cvs2svn has the option to create a new repository for you, which would let you skip steps 1 and 2). 3) Use "svnsync" to sync from your local repository to the real one. Note that the target repository has to be completely empty to do this. 4) Delete your temporary local repository. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: cannot break lock due to no matching lock-token
Hi, You don't say what client you're using, but it doesn't seem to be the Subversion command-line client. Try asking on the relevant mailing list for your client. If you were using the command-line client, you'd use "svn unlock --force". See these pages for details: http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.unlock.html Kind regards, Jon -- Please direct all replies to the mailing list. From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:14 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Does anyone know how I can clean up a missing lock-token? From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: Tuesday, April 13, 2010 7:01 AM To: 'users@subversion.apache.org' Subject: cannot break lock due to no matching lock-token A file was created and locked. The file was unlocked and the project tagged. the tagged folder was merged with an empty trunk and then the trunk checked out. A file in the project was locked, but later removed without being unlocked. Now the file does not exist in the trunk, but any changes to the trunk cannot commit because "cannot verify lock on path... ; no matching lock- token available. If you wish to break the lock, use the 'Check for Modification' dialog" appears and prevents any actions on the trunk (ie, delete all files). I have tried checking for modifications but none are listed (the file was deleted). I cannot merge, delete, copy or anything. The lock that was there is not needed. How do I remove this lock-token or whatever I need to do? Tom Jones Woodward Governor Co. Turbine Systems (Test Engineering) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: cannot break lock due to no matching lock-token
Hi, > could I use a local command line client (while > keeping Tortoise resident) to execute this? Yes. The command line client can be downloaded from here: http://subversion.apache.org/packages.html#windows I use the SlikSVN one, but it really doesn't matter which one you use. Kind regards, Jon -- Please direct all replies to the mailing list. -Original Message- From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:47 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Thanks for replying. I am using TortoiseSVN, which directs me to this mailing list for discussion. Pardon my amateurishness, could I use a local command line client (while keeping Tortoise resident) to execute this? -Original Message----- From: Jon Foster [mailto:jon.fos...@cabot.co.uk] Sent: Wednesday, April 14, 2010 7:23 AM To: Tom Jones; users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Hi, You don't say what client you're using, but it doesn't seem to be the Subversion command-line client. Try asking on the relevant mailing list for your client. If you were using the command-line client, you'd use "svn unlock --force". See these pages for details: http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.unlock.html Kind regards, Jon -- Please direct all replies to the mailing list. From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: 14 April 2010 13:14 To: users@subversion.apache.org Subject: RE: cannot break lock due to no matching lock-token Does anyone know how I can clean up a missing lock-token? From: Tom Jones [mailto:tom.jo...@woodward.com] Sent: Tuesday, April 13, 2010 7:01 AM To: 'users@subversion.apache.org' Subject: cannot break lock due to no matching lock-token A file was created and locked. The file was unlocked and the project tagged. the tagged folder was merged with an empty trunk and then the trunk checked out. A file in the project was locked, but later removed without being unlocked. Now the file does not exist in the trunk, but any changes to the trunk cannot commit because "cannot verify lock on path... ; no matching lock- token available. If you wish to break the lock, use the 'Check for Modification' dialog" appears and prevents any actions on the trunk (ie, delete all files). I have tried checking for modifications but none are listed (the file was deleted). I cannot merge, delete, copy or anything. The lock that was there is not needed. How do I remove this lock-token or whatever I need to do? Tom Jones Woodward Governor Co. Turbine Systems (Test Engineering) ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ *** The information in this e-mail is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this e-mail in error please notify the sender by return e-mail delete this e-mail and refrain from any disclosure or action based on the information. *** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, F
RE: JavaHL - when using peg makes the difference in diffSummarize()
Hi, "m g" wrote: > Subject: JavaHL - when using peg makes the difference in diffSummarize() > > can you provide me at least one case in which passing > a non-null peg revision to SVNClientInterface.diffSummarize() > returns a different result than when passing null ? > > Thanks > Mário Have you read the SVN book? http://svnbook.red-bean.com/ It has a good explanation of peg revisions. Kind regards, Jon -- Please direct all replies to the mailing list. ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: How to allow anonymous access, but not everyone access in path-based authorization?
Hi, Didier Trosset wrote: > I have a subversion server running with apache. It authenticates > users using LDAP configuration and uses SVN path-based > authorizations to limit user access to certain repositories. > This works perfectly. > > Now, I have a service I want to setup (rietveld, for code reviews) > that needs to have an anonymous access to the repository. > [... snip ...] > This did not work until I add an additional line "* = r" in the > authorization file to allow read access to all users. > > For instance, before I add the authorization from a specific IP, > all users were authenticated, and thus had a name. Now, some > accesses are done without a user name! I found the |"-|" user > name in the apache log files, but the line "|- = r"| does not work, > neither do |"anonymous = r"|. I'd like not to allow read access to > everyone in SVN authorization. How can I do this? Subversion's authz files support "$anonymous" to refer to anonymous users. (And "$authenticated" to refer to authenticated users). Kind regards, Jon -- Please direct all replies to the mailing list ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: can't build with zlib
Hi, Edward Ned Harvey wrote: > I have tried everything I can think of, and I can't seem to get > svn to build with the zlib that comes with it. It's always > linking against /usr/lib64/zlib. > After build: > ldd `which svn` | grep libz > libz.so.1 => /usr/lib64/libz.so.1 (0x0034a690) What's the full output of ldd? Are you linking against some other library that's linked against your system zlib? Run ldd on every other library that's listed, to see if any depend on libz.so. Kind regards, Jon -- Please direct all replies to the mailing list. ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Debian svn + apache2 configuration errors
Hi, kevin fauchon [mailto:kevin.fauc...@gmail.com] wrote: > AuthzSVNAccessFile /DATA/svn/config [...] > /DATA/svn/conf: > [/] > * = > anonymous = r You need $anonymous here - you're missing the $. So you granted read access to a user that's logged in with the username "anonymous", not to anonymous users. (But I'm not sure why you don't just do "*=r" - any of your users could get read access by simply logging out). > [test:/] > test = rw [...] > And when i try to go to http://svn.monpoulpe.com/test > i have a 403 forbiedden error On a related point... I have a Python script that does "lint" like checks on Subversion AuthZ files. It would have detected this bug, since it reads the ".htpasswd" file and would have reported that you're granting permissions to a non-existant user. Would the Subversion developers be interested in including it in Subversion? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Subversion 1.6 write-through proxy mirroring
Jim Lord wrote: > I'm setting up a write-through proxy mirror. I can run: > > svnsync init --source-username svnsystem --source-password $pass > --sync-username svnsystem --sync-password $pass > file:///data/svn/vtest > https://versiontest2.divxnetworks.com/svn/vtest > from the slave machine versiontest1 > BUT, I can't run: > svnsync init --source-username svnsystem --source-password $pass > --sync-username svnsystem --sync-password $pass > https://versiontest1.divxnetworks.com/svn/vtest > file:///data/svn > on the master without getting the error: > svnsync: DAV request failed; it's possible that the repository's > pre-revprop-change hook either failed or is non-existent > > The pre-revprop-change hooks exist on both master and slave for > the vtest repository What are the filesystem permissions on your pre-revprop-change hook in the target repository? What user does Apache run as? Does that user have execute permission on the hook script? Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Merging repositories - is it possible?
Hi, Les Mikesell wrote: > On 8/6/2010 10:12 AM, Itamar O wrote: > > On Fri, Aug 6, 2010 at 4:56 PM, JWalker > > This is my first post here. > > > > > > Is it possible to merge several repositories in a new empty > > > repository? > > > > > > I am asking this, because I made several repositories of one project, > > > one repository for mechanics, another for the software, another one > > > for the electronics and so on. Now I see that this will be a bit > > > hardly to maintain when more projects appear in the future. > > > > > > My goal is to create this layout (example) > > > / > > > /mechanics > > > /software > > > /electronics > > > > > > and then load the repository of mechanics to /mechanics, the > > > repository of software to /software and so on. > > > > > > So, is this scenario possible - by bump/load procedure or something > > > else? > > > > This is exactly the use case described in the SVN redbook: > > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html > > #svn.reposadmin.maint.migrate > > But note that although the revision histories are maintained, when you > combine them the revisions will be renumbered and you also won't be able > to specify date ranges because the changes will be out of order in the > combined repository. If you care about that, you could try "svndumptool merge". See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Migrating from 32 to 64 bit
Hi, SVN decides if two repositories are "the same" by comparing their UUIDs. You can get the Repository UUID from the old repository with "svn info", and set it on the new repository with "svnadmin setuuid". Kind regards, Jon From: Leszek Szarlej [mailto:leszek.szar...@gmail.com] Sent: 11 August 2010 18:56 To: Edward Ned Harvey; Leszek Szarlej; users@subversion.apache.org Subject: Re: Migrating from 32 to 64 bit Thank you for your answers. Currently I've setup svnsync and I am doing test run of synchronizing repositories. I will have a small window to migrate repositories. Using the svnsync gives me possibility to do major job before the change window and then final sync during the change. In this step I have some doubts whether users will have possibility to relocate their local copies to new repository on new server. The first step of sync procedure is to create fresh repository, I am afraid that it will have different ID and svn will say "its not the same repository" I will test it but you are welcome to give me your comments. I have about 400 repositories to migrate. Svnsync showed about 60 -70 hours to sync all repos. Thanks much Leszek Szarlej On 11 August 2010 15:50, Stefan Sperling wrote: On Wed, Aug 11, 2010 at 09:11:29AM -0400, Edward Ned Harvey wrote: > As far as subversion is concerned, as long as you get it installed, there is > nothing for you to think or care about. It depends on the Subversion repository backend. If the BerkeleyDB backend is used, a dump/load cycle is probably necessery, so just do it to be on the safe side. With repositories using FSFS, there is nothing to worry about. The file "db/fs-type" in a repository tells you which kind of backend the repository is using: "bdb" or "fsfs" Stefan __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: What's the current status for subversion replication?
Ulrich Eckhardt wrote: > On Wednesday 11 August 2010, Ryan Schmidt wrote: > > you can set up a write-through proxy so that people who check out > > from a slave and try to commit will be transparently redirected to > > the master. > > How? It's described in the book: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.s erverconfig.httpd.extra.writethruproxy Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: What's the current status for subversion replication?
Steven Woody wrote: > Thanks everyone, and, can I get know if the replication/write-through > things support https? Yes, they do. > The master that I want to mirror is using https On the mirror, you need the appropriate Apache modules and configuration. Make sure you have mod_proxy and mod_ssl loaded as well as the normal Subversion modules. The proxy-specific config I've used is: ... SSLProxyEngine on SSLProxyCACertificateFile /some/local/path/master_cert.pem SSLProxyVerify require SSLProxyVerifyDepth 10 ... standard SVN config omitted ... SVNMasterURI https://masterserver.mysite.example/svn The path /some/local/path/master_cert.pem should contain the SSL certificate for your master SVN server. To create it, I just browsed to the master SVN server using a web browser and saved the SSL certificate to a file. (In Firefox: Navigate to SSL page, click padlock in bottom-right corner of browser, "View Certificate", "Details", "Export"). Useful reference: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk
Daniel Shahaf wrote: > Feldhacker, Chris wrote on Thu, Aug 19, 2010 at 15:27:25 -0500: > > Ramkumar: > > > Again, I expect that access control/ security is automatically taken care > > > of in the RA layer. `svnrdump load` is just like a user making some changes > > > and committing them one by one except the author and timestamp in the > > > dumpfile are preserved. Why would you want to block this? > > > > A client performing a regular commit cannot currently spoof the author and timestamp, or can they? > > > > Yes: > > svn propset --revprop svn:author > svn propset --revprop svn:date > But not by default. Changing revprops has to be explicitly enabled by the repository administrator. To do this, the server admin has to explicitly create a "pre-revprop-change" hook, and set it to allow the changes. Many "pre-revprop-change" scripts will disallow changes to "svn:date" and "svn:author", although they might allow other revprops such as "svn:log" to be edited. http://svnbook.red-bean.com/nightly/en/svn.ref.reposhooks.pre-revprop-ch ange.html Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: is 'svn lock' possible for replication?
Hi, Steven Woody wrote: > On 20 August 2010 23:19, Steven Woody wrote: > > Hi, > > > > With a replication/write-through setup, can a user execute 'svn lock' > > on master/slaver nodes? Thanks. > > Hey folks, no one can gives me a hint? The SVN Book answers your question. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: is this a bug ?
Hans wrote: > I got no reaction on freenode#svn, so here goes : > > This looks like a bug in 1.6.12 to me : > for a subdirectory with its .svn/ removed > a 'svn up --force .' in its parent does not recreate it > where 'svn up --force dirname' does That won't happen in Subversion 1.7, so I wouldn't worry about it. (Subversion 1.7 won't have .svn folders in subdirectories, so you won't be able to delete them). Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Fwd: Repository Directory Tree
Stefan Sperling wrote: > On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote: > > I send this email out about once a month or so in what is > > becoming the vain hope I'll get a response... > > > > My subversion repository is in /var/svn. Somehow (and, yes, I'm > > new; I'm evaluating it), I've wound up with the following > > directory structure in my subversion repository: > > > > /var/svn/ > > var/svn/proj1 > > var/svn/proj2 > > var/svn/proj3. > > [snip] > > > > I've tried to do an svnadmin dump and load with --parent-dir, and > > that didn't work. This was the command line sequence after I had > > made a copy of the repository in /var/svn.sav: > > > > svnadmin dump /var/svn.sav> old_repos > > rm -r/var/svn/* > > svnadmin create /var/svn > > svnadmin load --parent-dir / /var/svn< old_repos > > > > But, even though I had parent-dir as / (to try to eliminate one > > of the /var/svn's), I still got /var/svn/var/svn/projects. > > > > What is the way to do this? > > You want to remove the leading /var/svn components from all paths > in the dump file. See here: > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html > #svn.reposadmin.maint.filtering > The part that starts with: > "At this point, you have to make a decision. > Each of your dump files will create a valid repository, but will > preserve the paths exactly as they were in the original repository." > is the interesting part you should read especially carefully. > > Stefan I'm wondering if svndumptool could do this automatically. (Maybe 'svndumptool merge -o out.dump -i in.dump -r var/svn/proj1 proj1' ?) But I haven't tried it. See: http://svn.borg.ch/svndumptool/ Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
