Discussion message digest

From: <users-digest_at_subversion.tigris.org>
Date: Sat, 11 Jul 2009 00:15:24 -0700 (PDT)

Here are the messages that have been received prior to 7/11/09 12:15 AM:

Topic (messages 46,967 through 47,091):

Enforcing svn property needs-lock for a repo subset
         46,969 by : David Aldrich <david.aldrich_at_eu.nec.com> sent on : Fri, 10 Jul 2009 09:24:10 +0100
          46,986 by : Andy Levy <andy.levy_at_gmail.com> sent on : Fri, 10 Jul 2009 07:05:33 -0400
          46,988 by : David Aldrich <david.aldrich_at_eu.nec.com> sent on : Fri, 10 Jul 2009 12:12:40 +0100
          47,063 by : Ryan Schmidt <subversion-2009b_at_ryandesign.com> sent on : Fri, 10 Jul 2009 13:50:05 -0500

svnserve Wont Start - svnserve: auxpropfunc error - xinetd sasl sasldb - PLEASE HELP!
         47,087 by : Stacy Lucchese <stacylucchese_at_roadrunner.com> sent on : Fri, 10 Jul 2009 14:37:09 -0700

Confused about branches and partial switches
         47,011 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 10:03:38 -0400

SVN bug
         46,967 by : haiqing <chengj929_at_163.com> sent on : Fri, 10 Jul 2009 15:49:21 +0800
          47,068 by : Ryan Schmidt <subversion-2009b_at_ryandesign.com> sent on : Fri, 10 Jul 2009 14:03:07 -0500

RHEL4 x86_64 issues with 'SASL' and difficulty installing i386 version on RHEL4 x86_64.
         47,091 by : Nico Kadel-Garcia <nkadel_at_gmail.com> sent on : Fri, 10 Jul 2009 19:07:31 -0400
          46,978 by : Radomir Zoltowski <radomir.zoltowski_at_s3group.com> sent on : Fri, 10 Jul 2009 10:46:42 +0100
          46,992 by : Nico Kadel-Garcia <nkadel_at_gmail.com> sent on : Fri, 10 Jul 2009 07:42:52 -0400
          47,000 by : Nico Kadel-Garcia <nkadel_at_gmail.com> sent on : Fri, 10 Jul 2009 09:06:51 -0400

Upgrading from 1.4 to 1.6.3
         47,033 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 12:58:27 -0400
          47,036 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 18:16:04 +0100
          47,037 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 13:24:42 -0400
          47,038 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 13:31:09 -0400
          47,040 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 18:33:57 +0100
          47,041 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 13:37:28 -0400
          47,044 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 18:49:16 +0100
          47,046 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 18:53:10 +0100
          47,047 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 13:53:37 -0400
          47,052 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 19:06:04 +0100
          47,054 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 14:20:18 -0400
          47,060 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 19:35:15 +0100
          47,062 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 14:42:04 -0400
          47,064 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 19:51:53 +0100
          47,067 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 15:01:21 -0400
          47,071 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 15:27:09 -0400
          47,073 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 15:58:05 -0400
          47,080 by : Vitaliy Sholokhov <vsholokhov_at_marvel.com> sent on : Fri, 10 Jul 2009 16:09:52 -0400
          47,082 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 16:17:06 -0400

svnsync: Cannot accept 'svn:log' property because it is not encoded in UTF-8
         46,968 by : Marc Lustig <ml_at_marclustig.com> sent on : Fri, 10 Jul 2009 09:58:42 +0200

SVN update + Resolve conflict !!
         46,976 by : Himanshu Raina <raina_himanshu_at_yahoo.com> sent on : Fri, 10 Jul 2009 14:59:40 +0530 (IST)

log' property because it is not encoded in UTF-8
         46,972 by : "B. Smith-Mannschott" <bsmith.occs_at_gmail.com> sent on : Fri, 10 Jul 2009 10:43:57 +0200
          46,974 by : Marc Lustig <ml_at_marclustig.com> sent on : Fri, 10 Jul 2009 11:19:53 +0200

Pre-commit hook
         47,039 by : Scott Vickery <svickery_at_cavucorp.com> sent on : Fri, 10 Jul 2009 13:15:51 -0400
          47,042 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 13:39:49 -0400
          47,043 by : Andy Levy <andy.levy_at_gmail.com> sent on : Fri, 10 Jul 2009 13:48:16 -0400
          47,045 by : Nicolai Scheer <scope_at_planetavent.de> sent on : Fri, 10 Jul 2009 19:50:09 +0200
          47,048 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 13:56:43 -0400
          47,049 by : Scott Vickery <svickery_at_cavucorp.com> sent on : Fri, 10 Jul 2009 13:43:37 -0400
          47,050 by : Scott Vickery <svickery_at_cavucorp.com> sent on : Fri, 10 Jul 2009 13:52:20 -0400
          47,051 by : Stephen Connolly <stephen.alan.connolly_at_gmail.com> sent on : Fri, 10 Jul 2009 19:01:56 +0100
          47,055 by : Scott Vickery <svickery_at_cavucorp.com> sent on : Fri, 10 Jul 2009 14:11:31 -0400
          47,057 by : Andy Levy <andy.levy_at_gmail.com> sent on : Fri, 10 Jul 2009 14:27:59 -0400
          47,058 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 14:28:50 -0400
          47,065 by : Ryan Schmidt <subversion-2009b_at_ryandesign.com> sent on : Fri, 10 Jul 2009 13:55:12 -0500
          47,066 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 14:58:03 -0400
          47,069 by : Ryan Schmidt <subversion-2009b_at_ryandesign.com> sent on : Fri, 10 Jul 2009 14:05:39 -0500
          47,083 by : Scott Vickery <svickery_at_cavucorp.com> sent on : Fri, 10 Jul 2009 16:15:43 -0400

Ignoring ancestry in --reintegrate merge
         47,012 by : Bob Archer <bob.archer_at_amsi.com> sent on : Fri, 10 Jul 2009 10:04:46 -0400

ignore' property
         46,994 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 12:46:30 +0100
          46,997 by : Nico Kadel-Garcia <nkadel_at_gmail.com> sent on : Fri, 10 Jul 2009 07:50:39 -0400

+----------------------------------------------------------------------+
| ETAS Mail Security - http://intranet.etasgroup.com/encryption |
+----------------------------------------------------------------------+
| - The message was not encrypted and not digitally signed |
+----------------------------------------------------------------------+

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2370623

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

attached mail follows:

On Fri, Jul 10, 2009 at 9:06 AM, Nico Kadel-Garcia<nkadel_at_gmail.com> wrote:
> On Fri, Jul 10, 2009 at 7:42 AM, Nico Kadel-Garcia<nkadel_at_gmail.com> wrote:
>> On Fri, Jul 10, 2009 at 5:46 AM, Radomir
>> Zoltowski<radomir.zoltowski_at_s3group.com> wrote:
>>> Is there a reason for not using CollabNet x86_64 RPMs? See here:
>>> http://www.open.collab.net/downloads/subversion/redhat.html
>>
>> Besides having to register for it, which I've always hated?
>>
>>> If you install i386 onto x86_64 machine, you need to provide all
>>> dependencies tree for i386 arch, too, which is usually quite entertaining
>>> task.
>>>
>>> R.
>>
>> See my notes below. The only tricky dependency was grabbing the
>> apr-util dependency. *BUT*, if you say "yum install subversion" (since
>> I use yum, which has vastly superior package management to RHEL's
>> up2date tool and works well with RPMforge and mock and EPEL), goes
>> ahead and installs the ancient subversion-1.1.x-foo.x86_64 version as
>> well as the contemporary subversion-1.6.3-bar.i386 version, which
>> seriously screws up the installation by replacing /usr/bin/svn.
>>
>> I'll take a shot at the collabnet RPM's, but I expect the same problem.
>
> Well, *that* was interesting. Collabnet does publish RPM's, as you
> suggest, but with their entirely personal and unique layout. They dump
> a bunch of material in interesting places, starting with a client in
> /opt, a server that puts a bunch of debris in /etc/opt/, and other
> vagaries. Comprehensible, but it would take thought to merge into our
> existing infrastructure. I need to think about its use carefully.
>
> Their x86_64 svn, however, does work correctly for the 'svn help'
> command. So I need to think about it: it's not just a drop in
> replacement, and either needs a bunch of symlinks created, or a "PATH"
> and "MANPATH" dropped into /etc/profile.d/collabnetsvn.sh to help out.
>

So, I tested the Collabnet version. It works just fine: Unfortunately,
I'm not in a position where I can switch the environment wholesale,
and only have the issue in x86_64 on RHEL 4, darn it. And re-arranging
a bunch of people's PATH and MANPATH is begging for pain in this
environment. I have to think about whether, and how, to integrate
this.

attached mail follows:

HELLO,ALL:

I found a bug about svn .
Iis it really a bug? hoping for yours advices.

MY svn message are:

1:http://17*.*.*.*/svn/test_svn_1,has 5files
└─test_svn_1
        B.png
        a.png
        f.png
steps:
1: svn delete B.png (success)
2: svn add b.png(success)
3: svn commit -m "add b.png" b.png(success)
4: in other directory,do: svn co http://1*.*.*.*/svn/ro45/branches/test_svn_1 (fail)

result:
the workcopy directory was locked,and can not cleanup success.
A test_svn_1\a.png
A test_svn_1\B.png
A test_svn_1\b.png
A test_svn_1\f.png
svn: In directory 'test_svn_1'
svn: Can't open file 'test_svn_1\.svn\tmp\text-base\b.png.svn-base': System can not find the file.

5:come into the workcopy,and execute : svn up
result:
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

6: svn cleanup
result:
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'a.png' is not under version control

That's all .
I think it's svn's bug.
what do everyone think ?

Best Wishes!

chengj929
2009-07-10

attached mail follows:

Hi there

I am trying to mirror a 1.5.1 based repo using a 1.6.3 client and mirror-repo

The svnsync command failes after about 20000 revs with following error message:

svnsync: Cannot accept 'svn:log' property because it is not encoded in UTF-8

I had no hit on google for that message,
Could somebody please elaborate what is the proper way to fix that and
to make svnsync to work?

Do I have to edit the log properties?

thanks
Marc

attached mail follows:

I'm aware that this has been discussed before, but I have a slight twist on the usual question...

We want to enforce the needs-lock property on Word documents added to a svn repository.

I have read in the svn manual that this should not be done using a pre-commit hook.

A possibility is to use the svn CheckProperty hook which could refuse commits of .doc files lacking needs-lock. However, it would be better to silently add the property automatically.

The obvious answer is to use the client-side config file:

*.doc = svn:mime-type=application/msword;svn:needs-lock=*

The twist for us is that we only want to enforce this for some of our repositories (we use one repo per project), but we push out a common config file to all users using a Windows script.

Is it possible to modify the config file line above to apply to a subset of repos?

Best regards

David

attached mail follows:

On Fri, Jul 10, 2009 at 09:58, Marc Lustig<ml_at_marclustig.com> wrote:
> Hi there
>
> I am trying to mirror a 1.5.1 based repo using a 1.6.3 client and mirror-repo
>
> The svnsync command failes after about 20000 revs with following error message:
>
> svnsync: Cannot accept 'svn:log' property because it is not encoded in UTF-8
>
> I had no hit on google for that message,
> Could somebody please elaborate what is the proper way to fix that and
> to make svnsync to work?
>
> Do I have to edit the log properties?

Yes, I believe so. Subversion has always *wanted* svn:log to be proper
UTF-8, but only started enforcing this with 1.6.0.

Older clients with misconfigured encoding can submit wrongly encoded
log messages to older servers. 1.6.0 and later clients will not make
this error, and 1.6.0 servers will refuse such log messages. And
that's what's tripping up svnsync.

Unfortunately, there's no way for 1.6.0 to know what the user meant
when it encounters a log message that's not UTF-8 encoded (without
further information, it would amount to guessing the encoding).

// Ben

attached mail follows:

Thanks a lot, Ben, for the explanation.
It makes sense, and I was able to fix it.

2009/7/10 B Smith-Mannschott <bsmith.occs_at_gmail.com>:
> On Fri, Jul 10, 2009 at 09:58, Marc Lustig<ml_at_marclustig.com> wrote:
>> Hi there
>>
>> I am trying to mirror a 1.5.1 based repo using a 1.6.3 client and mirror-repo
>>
>> The svnsync command failes after about 20000 revs with following error message:
>>
>> svnsync: Cannot accept 'svn:log' property because it is not encoded in UTF-8
>>
>> I had no hit on google for that message,
>> Could somebody please elaborate what is the proper way to fix that and
>> to make svnsync to work?
>>
>> Do I have to edit the log properties?
>
> Yes, I believe so. Subversion has always *wanted* svn:log to be proper
> UTF-8, but only started enforcing this with 1.6.0.
>
> Older clients with misconfigured encoding can submit wrongly encoded
> log messages to older servers. 1.6.0 and later clients will not make
> this error, and 1.6.0 servers will refuse such log messages. And
> that's what's tripping up svnsync.
>
> Unfortunately, there's no way for 1.6.0 to know what the user meant
> when it encounters a log message that's not UTF-8 encoded (without
> further information, it would amount to guessing the encoding).
>
> // Ben
>

attached mail follows:

Hi,

I have a working copy of my project checked out onto a server.

Ques - Can I have both uncommitted and committed data in the WC ?

The reason being I have close to 8000+ templates on that server off which 2000 are currently committed to SVN (The remaining aren't used but still needed as the user subscription hasn't expired completely).The problem is when I run svn update on WC it runs fine as long as there is no conflict w.r.t to data being already present in WC i.e. when I move a project to my repo and run SVN update on my WC it returns an error saying object of same name already exist. SVN status returns the following

! .

After this when I run svn update I get an error 400 (Bad request) or the connection times out.

Note - As long as I'm committing
new projects to my repo (i.e no conflicts with existing projects) , svn update on my WC works fine. Is there a way I can resolve this

See the Web's breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/

attached mail follows:

Is there a reason for not using CollabNet x86_64 RPMs? See here:
http://www.open.collab.net/downloads/subversion/redhat.html

If you install i386 onto x86_64 machine, you need to provide all
dependencies tree for i386 arch, too, which is usually quite
entertaining task.

Nico Kadel-Garcia wrote:
> I'm using RHEL 4 on x86_64 hardware, for various reasons, and have
> tried out several backports of subversion-1.6.3. A typical one is at
> http://lxpro.com/subversion/1.6.3/el4/RPMS/ and unfortunately shows
> problems when running under x86_64, for which I've recompiled it and
> other versions. Unfortunately, I see this error when running the
> x86_64 compiled version, even when building from the SVN sources on an
> RHEL 4 x86_64 box with local neon, Python, and other utilities as
> needed.
>
> # svn help
> svn: Could not initialize the SASL library
>
> This, of course, is unacceptable.
>
> I've tried to install the i386 version of the software, but that
> reports this at RPM installation:
>
> # rpm -U /tmp/lxpro.com/subversion/1.6.3/el4/RPMS/subversion-1.6.3-0.2.el4.rf.i386.rpm
> warning: /tmp/lxpro.com/subversion/1.6.3/el4/RPMS/subversion-1.6.3-0.2.el4.rf.i386.rpm:
> V3 DSA signature: NOKEY, key ID 60eb420f
> error: Failed dependencies:
> libaprutil-0.so.0 is needed by subversion-1.6.3-0.2.el4.rf.i386
>
> I can resolve that by manually grabbing the apr-util.i386 package from
> a 32-bit RHEL, but it's awkward at best. I'd prefer to run the bare
> x86_64 version.
>
> Does anyone have any hooks on this problem?
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369549
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications_at_s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18

attached mail follows:

On Fri, Jul 10, 2009 at 04:24, David Aldrich<david.aldrich_at_eu.nec.com> wrote:
> Hi
>
> I'm aware that this has been discussed before, but I have a slight twist on the usual question...
>
> We want to enforce the needs-lock property on Word documents added to a svn repository.
>
> I have read in the svn manual that this should not be done using a pre-commit hook.
>
> A possibility is to use the svn CheckProperty hook which could refuse commits of .doc files lacking needs-lock. However, it would be better to silently add the property automatically.
>
> The obvious answer is to use the client-side config file:
>
> *.doc = svn:mime-type=application/msword;svn:needs-lock=*
>
> The twist for us is that we only want to enforce this for some of our repositories (we use one repo per project), but we push out a common config file to all users using a Windows script.

Do you have files in your other repositories which have .doc
extensions but *aren't* MS Word documents? I can't imagine a situation
where you wouldn't want to set the mime-type and needs-lock on an MS
Word file.

attached mail follows:

Hi Andy

> Do you have files in your other repositories which have .doc
> extensions but *aren't* MS Word documents?

> I can't imagine a situation
> where you wouldn't want to set the mime-type and needs-lock on an MS
> Word file.

Well, I would agree that this is recommended practice. I just didn't want to impose the practice on everyone. I will check whether we can do this as a company-wide policy but, meanwhile, is there anyway of defining the auto-prop on a per repository basis?

David

attached mail follows:

On Fri, Jul 10, 2009 at 5:46 AM, Radomir
Zoltowski<radomir.zoltowski_at_s3group.com> wrote:
> Is there a reason for not using CollabNet x86_64 RPMs? See here:
> http://www.open.collab.net/downloads/subversion/redhat.html

Besides having to register for it, which I've always hated?

> If you install i386 onto x86_64 machine, you need to provide all
> dependencies tree for i386 arch, too, which is usually quite entertaining
> task.
>
> R.

See my notes below. The only tricky dependency was grabbing the
apr-util dependency. *BUT*, if you say "yum install subversion" (since
I use yum, which has vastly superior package management to RHEL's
up2date tool and works well with RPMforge and mock and EPEL), goes
ahead and installs the ancient subversion-1.1.x-foo.x86_64 version as
well as the contemporary subversion-1.6.3-bar.i386 version, which
seriously screws up the installation by replacing /usr/bin/svn.

I'll take a shot at the collabnet RPM's, but I expect the same problem.

Parallel package releases for x86_64 are tricky to handle. I'd much
prefer to have a working, 64-bit tool, and we could get it published
on RPMforge as well for folks like me. (I contributed notes to the
RHEL 5 compatible package there.) Otherwise, you've got to put in
stupid things like yum exclude statements for your base repositories
in yum.conf or worse, write them into up2date configuratons for folks
who don't use yum. And that is *NASTY* business.

> Nico Kadel-Garcia wrote:
>
> I'm using RHEL 4 on x86_64 hardware, for various reasons, and have
> tried out several backports of subversion-1.6.3. A typical one is at
> http://lxpro.com/subversion/1.6.3/el4/RPMS/ and unfortunately shows
> problems when running under x86_64, for which I've recompiled it and
> other versions. Unfortunately, I see this error when running the
> x86_64 compiled version, even when building from the SVN sources on an
> RHEL 4 x86_64 box with local neon, Python, and other utilities as
> needed.
>
> # svn help
> svn: Could not initialize the SASL library
>
> This, of course, is unacceptable.
>
> I've tried to install the i386 version of the software, but that
> reports this at RPM installation:
>
> # rpm -U
> /tmp/lxpro.com/subversion/1.6.3/el4/RPMS/subversion-1.6.3-0.2.el4.rf.i386.rpm
> warning:
> /tmp/lxpro.com/subversion/1.6.3/el4/RPMS/subversion-1.6.3-0.2.el4.rf.i386.rpm:
> V3 DSA signature: NOKEY, key ID 60eb420f
> error: Failed dependencies:
> libaprutil-0.so.0 is needed by subversion-1.6.3-0.2.el4.rf.
> i386
>
> I can resolve that by manually grabbing the apr-util.i386 package from
> a 32-bit RHEL, but it's awkward at best. I'd prefer to run the bare
> x86_64 version.
>
> Does anyone have any hooks on this problem?
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369549
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe_at_subversion.tigris.org].
>
>
> ________________________________
> The information contained in this e-mail and in any attachments is
> confidential and is designated solely for the attention of the intended
> recipient(s). If you are not an intended recipient, you must not use,
> disclose, copy, distribute or retain this e-mail or any part thereof. If you
> have received this e-mail in error, please notify the sender by return
> e-mail and delete all copies of this e-mail from your computer system(s).
> Please direct any additional queries to: communications_at_s3group.com. Thank
> You. Silicon and Software Systems Limited. Registered in Ireland no. 378073.
> Registered Office: South County Business Park, Leopardstown, Dublin 18
> ________________________________
>

attached mail follows:

On Thu, Jul 9, 2009 at 10:29 AM, Marc Lustig<ml_at_marclustig.com> wrote:
> [corrected]
>
> Hi,
>
> I am trying to replicate a 1.5.2 based repo (running on RHEL) using svnsync.
>
> The mirror is running 1.6.1 based on Debian lenny.

*Don't*. svnsync is a handy little tool, but maintaining disparate
repo versions is begging for pain. Also, it's worth jumping to version
1.6.3 on both sides.

RHEL5 has subversion 1.6.3 available from RPMforge. RHEL4 has some
published RPM's for i386, but x86_64 has some serious problems. (This
is understandable: 1.6.3 is leading edge and has a *lot* of
subcomponents that have been seriously upgraded in the interim, and
RHEL4 is a pretty old OS by this point.)

If you can upgrade to Subversion 1.6.3 on both sides, thoroughly
backup your repository and do that first.

> I installed the pre-revprop-change hook and the init was also successfull.
>
> Then, running the atual sync (non-interactive) results in the
> following error at revision 301 (of 40xxx):
>
> svnsync: Cannot accept non-LF line endings in 'svn:ignore' property
>
> I walked thru google and found out that there is some trouble
> (incompatibility) when using 1.6.x on the mirror side.
> Ok, I installed 1.5.1 on the mirror.
> But still I get the same error:
> svnsync: Cannot accept non-LF line endings in 'svn:ignore' property
>
> Anybody knows how to fix this?
>
> Do I have to edit all svn:ignore properties of the original repo?
> What please is the command to do that?
>
> thanks
>
> Marc

Good question. If you can backup your server repo, install 1.6.x on
the server side, and hotcopy your repository so it's in the new 1.6.x
format, you should have a lot less trouble.

attached mail follows:

On Fri, Jul 10, 2009 at 7:42 AM, Nico Kadel-Garcia<nkadel_at_gmail.com> wrote:
> On Fri, Jul 10, 2009 at 5:46 AM, Radomir
> Zoltowski<radomir.zoltowski_at_s3group.com> wrote:
>> Is there a reason for not using CollabNet x86_64 RPMs? See here:
>> http://www.open.collab.net/downloads/subversion/redhat.html
>
> Besides having to register for it, which I've always hated?
>
>> If you install i386 onto x86_64 machine, you need to provide all
>> dependencies tree for i386 arch, too, which is usually quite entertaining
>> task.
>>
>> R.
>
> See my notes below. The only tricky dependency was grabbing the
> apr-util dependency. *BUT*, if you say "yum install subversion" (since
> I use yum, which has vastly superior package management to RHEL's
> up2date tool and works well with RPMforge and mock and EPEL), goes
> ahead and installs the ancient subversion-1.1.x-foo.x86_64 version as
> well as the contemporary subversion-1.6.3-bar.i386 version, which
> seriously screws up the installation by replacing /usr/bin/svn.
>
> I'll take a shot at the collabnet RPM's, but I expect the same problem.

Well, *that* was interesting. Collabnet does publish RPM's, as you
suggest, but with their entirely personal and unique layout. They dump
a bunch of material in interesting places, starting with a client in
/opt, a server that puts a bunch of debris in /etc/opt/, and other
vagaries. Comprehensible, but it would take thought to merge into our
existing infrastructure. I need to think about its use carefully.

Their x86_64 svn, however, does work correctly for the 'svn help'
command. So I need to think about it: it's not just a drop in
replacement, and either needs a bunch of symlinks created, or a "PATH"
and "MANPATH" dropped into /etc/profile.d/collabnetsvn.sh to help out.

attached mail follows:

>My last question is do I really need to delete and recreate my branch after each merge to trunk? This seems to be the prevailing >wisdom on the articles I've found, but I find it's often hard to tell whether or not svn branching advice applies to svn 1.6 or only earlier >versions with more primitive branching support.

No you don't. After you do your --reintegrate do a merge from trunk to branch with record only.

Let's say you branch at rev 100 and you are doing regular merges from trunk to branch to keep up with the trunk changes.

Now you are at a point where you want to merge your branch into trunk. So you switch to your trunk WC (I don't use switch I check out each path separately so I don't have to remember what path I am working on).

On your trunk do your merge from branch with --reintegrate. When you commit that it make note of the revision. For example, it's revision 125.

Now switch back to your branch WC and do a merge from trunk, this time specifying the revision from the commit of your merge (125 for example) and use the record only option... I think the command would be something like (sorry I mostly use Tortoise)

svn merge -r 125 --record-only $REPO/PathToProjectTrunk
svn ci

From there you can carry on in the branch. As you do further merges from trunk to branch it will not merge in r 125 because it that was recorded as already merged in. When you are ready you can once again do a --reintegrate merge to trunk... rinse and repeat.

BOb

DISCLAIMER: Don't blame me if this doesn't work. You might want to try it on a test repo so you can see what is going on. After you do the record only merge you can do an svn st and or an svn propget svn:merginfo . to see that the rev is added properly.

attached mail follows:

> I imagine this syntax might do something different with the mergeinfo
> property. But if I delete my branch after the merge, and re-copy it
> from trunk (just like I would after a --reintegrate), it should be
> fine, right?
>

I would think so yes.

BOb

attached mail follows:

Hello,

I've just upgraded subversion software on the server from 1.4.* to 1.6.3
and ran 'svnadmin upgrade REPOS_PATH' without any problems.
Now when I try to access repository via http connection, I constantly
get the following error in tortoisesvn:

"Could not open the requested SVN filesystem"

In browser I get the following:

<D:error>
<C:error/>
<m:human-readable errcode="200030">
Could not open the requested SVN filesystem
</m:human-readable>
</D:error>

Running 'svn up' and 'svn log' in command line on the server ends with
no error. Therefore, I assume it has something to do with apache, but I
have not touched any configuration files.
Here's a config:

----
LoadModule dav_module libexec/apache2/mod_dav.so
LoadModule dav_fs_module libexec/apache2/mod_dav_fs.so
LoadModule php5_module        libexec/apache2/libphp5.so
 
LoadModule suexec_module        libexec/apache2/mod_suexec.so
LoadModule dav_svn_module     libexec/apache2/mod_dav_svn.so
LoadModule authz_svn_module   libexec/apache2/mod_authz_svn.so
---
 
<VirtualHost 10.2.8.10:81>
ServerName crossbow
<Location />
        DAV svn
        SVNParentPath /usr/local/subversion/
        AllowOverride All
        # how to authenticate a user
        AuthType Basic
        AuthName "Subversion Repository"
        AuthUserFile /var/www/.sub_passwd
        AuthzSVNAccessFile /var/www/authz
        Require valid-user
 
</Location>
</VirtualHost>
---
 
******************************************************************************
Nothing contained in this e-mail shall (a) be considered a legally binding agreement, amendment or modification of any agreement with Marvel, each of which requires a fully executed agreement to be received by Marvel or (b) be deemed approval of any product, packaging, advertising or promotion material, which may only come from Marvel's Legal Department.
******************************************************************************
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!

attached mail follows:

I've restarted apache to no avail.

All permissions are correct and set to be read by apache...

P.S. Yep, we're using subversion for development, or at least we have
been using it until this upgrade :-(

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Friday, July 10, 2009 1:16 PM
To: Sholokhov, Vitaliy
Cc: users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3

On Fri, Jul 10, 2009 at 12:58:27PM -0400, Vitaliy Sholokhov wrote:
> Hello,
>
> I've just upgraded subversion software on the server from 1.4.* to
> 1.6.3 and ran 'svnadmin upgrade REPOS_PATH' without any problems.
> Now when I try to access repository via http connection, I constantly
> get the following error in tortoisesvn:
>
> "Could not open the requested SVN filesystem"
>
> In browser I get the following:
>
> <D:error>
> <C:error/>
> <m:human-readable errcode="200030">
> Could not open the requested SVN filesystem </m:human-readable>
> </D:error>
>
>
> Running 'svn up' and 'svn log' in command line on the server ends with

> no error. Therefore, I assume it has something to do with apache, but
> I have not touched any configuration files.

Have you restarted apache to make sure the new mod_dav_svn is loaded?

BTW from your address it looks like Marvel comics uses Subversion?
That's so cool! I've read the first 100 issues of Ultimate Spidey in 3
days straight :)

Stefan

******************************************************************************
Nothing contained in this e-mail shall (a) be considered a legally binding agreement, amendment or modification of any agreement with Marvel, each of which requires a fully executed agreement to be received by Marvel or (b) be deemed approval of any product, packaging, advertising or promotion material, which may only come from Marvel's Legal Department.
******************************************************************************
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!

attached mail follows:

Attached is an strace command, if it helps any.

-----Original Message-----
From: Vitaliy Sholokhov [mailto:vsholokhov_at_marvel.com]
Sent: Friday, July 10, 2009 1:25 PM
To: Stefan Sperling
Cc: users_at_subversion.tigris.org
Subject: RE: Upgrading from 1.4 to 1.6.3

I've restarted apache to no avail.

All permissions are correct and set to be read by apache...

P.S. Yep, we're using subversion for development, or at least we have
been using it until this upgrade :-(

> no error. Therefore, I assume it has something to do with apache, but
> I have not touched any configuration files.

Have you restarted apache to make sure the new mod_dav_svn is loaded?

BTW from your address it looks like Marvel comics uses Subversion?
That's so cool! I've read the first 100 issues of Ultimate Spidey in 3
days straight :)

Stefan

************************************************************************
******
Nothing contained in this e-mail shall (a) be considered a legally
binding agreement, amendment or modification of any agreement with
Marvel, each of which requires a fully executed agreement to be received
by Marvel or (b) be deemed approval of any product, packaging,
advertising or promotion material, which may only come from Marvel's
Legal Department.
************************************************************************
******
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2369862

To unsubscribe from this discussion, e-mail:
[users-unsubscribe_at_subversion.tigris.org].

attached mail follows:

I have a process in place that sanity checks SQL scripts. The user can take a list set of scripts which are then run against a series of databases to see if they run. The user is given feedback as they run. If the scripts fail, the user is told which database the script failed against.

I want to put that process in place as pre-commit hook. So far so good. But, I would like to provide real time progress to the user that did the commit.

Any ideas on how I could pull this off? AFAIK, the pre commit hook is only run on the server, and, there is no way for the user to see it. Correct?

Thanks,
Scott

attached mail follows:

This is all I get in the error log:

[Fri Jul 10 13:10:03 2009] [notice] Apache configured -- resuming normal
operations
[Fri Jul 10 13:10:09 2009] [error] [client 10.2.57.17] (20014)Error
string not specified yet: SQLite compiled for 3.6.14.2, but running with
3.3.7
[Fri Jul 10 13:10:09 2009] [error] [client 10.2.57.17] Could not fetch
resource information. [500, #0]
[Fri Jul 10 13:10:09 2009] [error] [client 10.2.57.17] Could not open
the requested SVN filesystem [500, #200030]
[Fri Jul 10 13:10:09 2009] [error] [client 10.2.57.17] Could not open
the requested SVN filesystem [500, #200030]

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Friday, July 10, 2009 1:34 PM
To: Sholokhov, Vitaliy
Cc: users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3

On Fri, Jul 10, 2009 at 01:24:42PM -0400, Vitaliy Sholokhov wrote:
> I've restarted apache to no avail.
>
> All permissions are correct and set to be read by apache...
>
> P.S. Yep, we're using subversion for development, or at least we have
> been using it until this upgrade :-(

I'm trying to hunt down the meaning of error code 20030 by looking at
the APR source code, but I can't find its meaning.

Can you find anything in the apache logs that might help diagnose the
problem?

Thanks,
Stefan

attached mail follows:

>I have a process in place that sanity checks SQL scripts. The user can take a list set of scripts which are then run against a series of databases to >see if they run. The user is given feedback as they run. If the scripts fail, the user is told which database the script failed against.

>I want to put that process in place as pre-commit hook. So far so good. But, I would like to provide real time progress to the user that did the >commit.

>Any ideas on how I could pull this off? AFAIK, the pre commit hook is only run on the server, and, there is no way for the user to see it. Correct?

Am I the only one that hears major warning bells going off here?

What does this script have to do with version control? It sounds like something that should be run on a build server. Or, perhaps it should be something done on the client first. Are you devs not following:

edit, update, TEST, commit workflow?

BOb

attached mail follows:

On Fri, Jul 10, 2009 at 13:15, Scott Vickery<svickery_at_cavucorp.com> wrote:
> I have a process in place that sanity checks SQL scripts. The user can take
> a list set of scripts which are then run against a series of databases to
> see if they run. The user is given feedback as they run. If the scripts
> fail, the user is told which database the script failed against.
>
> I want to put that process in place as pre-commit hook. So far so
> good. But, I would like to provide real time progress to the user that did
> the commit.
>
> Any ideas on how I could pull this off? AFAIK, the pre commit hook is only
> run on the server, and, there is no way for the user to see it. Correct?

Anytime a pre-comit hook script sends feedback to the user, it results
in a rejected commit. So you cannot give "real time progress" feedback
to the user.

Bob Archer is right, this should be done outside Subversion, maybe on
a build server as part of a CI process. Or better yet, by the user
*prior* to committing.

attached mail follows:

Hi!

Scott Vickery schrieb:
> I have a process in place that sanity checks SQL scripts. The user can
> take a list set of scripts which are then run against a series of
> databases to see if they run. The user is given feedback as they run.
> If the scripts fail, the user is told which database the script failed
> against.
>
> I want to put that process in place as pre-commit hook. So far so
> good. But, I would like to provide real time progress to the user that
> did the commit.
>
> Any ideas on how I could pull this off? AFAIK, the pre commit hook is
> only run on the server, and, there is no way for the user to see it.
> Correct?

As far as I know there is no possibility to pass intermediate output to
the svn client during a commit. But you can just collect the data and
return it at the end of the pre-commit-hook (in case the
pre-commit-hook fails).

Greetings,

Nico

attached mail follows:

There aren't any ".svn" folders under there. Our working copies reside
in completely different directories. Not sure why would it try reading
the '.svn' at all

[root_at_crossbow ~]# ls -la /usr/local/subversion/marvel
total 18
drwxrwxrwx 7 www www 512 Jul 10 12:15 .
drwxrwxrwx 9 www www 512 Jul 10 13:21 ..
-rwxrwxrwx 1 www www 229 Mar 18 2008 README.txt
drwxrwxrwx 2 www www 512 Sep 29 2008 conf
drwxrwxrwx 3 www www 512 Jul 8 2008 dav
drwxrwxrwx 7 www www 512 Jul 10 13:51 db
-rwxrwxrwx 1 www www 2 Jul 10 12:15 format
drwxrwxrwx 2 www www 512 Jan 30 15:30 hooks
drwxrwxrwx 2 www www 512 Mar 18 2008 locks

[root_at_crossbow ~]# ls -la /usr/local/subversion/marvelkids/
total 18
drwxrwxrwx 7 www www 512 Jul 10 12:15 .
drwxrwxrwx 9 www www 512 Jul 10 13:21 ..
-rwxrwxrwx 1 www www 229 Mar 19 2008 README.txt
drwxrwxrwx 2 www www 512 Mar 19 2008 conf
drwxrwxrwx 3 www www 512 Jul 9 2008 dav
drwxrwxrwx 6 www www 512 Jul 10 12:15 db
-rwxrwxrwx 1 root www 2 Jul 10 12:15 format
drwxrwxrwx 2 www www 512 Oct 8 2008 hooks
drwxrwxrwx 2 www www 512 Mar 19 2008 locks

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Friday, July 10, 2009 1:49 PM
To: Sholokhov, Vitaliy
Cc: users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3

On Fri, Jul 10, 2009 at 01:31:09PM -0400, Vitaliy Sholokhov wrote:
> Attached is an strace command, if it helps any.

I might be totally wrong, but this looks to me like mod_dav_svn was
trying to open a Subversion working copy rather than a Subversion
repository. E.g. why is a .svn directory in the list of direntries that
mod_dav_svn is reading? That is somewhat strange...

> getdirentries(25, {{d_fileno=4900111, d_reclen=12, d_type=DT_DIR,
> d_namlen=1, d_name="."} {d_fileno=4899577, d_reclen=12, d_type=DT_DIR,

> d_namlen=2, d_name=".."} {d_fileno=4900112, d_reclen=16,
> d_type=DT_DIR, d_namlen=4, d_name=".svn"} {d_fileno=4900127,
^^^^^^^^^^^^

You have an SVNParentPath directive in the mod_dav_svn config.
Any subdirectories of the directory specified there should be
repositories.

Stefan

attached mail follows:

I understand... and the answer is no. As you said, this runs server side, the only feed back you can give is to return something to STDERR when it compeletes.

BOb

From: Scott Vickery [mailto:svickery_at_cavucorp.com]
Sent: Friday, July 10, 2009 1:44 PM
To: Bob Archer; users_at_subversion.tigris.org
Subject: RE: Pre-commit hook

Thanks for the input, but, my question is not about my process (yes, devs test before commit). The question is whether I can provide feedback to the user from a pre-commit hook.

Thanks,
Scott

________________________________
From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
Sent: Friday, July 10, 2009 1:40 PM
To: Scott Vickery; users_at_subversion.tigris.org
Subject: RE: Pre-commit hook
>I have a process in place that sanity checks SQL scripts. The user can take a list set of scripts which are then run against a series of databases to >see if they run. The user is given feedback as they run. If the scripts fail, the user is told which database the script failed against.

>I want to put that process in place as pre-commit hook. So far so good. But, I would like to provide real time progress to the user that did the >commit.

>Any ideas on how I could pull this off? AFAIK, the pre commit hook is only run on the server, and, there is no way for the user to see it. Correct?

Am I the only one that hears major warning bells going off here?

edit, update, TEST, commit workflow?

BOb

attached mail follows:

Thanks for the input, but, my question is not about my process (yes, devs test before commit). The question is whether I can provide feedback to the user from a pre-commit hook.

Thanks,
Scott

________________________________
From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
Sent: Friday, July 10, 2009 1:40 PM
To: Scott Vickery; users_at_subversion.tigris.org
Subject: RE: Pre-commit hook

>I want to put that process in place as pre-commit hook. So far so good. But, I would like to provide real time progress to the user that did the >commit.

>Any ideas on how I could pull this off? AFAIK, the pre commit hook is only run on the server, and, there is no way for the user to see it. Correct?

Am I the only one that hears major warning bells going off here?

edit, update, TEST, commit workflow?

BOb

attached mail follows:

Great. Thanks for the input.

Scott

-----Original Message-----
From: Andy Levy [mailto:andy.levy_at_gmail.com]
Sent: Friday, July 10, 2009 1:48 PM
To: Scott Vickery
Cc: users_at_subversion.tigris.org
Subject: Re: Pre-commit hook

On Fri, Jul 10, 2009 at 13:15, Scott Vickery<svickery_at_cavucorp.com> wrote:
> I have a process in place that sanity checks SQL scripts. The user
> can take a list set of scripts which are then run against a series of
> databases to see if they run. The user is given feedback as they run.
> If the scripts fail, the user is told which database the script failed against.
>
> I want to put that process in place as pre-commit hook. So far so
> good. But, I would like to provide real time progress to the user
> that did the commit.
>
> Any ideas on how I could pull this off? AFAIK, the pre commit hook is
> only run on the server, and, there is no way for the user to see it. Correct?

Anytime a pre-comit hook script sends feedback to the user, it results in a rejected commit. So you cannot give "real time progress" feedback to the user.

Bob Archer is right, this should be done outside Subversion, maybe on a build server as part of a CI process. Or better yet, by the user
*prior* to committing.

attached mail follows:

I would prefer a CI system such as Hudson that polls svn and checks
out the scripts and runs them against your database.

using a pre-commit or post-commit hook is tight coupling your CI with
your source control aka a bad thing

what happens when the database is down and you've left on holidays for
two weeks? nobody can commit

Sent from my [rhymes with myPod] ;-)

On 10 Jul 2009, at 18:15, Scott Vickery <svickery_at_cavucorp.com> wrote:

> I have a process in place that sanity checks SQL scripts. The user
> can take a list set of scripts which are then run against a series
> of databases to see if they run. The user is given feedback as they
> run. If the scripts fail, the user is told which database the
> script failed against.
>
> I want to put that process in place as pre-commit hook. So far so
> good. But, I would like to provide real time progress to the user
> that did the commit.
>
> Any ideas on how I could pull this off? AFAIK, the pre commit hook
> is only run on the server, and, there is no way for the user to see
> it. Correct?
>
> Thanks,
> Scott

attached mail follows:

[root_at_crossbow /usr/local/subversion]# find / -type f -name "libsvn_*"
-print
/usr/local/lib/libsvn_subr-1.la
/usr/local/lib/libsvn_subr-1.a
/usr/local/lib/libsvn_delta-1.so.0
/usr/local/lib/libsvn_delta-1.la
/usr/local/lib/libsvn_repos-1.la
/usr/local/lib/libsvn_repos-1.a
/usr/local/lib/libsvn_ra_local-1.so.0
/usr/local/lib/libsvn_ra_local-1.la
....
-----

Here's what I did:
I symlinked "/usr/local/lib/libsvn_*" to "/usr/local/apache2/lib/" and
re-run the strace. Output is attached. Repositories are still not
avaliable via http.

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Friday, July 10, 2009 2:06 PM
To: Sholokhov, Vitaliy
Cc: users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3

On Fri, Jul 10, 2009 at 01:53:37PM -0400, Vitaliy Sholokhov wrote:
> There aren't any ".svn" folders under there. Our working copies reside

> in completely different directories. Not sure why would it try reading

> the '.svn' at all

Hmm... well OK let's not get distracted by this, maybe there's a reason
for the .svn directory which is unrelated to the problem.

One other thing I can see from the strace output is that you have the
directory /path/to/svn/bin in your path. I would assume that you
installed 1.6.3 into /path/to/svn ? If so, apache is most likely loading
a wrong set of Subversion libraries, since all the libsvn_* files it is
loading come from /usr/local/lib.

Stefan

attached mail follows:

We are using CruiseControl for a similar thing.

What I am trying to do it to prevent faulty scripts get getting into source control in the first place. Developers test against a single database, but, we have 100's of databases. Right now, there is a process that is done on the side outside of version control to test the scripts against all databases. I am trying to integrate that process into version control to make check-ins part of our process instead of an afterthought.

Basically, I trying to reduce overhead on the developer. But, as has been pointed out, this is either a pre checkin activity OR a build issue.

Thanks,
Scott

I would prefer a CI system such as Hudson that polls svn and checks out the scripts and runs them against your database.

using a pre-commit or post-commit hook is tight coupling your CI with your source control aka a bad thing

what happens when the database is down and you've left on holidays for two weeks? nobody can commit

Sent from my [rhymes with myPod] ;-)

On 10 Jul 2009, at 18:15, Scott Vickery <svickery_at_cavucorp.com<mailto:svickery_at_cavucorp.com>> wrote:

I want to put that process in place as pre-commit hook. So far so good. But, I would like to provide real time progress to the user that did the commit.

Any ideas on how I could pull this off? AFAIK, the pre commit hook is only run on the server, and, there is no way for the user to see it. Correct?

Thanks,
Scott

attached mail follows:

On Fri, Jul 10, 2009 at 14:11, Scott Vickery<svickery_at_cavucorp.com> wrote:
> We are using CruiseControl for a similar thing.
>
> What I am trying to do it to prevent faulty scripts get getting into source
> control in the first place. Developers test against a single database, but,
> we have 100's of databases. Right now, there is a process that is done on
> the side outside of version control to test the scripts against all
> databases. I am trying to integrate that process into version control to
> make check-ins part of our process instead of an afterthought.
>
> Basically, I trying to reduce overhead on the developer. But, as has been
> pointed out, this is either a pre checkin activity OR a build issue.

Another thing to consider - how long will that check against hundreds
of databases take to execute? While that script is executing, no one
else will be able to commit. Such a process would be a very easy means
by which a developer could effectively DoS your repository and/or the
databases.

attached mail follows:

The only thing I can think of is to have your scripts be in a svn copy/branch of the main trunk. Have your build system check the scripts on commit and if no errors occur it can merge them to trunk, or just copy the scripts to trunk and commit them that way.

They would still be in source control but not in trunk until they have been verified.

BOb

From: Scott Vickery [mailto:svickery_at_cavucorp.com]
Sent: Friday, July 10, 2009 2:12 PM
To: Stephen Connolly
Cc: users_at_subversion.tigris.org
Subject: RE: Pre-commit hook

We are using CruiseControl for a similar thing.

Basically, I trying to reduce overhead on the developer. But, as has been pointed out, this is either a pre checkin activity OR a build issue.

Thanks,
Scott

________________________________
From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Friday, July 10, 2009 2:02 PM
To: Scott Vickery
Cc: users_at_subversion.tigris.org
Subject: Re: Pre-commit hook
I would prefer a CI system such as Hudson that polls svn and checks out the scripts and runs them against your database.

using a pre-commit or post-commit hook is tight coupling your CI with your source control aka a bad thing

what happens when the database is down and you've left on holidays for two weeks? nobody can commit

Sent from my [rhymes with myPod] ;-)

On 10 Jul 2009, at 18:15, Scott Vickery <svickery_at_cavucorp.com<mailto:svickery_at_cavucorp.com>> wrote:
I have a process in place that sanity checks SQL scripts. The user can take a list set of scripts which are then run against a series of databases to see if they run. The user is given feedback as they run. If the scripts fail, the user is told which database the script failed against.

I want to put that process in place as pre-commit hook. So far so good. But, I would like to provide real time progress to the user that did the commit.

Any ideas on how I could pull this off? AFAIK, the pre commit hook is only run on the server, and, there is no way for the user to see it. Correct?

Thanks,
Scott

attached mail follows:

Nope. Here's a new error that just started popping (regardless if
authorization enabled or not). I've went to "Repo-browser" in
tortoisesvn and noticed the following in apache log:

[Fri Jul 10 14:41:44 2009] [notice] Apache configured -- resuming normal
operations
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] (20014)Error
string not specified yet: SQLite compiled for 3.6.14.2, but running with
3.3.7
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not fetch
resource information. [500, #0]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not open
the requested SVN filesystem [500, #200030]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not open
the requested SVN filesystem [500, #200030]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not fetch
resource information. [403, #0]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] (2)No such file
or directory: The URI does not contain the name of a repository. [403,
#190001]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] (20014)Error
string not specified yet: SQLite compiled for 3.6.14.2, but running with
3.3.7
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not fetch
resource information. [500, #0]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not open
the requested SVN filesystem [500, #200030]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not open
the requested SVN filesystem [500, #200030]
[Fri Jul 10 14:41:50 2009] [error] [client 10.2.57.17] Could not fetch
resource information. [403, #0]

I'm going to re-install subversion see if it'll pick up the updated
sqlite3 libraries correctly.

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Friday, July 10, 2009 2:35 PM
To: Sholokhov, Vitaliy
Cc: users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3

On Fri, Jul 10, 2009 at 02:20:18PM -0400, Vitaliy Sholokhov wrote:
> [root_at_crossbow /usr/local/subversion]# find / -type f -name "libsvn_*"
> -print
> /usr/local/lib/libsvn_subr-1.la
> /usr/local/lib/libsvn_subr-1.a
> /usr/local/lib/libsvn_delta-1.so.0
> /usr/local/lib/libsvn_delta-1.la
> /usr/local/lib/libsvn_repos-1.la
> /usr/local/lib/libsvn_repos-1.a
> /usr/local/lib/libsvn_ra_local-1.so.0
> /usr/local/lib/libsvn_ra_local-1.la
> ....
> -----
>
> Here's what I did:
> I symlinked "/usr/local/lib/libsvn_*" to "/usr/local/apache2/lib/" and

> re-run the strace. Output is attached. Repositories are still not
> avaliable via http.

Let's just assume for a minute that the basics (loading correct
libraries etc.) work fine.

Can you successfully access your repositories if you temporarily disable
path-based authorisation (authz) in the apache config?
If so, please see
http://subversion.tigris.org/issues/show_bug.cgi?id=3242

Stefan

attached mail follows:

On Jul 10, 2009, at 06:12, David Aldrich wrote:

>> Do you have files in your other repositories which have .doc
>> extensions but *aren't* MS Word documents?
>
> No
>
>> I can't imagine a situation
>> where you wouldn't want to set the mime-type and needs-lock on an MS
>> Word file.
>
> Well, I would agree that this is recommended practice. I just
> didn't want to impose the practice on everyone. I will check
> whether we can do this as a company-wide policy but, meanwhile, is
> there anyway of defining the auto-prop on a per repository basis?

No, there is not, not within a single config file.

You can define multiple config files, and point svn at different
config files per svn command invocation with the --config-dir or --
config-option switches. But you would have to remember to use that
option for each svn command you issue against whatever repository it
is, so that's hardly convenient.

attached mail follows:

On Jul 10, 2009, at 12:15, Scott Vickery wrote:

> I have a process in place that sanity checks SQL scripts. The user
> can take a list set of scripts which are then run against a series
> of databases to see if they run. The user is given feedback as
> they run. If the scripts fail, the user is told which database the
> script failed against.
>
> I want to put that process in place as pre-commit hook. So far so
> good. But, I would like to provide real time progress to the user
> that did the commit.
>
> Any ideas on how I could pull this off? AFAIK, the pre commit hook
> is only run on the server, and, there is no way for the user to see
> it. Correct?

If you want to send non-failure status messages from your pre-commit
hook script to the user, you have to use a roundabout way. One way is
email, if you have a known mapping between the ID the user commits to
the repository as and their email address. Another more immediate way
would be an instant messaging client, if your developers use one and
you can map their repository ID to their instant messaging handle.

attached mail follows:

> > I have a process in place that sanity checks SQL scripts. The user
> > can take a list set of scripts which are then run against a series
> > of databases to see if they run. The user is given feedback as
> > they run. If the scripts fail, the user is told which database the
> > script failed against.
> >
> > I want to put that process in place as pre-commit hook. So far so
> > good. But, I would like to provide real time progress to the user
> > that did the commit.
> >
> > Any ideas on how I could pull this off? AFAIK, the pre commit hook
> > is only run on the server, and, there is no way for the user to see
> > it. Correct?
>
> If you want to send non-failure status messages from your pre-commit
> hook script to the user, you have to use a roundabout way. One way is
> email, if you have a known mapping between the ID the user commits to
> the repository as and their email address. Another more immediate way
> would be an instant messaging client, if your developers use one and
> you can map their repository ID to their instant messaging handle.

Hey, nice idea. You could have your build server tweet status update messages and your devs that cared could follow the build servers account.

Hmmmm.....???!!!!

BOb

attached mail follows:

I was installing all these packages through FreeBSD ports collection,
but I'm about to do this the good ol' manual way now...

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Friday, July 10, 2009 2:52 PM
To: Sholokhov, Vitaliy
Cc: users_at_subversion.tigris.org
Subject: Re: Upgrading from 1.4 to 1.6.3

On Fri, Jul 10, 2009 at 02:42:04PM -0400, Vitaliy Sholokhov wrote:
> I'm going to re-install subversion see if it'll pick up the updated
> sqlite3 libraries correctly.

If you have the SQlite source code tree handy, try passing the following
to Subversion's configure script in order to avoid linking against a
shared library of sqlite:

--with-sqlite=".../sqlite-3.6.14.2/sqlite3.c"

Where ... is the path where you unpacked the SQlite sources.

Stefan

attached mail follows:

On Jul 10, 2009, at 02:49, haiqing wrote:

> I found a bug about svn .
> Iis it really a bug? hoping for yours advices.
>
> MY svn message are:
>
> 1:http://17*.*.*.*/svn/test_svn_1,has 5files

Did you mean http://1*.*.*.*/svn/ro45/branches/test_svn_1 as below,
or is this a different location than below?

> └─test_svn_1
> B.png
> a.png
> f.png
> steps:
> 1: svn delete B.png (success)
> 2: svn add b.png(success)
> 3: svn commit -m "add b.png" b.png(success)
> 4: in other directory,do: svn co http://1*.*.*.*/svn/ro45/branches/
> test_svn_1 (fail)
>
> result:
> the workcopy directory was locked,and can not cleanup success.
> A test_svn_1\a.png
> A test_svn_1\B.png

If this is the same repository location you deleted B.png from above,
why is it still there?

> A test_svn_1\b.png
> A test_svn_1\f.png
> svn: In directory 'test_svn_1'
> svn: Can't open file 'test_svn_1\.svn\tmp\text-base\b.png.svn-
> base': System can not find the file.
>
> 5:come into the workcopy,and execute : svn up
> result:
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
> 6: svn cleanup
> result:
> svn: In directory '.'
> svn: Error processing command 'modify-wcprop' in '.'
> svn: 'a.png' is not under version control
>
> That's all .
> I think it's svn's bug.
> what do everyone think ?

If B.png and b.png exist in the same place in the repository, then
the above error is what you will get if you try to check this place
out to a case-insensitive file system.

If you need to support case-insensitive file systems (and most of us
do, since the default file systems on Windows and Mac OS X are case-
insensitive) then you should not commit files whose names differ only
by case, and you should decide on the correct case of each filename
at the beginning and not change it later, because it can cause some
problems. See the FAQ for the problems it can cause and the
workarounds you may have to use to deal with them:

http://subversion.tigris.org/faq.html#case-change

attached mail follows:

On Jul 10, 2009, at 13:58, Bob Archer wrote:

>>> I have a process in place that sanity checks SQL scripts. The user
>>> can take a list set of scripts which are then run against a series
>>> of databases to see if they run. The user is given feedback as
>>> they run. If the scripts fail, the user is told which database the
>>> script failed against.
>>>
>>> I want to put that process in place as pre-commit hook. So far so
>>> good. But, I would like to provide real time progress to the user
>>> that did the commit.
>>>
>>> Any ideas on how I could pull this off? AFAIK, the pre commit hook
>>> is only run on the server, and, there is no way for the user to see
>>> it. Correct?
>>
>> If you want to send non-failure status messages from your pre-commit
>> hook script to the user, you have to use a roundabout way. One way is
>> email, if you have a known mapping between the ID the user commits to
>> the repository as and their email address. Another more immediate way
>> would be an instant messaging client, if your developers use one and
>> you can map their repository ID to their instant messaging handle.
>
> Hey, nice idea. You could have your build server tweet status
> update messages and your devs that cared could follow the build
> servers account.

If this is an open source project, sure, using Twitter could be
interesting too.

In my instant messaging suggestion I was thinking more of corporate
users who wouldn't want to broadcast information about their private
projects. They might instead set up a jabber server, for example,
inside the corporate firewall, and use it to broadcast messages.

attached mail follows:

I manually re-compiled subversion linking to the sqlite3 source and it
helped with the error and http access. So, in regards to the issue at
hand, this has been resolved.
But now I'm getting new error when running working copy update on any of
the developer branches or trunk:

"Repository moved permanently to 'http://crossbow:81/marvel/'; please
relocate"

I've upgraded the repositories via 'svnadmin upgrade' and tortoisesvn is
the fresh download...

-----Original Message-----
From: Vitaliy Sholokhov [mailto:vsholokhov_at_marvel.com]
Sent: Friday, July 10, 2009 3:01 PM
To: users_at_subversion.tigris.org
Subject: RE: Upgrading from 1.4 to 1.6.3

I was installing all these packages through FreeBSD ports collection,
but I'm about to do this the good ol' manual way now...

On Fri, Jul 10, 2009 at 02:42:04PM -0400, Vitaliy Sholokhov wrote:
> I'm going to re-install subversion see if it'll pick up the updated
> sqlite3 libraries correctly.

If you have the SQlite source code tree handy, try passing the following
to Subversion's configure script in order to avoid linking against a
shared library of sqlite:

--with-sqlite=".../sqlite-3.6.14.2/sqlite3.c"

Where ... is the path where you unpacked the SQlite sources.

Stefan

************************************************************************
******
Nothing contained in this e-mail shall (a) be considered a legally
binding agreement, amendment or modification of any agreement with
Marvel, each of which requires a fully executed agreement to be received
by Marvel or (b) be deemed approval of any product, packaging,
advertising or promotion material, which may only come from Marvel's
Legal Department.
************************************************************************
******
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2370015

To unsubscribe from this discussion, e-mail:
[users-unsubscribe_at_subversion.tigris.org].

attached mail follows:

> -----Original Message-----
> From: Vitaliy Sholokhov [mailto:vsholokhov_at_marvel.com]
> Sent: Friday, July 10, 2009 3:27 PM
> To: users_at_subversion.tigris.org
> Subject: RE: Upgrading from 1.4 to 1.6.3
>
> I manually re-compiled subversion linking to the sqlite3 source and it
> helped with the error and http access. So, in regards to the issue at
> hand, this has been resolved.
> But now I'm getting new error when running working copy update on any
> of
> the developer branches or trunk:
>
> "Repository moved permanently to 'http://crossbow:81/marvel/'; please
> relocate"
>
> I've upgraded the repositories via 'svnadmin upgrade' and tortoisesvn
> is
> the fresh download...

So is the repository path different now than it was on the 1.4 version?

If so do what the message says. Relocate will point a WC to a different location for the same repository UUID.

BOb

attached mail follows:

Nope. Repository path is exactly the same. Nothing has changed since the
upgrade

-----Original Message-----
From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
Sent: Friday, July 10, 2009 3:58 PM
To: Sholokhov, Vitaliy; users_at_subversion.tigris.org
Subject: RE: Upgrading from 1.4 to 1.6.3

> helped with the error and http access. So, in regards to the issue at
> hand, this has been resolved.
> But now I'm getting new error when running working copy update on any
> of the developer branches or trunk:
>
> "Repository moved permanently to 'http://crossbow:81/marvel/'; please
> relocate"
>
> I've upgraded the repositories via 'svnadmin upgrade' and tortoisesvn
> is the fresh download...

So is the repository path different now than it was on the 1.4 version?

If so do what the message says. Relocate will point a WC to a different
location for the same repository UUID.

BOb

attached mail follows:

I think there might have been some case sensitivity issues resolved between 1.4 and 1.6. Just do the relocate and I expect you will be ok.

BOb

> -----Original Message-----
> From: Sholokhov, Vitaliy [mailto:vsholokhov_at_marvel.com]
> Sent: Friday, July 10, 2009 4:10 PM
> To: Bob Archer; users_at_subversion.tigris.org
> Subject: RE: Upgrading from 1.4 to 1.6.3
>
> Nope. Repository path is exactly the same. Nothing has changed since
> the
> upgrade
>
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: Friday, July 10, 2009 3:58 PM
> To: Sholokhov, Vitaliy; users_at_subversion.tigris.org
> Subject: RE: Upgrading from 1.4 to 1.6.3
>
> > -----Original Message-----
> > From: Vitaliy Sholokhov [mailto:vsholokhov_at_marvel.com]
> > Sent: Friday, July 10, 2009 3:27 PM
> > To: users_at_subversion.tigris.org
> > Subject: RE: Upgrading from 1.4 to 1.6.3
> >
> > I manually re-compiled subversion linking to the sqlite3 source and
> it
>
> > helped with the error and http access. So, in regards to the issue at
> > hand, this has been resolved.
> > But now I'm getting new error when running working copy update on any
> > of the developer branches or trunk:
> >
> > "Repository moved permanently to 'http://crossbow:81/marvel/'; please
> > relocate"
> >
> > I've upgraded the repositories via 'svnadmin upgrade' and tortoisesvn
> > is the fresh download...
>
> So is the repository path different now than it was on the 1.4 version?
>
> If so do what the message says. Relocate will point a WC to a different
> location for the same repository UUID.
>
> BOb
>
> ***********************************************************************
> *******
> Nothing contained in this e-mail shall (a) be considered a legally
> binding agreement, amendment or modification of any agreement with
> Marvel, each of which requires a fully executed agreement to be
> received by Marvel or (b) be deemed approval of any product, packaging,
> advertising or promotion material, which may only come from Marvel's
> Legal Department.
> ***********************************************************************
> *******
> THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!
>

attached mail follows:

Cool ideas from all.

At the end of the day, I think I will have to keep this as a separate process. I think....

Scott

-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2009b_at_ryandesign.com]
Sent: Friday, July 10, 2009 3:06 PM
To: Bob Archer
Cc: Scott Vickery; users_at_subversion.tigris.org
Subject: Re: Pre-commit hook

On Jul 10, 2009, at 13:58, Bob Archer wrote:

>>> I have a process in place that sanity checks SQL scripts. The user
>>> can take a list set of scripts which are then run against a series
>>> of databases to see if they run. The user is given feedback as they
>>> run. If the scripts fail, the user is told which database the
>>> script failed against.
>>>
>>> I want to put that process in place as pre-commit hook. So far so
>>> good. But, I would like to provide real time progress to the user
>>> that did the commit.
>>>
>>> Any ideas on how I could pull this off? AFAIK, the pre commit hook
>>> is only run on the server, and, there is no way for the user to see
>>> it. Correct?
>>
>> If you want to send non-failure status messages from your pre-commit
>> hook script to the user, you have to use a roundabout way. One way is
>> email, if you have a known mapping between the ID the user commits to
>> the repository as and their email address. Another more immediate way
>> would be an instant messaging client, if your developers use one and
>> you can map their repository ID to their instant messaging handle.
>
> Hey, nice idea. You could have your build server tweet status update
> messages and your devs that cared could follow the build servers
> account.

If this is an open source project, sure, using Twitter could be interesting too.

In my instant messaging suggestion I was thinking more of corporate users who wouldn't want to broadcast information about their private projects. They might instead set up a jabber server, for example, inside the corporate firewall, and use it to broadcast messages.

attached mail follows:

i am a complete newbie to linux and svn - and i need help!!! i've been
looking at this for days and have no idea what is wrong.

i have a linux server, architecture i386, kernel version 2.6.18-028stab062.3

apache server version: Apache/2.2.11 (Unix) mod_ssl/2.2.11
OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_bwlimited/1.4

i installed CollabNetSubversion server/client v1.6.3-2 in
/opt/CollabNet_Subversion

svn, version 1.6.3 (r38063)

compiled Jun 23 2009, 16:30:19

Subversion is open source software, see http://subversion.tigris.org/

This product includes software developed by CollabNet (
<http://www.collab.net/> http://www.Collab.Net/).

svnserve, version 1.6.3 (r38063)

compiled Jun 23 2009, 16:30:19

Subversion is open source software, see http://subversion.tigris.org/

This product includes software developed by CollabNet
(http://www.Collab.Net/).

The following repository back-end (FS) modules are available:

* fs_fs : Module for working with a plain file (FSFS) repository.

Cyrus SASL authentication is available.

i created a repository in /home/stacy/svn/repos

svnadmin create /svn/repos

i imported the files

svn import -d -r /home/stacy/svn

first I ran svnserve as a daemon because that is the simplest approach, and
it worked. i was able to remotely access my repository and create a working
set on my local pc using tortoiseSVN.

then i decided that i should really be running it with sasl authentication.

so i am trying to run svnserve via xinetd with SASL authentication

in /home/stacy/svn/repos/conf/svnserve.conf:

[general]

realm = stacyrealm

anon-access = none

auth-access = write

[sasl]

use-sasl = true

min-encryption = 128

max-encryption = 256

in /etc/services, the svn entries exist:

svn 3690/tcp # Subversion

svn 3690/udp # Subversion

in /usr/lib/sas12/svn.conf:

pwcheck_method: auxprop

auxprop_plugin: sasldb

sasldb_path: /etc/my_sasldb

mech_list: DIGEST-MD5

listing users in the my_sasldb:

[root_at_host etc]# sasldblistusers2 -f /etc/my_sasldb

stacy_at_stacyrealm: userPassword

jim_at_stacyrealm: userPassword

confirmed that the right owner of the my_sasldb is root

[root_at_host /]# ls -l /etc/my_sasldb

-rw-r--r-- 1 root root 12288 Jul 9 02:03 /etc/my_sasldb

in /etc/xinetd.d, created a file svn that contains

# default: on

# description: Subversion server for the svn protocol

service svn

{

disable = no

port = 3690

socket_type = stream

protocol = tcp

wait = no

user = root

server = /opt/CollabNet_Subversion/bin/svnserve

server_args = -i -r /home/stacy/svn

}

confirmed xinetd is running

Jul 10 10:12:10 host xinetd[24172]: xinetd Version 2.3.14 started with
libwrap loadavg labeled-networking options compiled in.

Jul 10 10:12:10 host xinetd[24172]: Started working: 2 available services

when I try to access the repository remotely, i use tortoiseSVN and use URL:

svn://host.stacyshost.com/repos/drupal-6.12

in the sys log I see that the 'svn' service tries to start svnserve, but
then I see a failure

Jul 10 10:12:27 host xinetd[24172]: START: svn pid=24393 from=##.##.##.###

Jul 10 10:12:27 host svnserve: auxpropfunc error invalid parameter supplied

and I don't ever see svnserve as a process running.

in the tortoiseSVN repository browser, i am forever prompted to
authenticate, just repeatedly prompts for id and password, i stopped
entering it after 15 times and finally just cancelled.

is there any other logs I can look at that would indicate my issue?

PLEASE HELP!
Received on 2009-07-11 09:16:55 CEST

This message: [ Message body ]
Next message: haiqing: "Fw:Re:Re: SVN bug"
Previous message: Nico Kadel-Garcia: "Re: RHEL4 x86_64 issues with 'SASL' and difficulty installing i386 version on RHEL4 x86_64."

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]