Re: Checking for commits
On Mon, Dec 21, 2009 at 11:51, Dennis Jones
djo...@grassvalleysoftware.com wrote:
Hi,
Is there a simple way to determine if there were any commits on a repository
path given a specific date?
'svn log' doesn't give the results one might expect. For example, if there
were no commits yesterday (12/20/2009), and I say:
svn log -r {2009-12-20}:{2009-12-21} repourl
. . . then instead of getting back nothing (which one would expect), I'll
get back the most recent commit from a couple of days ago (which is not what
I want).
One might only expect that if they hadn't read
http://svnbook.red-bean.com/en/1.5/svn.tour.revs.specifiers.html#svn.tour.revs.dates
which states: When you specify a date, Subversion resolves that date
to the most recent revision of the repository as of that date, and
then continues to operate against that resolved revision number:
How can I determine if there were commits on a specific date?
Parse the output of the svn log you're already running.
FSFS and BDB compare benchmark
Hi, I'm looking for some benchmark test utility to test speed and performance of the BDB and FSFS backends, but could not find anything. Does anybody know about any utility or script suitable for this purpose? Thanks to any advice. -- Regards Honza Horak E-mail: horak.ho...@gmail.com
Svn shows timeout errors without any reason
Hello, My svn server has a debian 4.0, apache 2.2.3-4+etch11 installed with apt-get, an d svn 1.4.2dfsg1-3. The svn auth is through ldap. My problem is very strange and difficult to reproduce: Sometimes, when an user tries to do an update, co or ci, a signal de timeout is showed. Then you do an cleanup, and run the command again. Maybe, the third or fourth time you run the command the operation is successful. Then, everytime you run a command, it works fine. But, if you wait 30 minutes without doing anything, maybe the problem appears again. I know that the problem is not from client, because we are 20 people using the same svn, and all of us have this problem. The logs of apache dont show anything interesting :(. Can anyone tell us about this?? Regards Confidencialidad: Este mensaje y sus ficheros adjuntos se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente respondiendo al mensaje y proceda a su destrucción. Disclaimer: This message and its attached files is intended exclusively for its recipients and may contain confidential information. If you received this e-mail in error you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited and may be unlawful. In this case, please notify us by a reply and delete this email and its contents immediately.
Re: restricting sub-directory permissions
Hi Jon, The link you sent was helpful and the final workaround mentioned in the article seems to work, except one thing... There seems to be a security hole, which is that web-browsing of the restricted sub-directory is still possible using the anonymous-open URL. Thus, the solution does not seem to be feasible. I'll followup by commenting directly on the authors article, but if anyone has any other suggestions, it would be greatly appreciated. Thanks, On Sun, Dec 20, 2009 at 10:36 PM, Gabriel Ricardo gabriel.rica...@gmail.com wrote: Thanks for all the responses. I tried all of the suggestions, but unfortunately none of them worked. I also downloaded and installed subversion 1.6.5, along with apache 2.2.14 to see if maybe I needed more recent versions. I still have the same strange behavior, where either the sub-directory appears to users as if it does not exist, or all users can access it. Very frustrating. Seems like this is an area of subversion functionality that would greatly benefit from some more documentation, or some subversion developers troubleshooting why this breaks down for so many users. On Thu, Dec 17, 2009 at 3:08 AM, Jon Foster jon.fos...@cabot.co.uk wrote: 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 __
How to start over?
Hi,
I'm just starting to explore using svn. I have downloaded and
read /Version Control with Subversion For Subversion 1.5 (Compiled
from r3305)/. I have installed svn and svnserve on my home computer
(running openSuSE 11.0), and it appears to be done right, as far as I
can see.
I'm using svnserve mostly for practice; I realize that I didn't
have to set that up for a local repository. Also, because my
personal partition is larger than my root partition, I have svnserve
pointing to a location there.
So I run svnadmin create, and it seems to have worked, but when
I try to add entities to the repository I get these messages:
svn: '.' is not a working copy
svn: Can't open file '.svn/entries': No such file or directory
I'm guessing that I set up something in the wrong order or
something. If I want to start over, how do I get rid of the current,
empty repository?
Thanks,
Leslie
Some environment information:
turr...@pinto$ uname -a
Linux pinto 2.6.25.20-0.5-pae #1 SMP 2009-08-14 01:48:11 +0200 i686 i686
i386 GNU/Linux
turr...@pinto$ cat /etc/SuSE-release
openSUSE 11.0 (i586)
VERSION = 11.0
turr...@pinto$ svn --version
svn, version 1.5.7 (r36142)
compiled Aug 10 2009, 15:34:19
Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet
(http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using
Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network
protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
turr...@pinto$ rpm -q cyrus-sasl
cyrus-sasl-2.1.22-140.2
turr...@pinto$ cat /etc/sysconfig/svnserve
# Path:Network/Subversion/svnserve
# Description: Basic configuration for svnserve
#
# Default options for the svnserve process:
# It is recommended to provide only readonly access to your data.
# There is no authentication possible; everyone can read and write at
will.
# Read the subversion documentation about more information.
# Value type: string
# Default value: -d -R -r /srv/svn/repos
#
# svnserve should run as an unprivileged user:
# The userid/groupid svn is not created during package install;
# run 'useradd -d /srv/svn -s /bin/false svn ; groupadd svn' to create
the
# userid and groupid.
# Value type: string
# Default value: svn
#
# svnserve should run as unprivileged user:
# Userid svn and groupid svn are not created during package install;
# run 'useradd -d /srv/svn -s /bin/false svn ; groupadd svn' to create
the
# userid and groupid.
# Value type: string
# Default value: svn
#
SVNSERVE_OPTIONS=-d -R -r /home/turriff/svn/Project
SVNSERVE_USERID=svn
SVNSERVE_GROUPID=svn
turr...@pinto$ cat /etc/sasl2/svn.conf
pwcheck_method: saslauthd
mech_list: plain digest-md5
turr...@pinto$ grep svn /etc/{passwd,group}
/etc/passwd:svn:x:1003:100::/home/turriff/svn:/bin/false
/etc/group:svn:!:1001:
turr...@pinto$ ll ~/svn/Project/
total 16
drwxr-xr-x 2 svn svn 80 2009-12-20 14:50 conf
drwxr-sr-x 6 svn svn 4096 2009-12-20 09:49 db
-r--r--r-- 1 svn svn2 2009-12-20 09:49 format
drwxr-xr-x 2 svn svn 4096 2009-12-20 09:49 hooks
drwxr-xr-x 2 svn svn 39 2009-12-20 09:49 locks
-rw-r--r-- 1 svn svn 229 2009-12-20 09:49 README.txt
turr...@pinto$ #My working directory; what I want to add to svn:
#My working directory; what I want to add to svn:
turr...@pinto$ tree -d ~/Documents/SourceCode/OpenPipelines
/home/turriff/Documents/SourceCode/OpenPipelines
|-- client
| |-- branch
| |-- tag
| `-- trunk
`-- daemon
|-- branch
|-- tag
`-- trunk
8 directories
svn merge --reintegrate results in a false text conflict set on a binary file
Hello everybody, I have discovered a scenario when svn merge --reintegrate results in a false text conflict set on a binary file. The scenario is simple: 1. add any binary file to the trunk, 2. create a branch from the trunk, 3. modify the binary at the trunk, 4. merge changes from trunk to the branch 5. repeat step 3, 6. try to merge the branch back to the trunk using svn merge --reintegrate and get the following: svn, version 1.5.6 (r36142) compiled Feb 26 2009, 22:41:36 svn merge file:///extra/playground/repos/branches/any_feature/ Conflict discovered in 'iota.tgz'. Select: (p) postpone, (mf) mine-full, (tf) theirs-full, (h) help for more options: --- Merging r3 through r7 into '.': Ciota.tgz svn, version 1.6.6 (r40053) compiled Nov 8 2009, 13:10:49 Conflict discovered in 'iota.tgz'. Select: (p) postpone, (mf) mine-full, (tf) theirs-full, (s) show all options: p --- Merging differences between repository URLs into '.': Ciota.tgz Summary of conflicts: Text conflicts: 1 Subversion server version in both cases: svn, version 1.5.6 (r36142) compiled Feb 26 2009, 22:41:36 svn pl iota.tgz Properties on 'iota.tgz': svn:mime-type svn pg svn:mime-type iota.tgz application/x-gzip Any comment would be very appreciated! Is there anything I do wrong? Been searching over bug tracker - no success. A reproduction script is attached. uname -a Linux 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux Best regards, Pavel repro.sh Description: Bourne shell script
