Re: How to recover from "Found malformed header in revision file"?

[Mariusz Droździel]

On 4 March 2010 03:24, Steven Roussey  wrote:

> I also tried svnadmin recover which did not work, and fsfsverify.py. I have a
> few working copies around that are ok (I think) -- is there a way to use that 
> to
> fix the repository?

Check out "Corrupted FSFS commit" and "Broken Revision in FSFS Repo"
threads from few days ago. I think me and Martin had very similiar
problem and solved it out with svnsync + access control over webdav.

-- 
Mariusz Drozdziel

Re: Perl can't find my libraries when run via the subversion post-commit script

[David Weintraub]

On Wed, Mar 3, 2010 at 3:15 PM, Craig Thayer  wrote:
> I am at a loss as to why my perl script cannot find my libraries when
> invoked by the subversion post-commit script.  My script runs just fine when
> invoked manually in a terminal window.  I’m aware that the subversion
> post-commit script runs with no environment defined, but the error I’m
> getting (below) makes no sense since the module perl claims it can’t find
> (Log.pm) is, in fact, in the ‘/root/perl5/lib’ directory which is clearly
> listed in the @INC array.

Have you tried logging into the server as the user that runs
Subversion and tried running the Perl script as that user (and not as
part of the hook)? You might find the error when you try to execute as
the user that is running the Subversion server.

It is obvious that the Perl program is including the directories you
want to include in the @INC array, so the problem is not in the use
lib statements.

I wonder if there is a permission issue going on -- especially since
these are not standard Perl directories.

-- 
David Weintraub
qazw...@gmail.com

Re: How to recover from "Found malformed header in revision file"?

[Steven Roussey]

Steven Roussey  network54.com> writes:
>
> How to recover from "Found malformed header in revision file"?
>
> > svn commit myfile
> Sendingmyfile
> Transmitting file data .svn: Commit failed (details follow):
> svn: Corrupt node-revision '0-484.0-123.r993/92'
> svn: Found malformed header in revision file
>
> So I tried create a dump file:
> > svnadmin dump /site/svn/ > dumpsvn
> * Dumped revision 0.
> ...
> * Dumped revision 987.
> svnadmin: Corrupt representation '988 0 8767 8749
> 17d4a0cc3e480c0c64dd8107a1854b7f'
> svnadmin: Malformed representation header
>
> So it started a long long time ago... :(
>
> > svn --version
> svn, version 1.5.1 (r32289)
>   compiled Aug  7 2009, 01:15:13
>
> This the version of svn from ubuntu for whatever version is running on
> that machine.
>
> If a dump of the repo doesn't work, what next???
>
>

I also tried svnadmin recover which did not work, and fsfsverify.py. I have a
few working copies around that are ok (I think) -- is there a way to use that to
fix the repository?

Steven Roussey
Network54 Corp.

How to use txdelta_window?

[Alexey Neyman]

Hi all,

I am trying to check for some content changes in the pre-commit script,
and for that I am trying to employ the apply_textdelta method in the
editor. From the comments in the code (e.g. in python bindings), I
understand that the "window handler" callback should be called
repeatedly and the last call would pass None (NULL in C) as the window
pointer.

However that does not seem to be the case. I tried creating the
following editor and invoking it from pre-commit scripts:

  def add_file(self, path, parent_baton, copyfrom_path, copyfrom_revision, 
file_pool):
if copyfrom_path is not None:
  sys.stderr.write(("@@ add_file %s (from %s:%d)\n" % (path, copyfrom_path, 
copyfrom_rev)))
else:
  sys.stderr.write(("@@ add_file %s\n" % (path)))
return [ path ]

  def apply_textdelta(self, file_baton, base_checksum):
sys.stderr.write(("@@ apply_textdelta to %s\n" % (file_baton[0])))
def winhnd(window, btn=file_baton, rcv=self):
  if window is not None:
sys.stderr.write(("@@ delta_window on %s - not null\n" % (btn[0])))
  else:
sys.stderr.write(("@@ delta_window on %s - null\n" % (btn[0])))
return winhnd

  def open_file(self, path, parent_baton, base_revision, file_pool):
sys.stderr.write(("@@ open_file %s\n" % (path)))
return [ path ]

  def close_file(self, file_baton, text_checksum):
sys.stderr.write(("@@ close_file %s\n" % (file_baton[0])))
return

With that script, I get the output as below:

@@ open_file foo/bar1
@@ apply_textdelta to foo/bar1
@@ delta_window on foo/bar1 - null
@@ close_file foo/bar1
@@ open_file foo/bar2
@@ apply_textdelta to foo/bar2
@@ delta_window on foo/bar2 - null
@@ close_file foo/bar2

That is, the "window handler" is always called with None object as
the text delta. Am I doing something wrong? Could the change content
be accessed from the pre-commit script?

Regards,
Alexey.

Perl can't find my libraries when run via the subversion post-commit script

[Craig Thayer]

I am at a loss as to why my perl script cannot find my libraries when invoked 
by the subversion post-commit script.  My script runs just fine when invoked 
manually in a terminal window.  I'm aware that the subversion post-commit 
script runs with no environment defined, but the error I'm getting (below) 
makes no sense since the module perl claims it can't find (Log.pm) is, in fact, 
in the '/root/perl5/lib' directory which is clearly listed in the @INC array.

The problem is most likely a perl issue, but since the problem only occurs when 
my script is run via the subversion post-commit operation I'm hoping that 
someone else has run into this issue with subversion hooks executing a perl 
script and can enlighten me as to what I'm missing here.  It acts like perl is 
compiling the 'use' statements BEFORE it compiles the BEGIN section-which  
comes first.

Here is the error reported by the commit operation when it runs the post-commit 
script (which calls my svn-post-commit.pl script):
'post-commit' hook failed with error output:
Can't locate Log.pm in @INC (@INC contains: lib ../lib /root/perl5/lib 
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi 
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl 
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi 
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl 
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at 
/var/svn/repos/cirrus/hooks/svn-post-commit.pl line 96.
BEGIN failed--compilation aborted at 
/var/svn/repos/cirrus/hooks/svn-post-commit.pl line 96.

My script adds the path  '/root/perl5/lib' to the @INC array in the BEGIN 
section and my 'use Log' statement is in the main body after the BEGIN section. 
 I've tried several different methods for trying to get perl to find my 
libraries to no avail (including exporting the PERL5LIB EV in the post-commit 
script before calling my script and using the 'require' function-but this 
creates a whole new set of problems with libraries included by the libraries 
and I don't want to have to hard code paths to libraries in all my modules).  
And I don't want to place our libraries in one of the perl library paths-which 
perl seems to have no trouble finding libraries installed with it package 
(e.g., File::Basename, Net::SMTP, etc.).

post-commit script called by subversion commit:
REPOS="$1"
REV="$2"
/var/svn/repos/cirrus/hooks/svn-post-commit.pl "$REPOS" "$REV"

Snippet of my svn-post-commit.pl perl script called via the post-commit script:
use strict;
use warnings;
use File::Basename;
use Getopt::Long;
use Net::SMTP;
BEGIN {
   use lib "/root/perl5/lib";
   use lib "../lib";
   use lib "lib";
}

use Log;
use Singleton;
use Timestamp;

System information:
Server info:
CentOS  2.6.18-164.6.1.el5 x86_64 x86_64 x86_64 GNU/Linux
Subversion v1.4.2
Perl v5.8.8

Client Info:
Subversion Client: TortoiseSVN 1.6.7, Build 18415 - 64 Bit , 2010/01/22 17:55:06
Commit operation was performed from my Windows 7 machine, but the subversion 
repository and hook scripts are on a Linux server.

Any help would be greatly appreciated!

Re: Tigris binary packages for Windows

[Mark Phippard]

On Wed, Mar 3, 2010 at 6:28 PM,   wrote:

> I don't see any showstoppers either.  We can all adapt.  In fact,
> we were previously using the Collabnet installers, and (in this case
> unfortunately) moved to the tigris ones in the past for various reasons.
>
> Most likely, we will repackage something internally, which we
> do for most other apps anyway.  (I build our solaris and linux
> versions from scratch with all dependencies, so I should just
> get off my lazy butt and build Windows too...)

Just fyi, but the CollabNet installer can also be installed Silent by
using the /S switch and accepts a command line option to specify the
directory to install to.  The next version (next SVN release) will
also support an "answer file" so that you can provide the values for
any of the options in the UI of the installer.  In the current version
(and in the absence of this file) we just choose a default.  These
features came from users asking for them, as was suggested earlier.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: Tigris binary packages for Windows

[kmradke]

Bob Archer  wrote on 03/03/2010 04:42:49 PM:
> > Bob Archer  wrote on 03/03/2010 03:15:22 PM:
> > > > David Darj wrote:
> > > > > My plan was to build (for a start) what's included in the
> > > > > svn-win32-1.6.x.zip,
> > > > >
> > > > > Win32 binaries (svn, svnadmin, svnserve, svnmucc, etc...) both 
dor
> > BDB
> > > > > and FSFS, including OpenSSL
> > > > > Modules for Apache 2.2.x (mod_dav_svn.so, mod_authz_svn.so)
> > > > >
> > > > > in short: what's needed for building the Windows msi installer.
> > > > >
> > > > > /David
> > >
> > > > Yes, that's exactly what I had in mind.
> > > > As to the "extract collabnet and repack" idea, I too am not sure 
if it
> > > > would be allowed
> > > >
> > >
> > > What is wrong with the collabnet installers/binaries that you can't 
use
> > them?
> > 
> > Different default installation path and the old tigris installer
> > needs to be manually removed.  The collabnet one can install more 
stuff
> > (including apache) which I wouldn't want to give as an option.
> 
> Ok... 
> 
> 1. You only have to remove the tigris installer once. 

For an individual, yes.  I have around 6000 installs to "upgrade"...
(Yes, there are other ways to do large upgrades, but the individual
 users needs to upgrade on their own here for other reasons.)

> 2. You can specify the install directory rather than accept the 
> default. When you run upgrades it will maintain the INSTALLDIR that you 
used.
> 3. It only "installs" apache if you select it. And you can also opt 
> to not set up svnserver/apache as services if you have you own 
> apache install you want to use. Yes it throws apache in there too...
> 20 MB or so. You can delete it if taht 20 MB really bothers you. You
> could create a batch file that deletes all of the apache stuff 
> except mod.dav_svn.so and run it after you run the installer.
> 
> There is also the client only installer which doesn't install any of
> the server side stuff.

Hadn't noticed this.  That effectively solves the "user decides they
want to install everything" problem.

> > I'm willing to move to another installer for our enterprise users
> > for a "major" 1.7 upgrade, but hesitant to do it sooner.
> > 
> > My other option is to just modify the TortoiseSvn installer to
> > include command line binaries from somewhere.  (This wouldn't
> > be for outside distribution though, so wouldn't help the community.)
> > 
> > Kevin R.
> 
> If you want just the command line binaries, use the client only 
> collabnet installer.
> 
> I really haven't seen a show stopper with using the collabnet 
> installers except for, what seem to me, like a few very minor nits. 

I don't see any showstoppers either.  We can all adapt.  In fact,
we were previously using the Collabnet installers, and (in this case
unfortunately) moved to the tigris ones in the past for various reasons.

Most likely, we will repackage something internally, which we
do for most other apps anyway.  (I build our solaris and linux
versions from scratch with all dependencies, so I should just
get off my lazy butt and build Windows too...)

Don't get me wrong, I *HIGHLY* appreciate all the effort put
forth in the past (and in the future) by all the volunteers!!!

Kevin R.

Re: Tigris binary packages for Windows

[eg]

On 3/3/2010 6:26 AM, Mark Phippard wrote:


One other "pain" I thought of is that ideally the binaries should be
built using MSVC 6.0 (I am assuming DJ has not changed that).  Since
the httpd binaries are built using that you can have problems if a
newer Visual Studio is used for mod_dav_svn.  You also have to deal
with distributing the MS runtime libraries if a newer version is used.


I checked the last zipped binaries the other day and ran a depends 
against them, and they were only dependent on vanilla msvc runtime 
libraries... so yes, he was using MSVC 6 still.


The first issue you mention about building mod_dav_svn with different 
run time library dependency as httpd is the bigger issue.


Is httpd always built using MSVC 6 still?

If that is a hard constraint, then distributing the new run time 
libraries is red-herring.


Nevertheless, for the second issue, with the new Wix-based installer, 
distributing newer runtime libraries is now trivial. You just install 
the relevant library and policy merge modules provided by the compiler.





The "pain" is that is not possible to obtain a legal copy of MSVC 6.0
anymore.  So unless you already have a copy you cannot get it.

Building with Visual Studio 2008 is a lot simpler but has these other
problems to contend with.



I still have a compiler and (probably) a build setup for a svn 1.4x 
build I did using VC 6.0 back in 2006. I havent tried since, as it was a 
real pain (as others have echoed) to drag in all the dependencies, 
tools, and modify setup and scripts that would make it all work... and I 
havent found the motivation to do it again.

RE: Tigris binary packages for Windows

[Bob Archer]

> Bob Archer  wrote on 03/03/2010 03:15:22 PM:
> > > David Darj wrote:
> > > > My plan was to build (for a start) what's included in the
> > > > svn-win32-1.6.x.zip,
> > > >
> > > > Win32 binaries (svn, svnadmin, svnserve, svnmucc, etc...) both dor
> BDB
> > > > and FSFS, including OpenSSL
> > > > Modules for Apache 2.2.x (mod_dav_svn.so, mod_authz_svn.so)
> > > >
> > > > in short: what's needed for building the Windows msi installer.
> > > >
> > > > /David
> >
> > > Yes, that's exactly what I had in mind.
> > > As to the "extract collabnet and repack" idea, I too am not sure if it
> > > would be allowed
> > >
> >
> > What is wrong with the collabnet installers/binaries that you can't use
> them?
> 
> Different default installation path and the old tigris installer
> needs to be manually removed.  The collabnet one can install more stuff
> (including apache) which I wouldn't want to give as an option.

Ok... 

1. You only have to remove the tigris installer once. 
2. You can specify the install directory rather than accept the default. When 
you run upgrades it will maintain the INSTALLDIR that you used.
3. It only "installs" apache if you select it. And you can also opt to not set 
up svnserver/apache as services if you have you own apache install you want to 
use. Yes it throws apache in there too... 20 MB or so. You can delete it if 
taht 20 MB really bothers you. You could create a batch file that deletes all 
of the apache stuff except mod.dav_svn.so and run it after you run the 
installer.

There is also the client only installer which doesn't install any of the server 
side stuff.


> I'm willing to move to another installer for our enterprise users
> for a "major" 1.7 upgrade, but hesitant to do it sooner.
> 
> My other option is to just modify the TortoiseSvn installer to
> include command line binaries from somewhere.  (This wouldn't
> be for outside distribution though, so wouldn't help the community.)
> 
> Kevin R.

If you want just the command line binaries, use the client only collabnet 
installer.

I really haven't seen a show stopper with using the collabnet installers except 
for, what seem to me, like a few very minor nits. 

Also, maybe if you ask collabnet to modify their install a bit so you can have 
it give you mod_dav_svn.so without all the other apache stuff they might be 
willing to do that.

BOb

RE: Tigris binary packages for Windows

[kmradke]

Bob Archer  wrote on 03/03/2010 03:15:22 PM:
> > David Darj wrote:
> > > My plan was to build (for a start) what's included in the
> > > svn-win32-1.6.x.zip,
> > >
> > > Win32 binaries (svn, svnadmin, svnserve, svnmucc, etc...) both dor 
BDB
> > > and FSFS, including OpenSSL
> > > Modules for Apache 2.2.x (mod_dav_svn.so, mod_authz_svn.so)
> > >
> > > in short: what's needed for building the Windows msi installer.
> > >
> > > /David
> 
> > Yes, that's exactly what I had in mind.
> > As to the "extract collabnet and repack" idea, I too am not sure if it
> > would be allowed
> >
> 
> What is wrong with the collabnet installers/binaries that you can't use 
them?

Different default installation path and the old tigris installer
needs to be manually removed.  The collabnet one can install more stuff
(including apache) which I wouldn't want to give as an option.

I'm willing to move to another installer for our enterprise users
for a "major" 1.7 upgrade, but hesitant to do it sooner.

My other option is to just modify the TortoiseSvn installer to
include command line binaries from somewhere.  (This wouldn't
be for outside distribution though, so wouldn't help the community.)

Kevin R.

Re: "svn log" via svnserve is letting me see things it shouldn't, but "svn ls" works as I expect

[Alexey Neyman]

On Wednesday 03 March 2010 01:14:38 pm 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.

Using svnadmin dump/load sequence piped through "svndumpfilter 
include --drop-empty-revs /cyclingproject/public" instead of svnsync 
would probably help.

Regards,
Alexey.


signature.asc
Description: This is a digitally signed message part.

Re: "svn log" via svnserve is letting me see things it shouldn't, but "svn ls" works as I expect

[Stefan Sperling]

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.

Stefan

RE: Tigris binary packages for Windows

[Bob Archer]

> David Darj wrote:
> > My plan was to build (for a start) what's included in the
> > svn-win32-1.6.x.zip,
> >
> > Win32 binaries (svn, svnadmin, svnserve, svnmucc, etc...) both dor BDB
> > and FSFS, including OpenSSL
> > Modules for Apache 2.2.x (mod_dav_svn.so, mod_authz_svn.so)
> >
> > in short: what's needed for building the Windows msi installer.
> >
> > /David

> Yes, that's exactly what I had in mind.
> As to the "extract collabnet and repack" idea, I too am not sure if it
> would be allowed
>

What is wrong with the collabnet installers/binaries that you can't use them?

My understanding of needing to build windows binaries from source would be to 
provide binaries for each svn commit in order to simplify testing interium 
versions. 

BOb

Re: Tigris binary packages for Windows

[Olivier Sannier]

Yes, that's exactly what I had in mind.
As to the "extract collabnet and repack" idea, I too am not sure if it 
would be allowed


David Darj wrote:
My plan was to build (for a start) what's included in the 
svn-win32-1.6.x.zip,


Win32 binaries (svn, svnadmin, svnserve, svnmucc, etc...) both dor BDB 
and FSFS, including OpenSSL

Modules for Apache 2.2.x (mod_dav_svn.so, mod_authz_svn.so)

in short: what's needed for building the Windows msi installer.

/David

On 2010-03-03 10:50, Troy Simpson wrote:
For base-level support, we narrowed that down to apache 2.2x.  Do we 
really
need to support all the python builds? They were a great service from 
D.J.

Heap, but now that we don't have that, do we really need to ditch all
windows builds?  What we could look at is a standard base-level windows
build that most people use.  Personally, I just use a windows client, 
as do

many users - I don't even use the apache bindings, nor do many windows
users.  We could leave specialised builds to teams who want to 
support them

which in theory would make the job at this end much easier.


Regards,

Troy

  

-Original Message-
From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Wednesday, 3 March 2010 7:54 AM
To: Johan Corveleyn
Cc: Daniel Shahaf; users@subversion.apache.org
Subject: Re: Tigris binary packages for Windows

On Tue, Mar 2, 2010 at 4:48 PM, Johan Corveleyn
wrote:



I also whish you (or anyone who tries to build subversion on Windows)
good luck. It can be done, but it isn't easy. I for one spent a lot
   

of


time getting it to work on my machine, just to experiment with some
simple things. Now I have a working build setup, but I wouldn't
consider it standard by any means (and don't have more time to invest
in standardizing this build).

I actually started from Daniel Shahaf's Makefile, which he mentioned
above. See my experiences here:
http://svn.haxx.se/users/archive-2009-09/0305.shtml
   

I do not want to jinx myself for the next time I have to setup a new
system, but I do not find it that difficult.  I have been building SVN
on Windows for years and have set it up on a number of new systems. I
usually get it all working right the first time now.

It is certainly a "pain in the ***" but it is not that hard.  The
worst part is just that building SVN means building a whole lot of
other software first and tracking down dependencies for those build
processes like Perl/Python that you might not otherwise have
installed.

Personally, I would steer people away from volunteering for this task
because I know what a pain it is.  Building the basic binaries is not
too hard, but doing it for all of the bindings and dealing with things
like providing different versions of the binaries built against
different Python versions or Apache versions gets to be a bit much.
Not to mention some of the variants in building in support for some of
the different SSL and authentication packages.  These are basically
the reasons I cannot see this project ever officially supporting any
specific binary.  It should really be the maintainer of the binary
that does the support because there are too many factors involved.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/
 
   

"svn log" via svnserve is letting me see things it shouldn't, but "svn ls" works as I expect

[Reid Priedhorsky]

Hi,

We are trying to set up svnserve to serve part of a repository to the 
public. The problem: "svn log" shows _all_ log messages in the repo when 
invoked on the repo root, even when "svn ls" on the same path gives 
"Authorization failed".


The goal: serve repository path /cyclingproject/public read-only to 
anyone, and the rest of the repo should not be available to the public. 
In particular, log messages to files not in /cyclingproject/public 
should not be available.


We are mirroring our main repository with svnsync, restricting the copy 
to the path /cyclingproject/public. Only data in this path seems to be 
copied, but all log messages in the main repo are coming over. We are 
using file: to do the mirroring, so this step does not involve svnserve. 
It is the mirror that we're serving with svnserve.


We are on version 1.5.7.

Contents of svnserve.conf:

  [general]
  anon-access = read
  auth-access = none
  authz-db = authz

Contents of authz:

  [/cyclingproject/public]
  * = r

We invoke svnserve as:

  $ svnserve -d --foreground -r /project/Grouplens/svn-cyclopath-public

"svn ls" output (all this is what we want):

  $ svn ls svn://localhost/
  svn: Authorization failed
  $ svn ls svn://localhost/cyclingproject
  svn: Authorization failed
  $ svn ls svn://localhost/cyclingproject/public
  test

"svn log" output:

  $ svn log svn://localhost/cyclingproject/public
  [log messages for /cyclingproject/public]
  $ svn log svn://localhost/cyclingproject
  svn: Item is not readable
  $ svn log svn://localhost
  [log messages for the whole mirror repository]

It is the last command that is the problem. The expected (and desired) 
behavior is either (a) "svn: Item is not readable" or (b) log messages 
for /cyclingproject/public only.


What's wrong? Did I make a configuration error? Is this a bug?

All I can think of is to write a commit hook in the mirror repository 
that removes log messages for paths that shouldn't be public.


Any help would be much appreciated.

Reid

Re: Tigris binary packages for Windows

[David Darj]

On 2010-03-03 16:25, Konstantin Kolinko wrote:

2010/3/3 Mark Phippard:
   

(...)
One other "pain" I thought of is that ideally the binaries should be
built using MSVC 6.0 (I am assuming DJ has not changed that).  Since
the httpd binaries are built using that you can have problems if a
newer Visual Studio is used for mod_dav_svn.  You also have to deal
with distributing the MS runtime libraries if a newer version is used.

The "pain" is that is not possible to obtain a legal copy of MSVC 6.0
anymore.  So unless you already have a copy you cannot get it.

Building with Visual Studio 2008 is a lot simpler but has these other
problems to contend with.

 

I, personally, do not know with what VS version official Apache HTTPD
binaries (*.msi) are built with, but the ones from
http://www.apachelounge.com/ that I am using (many thanks to them for
providing those)  are built with VC 2008.

I had to install VC 2008 redistributable package, that can be downloaded here:
www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

I used Tigris binaries before, but since 1.6.9 I am using the
Collabnet ones. I wish those were available as a zip archive (or with
a command to unpack the installer), though.

This is for a 32-bit OS.

Best regards,
Konstantin Kolinko
   
One idea I had was installing Collabnet's release and using their 
binaries to build the Windows msi installer.
Don't know if this can be done legally? I think should be OK but I don't 
know. Anyone who knows ?


/David

Re: Tigris binary packages for Windows

[David Darj]

My plan was to build (for a start) what's included in the 
svn-win32-1.6.x.zip,


Win32 binaries (svn, svnadmin, svnserve, svnmucc, etc...) both dor BDB 
and FSFS, including OpenSSL

Modules for Apache 2.2.x (mod_dav_svn.so, mod_authz_svn.so)

in short: what's needed for building the Windows msi installer.

/David

On 2010-03-03 10:50, Troy Simpson wrote:

For base-level support, we narrowed that down to apache 2.2x.  Do we really
need to support all the python builds? They were a great service from D.J.
Heap, but now that we don't have that, do we really need to ditch all
windows builds?  What we could look at is a standard base-level windows
build that most people use.  Personally, I just use a windows client, as do
many users - I don't even use the apache bindings, nor do many windows
users.  We could leave specialised builds to teams who want to support them
which in theory would make the job at this end much easier.


Regards,

Troy

   

-Original Message-
From: Mark Phippard [mailto:markp...@gmail.com]
Sent: Wednesday, 3 March 2010 7:54 AM
To: Johan Corveleyn
Cc: Daniel Shahaf; users@subversion.apache.org
Subject: Re: Tigris binary packages for Windows

On Tue, Mar 2, 2010 at 4:48 PM, Johan Corveleyn
wrote:

 

I also whish you (or anyone who tries to build subversion on Windows)
good luck. It can be done, but it isn't easy. I for one spent a lot
   

of
 

time getting it to work on my machine, just to experiment with some
simple things. Now I have a working build setup, but I wouldn't
consider it standard by any means (and don't have more time to invest
in standardizing this build).

I actually started from Daniel Shahaf's Makefile, which he mentioned
above. See my experiences here:
http://svn.haxx.se/users/archive-2009-09/0305.shtml
   

I do not want to jinx myself for the next time I have to setup a new
system, but I do not find it that difficult.  I have been building SVN
on Windows for years and have set it up on a number of new systems. I
usually get it all working right the first time now.

It is certainly a "pain in the ***" but it is not that hard.  The
worst part is just that building SVN means building a whole lot of
other software first and tracking down dependencies for those build
processes like Perl/Python that you might not otherwise have
installed.

Personally, I would steer people away from volunteering for this task
because I know what a pain it is.  Building the basic binaries is not
too hard, but doing it for all of the bindings and dealing with things
like providing different versions of the binaries built against
different Python versions or Apache versions gets to be a bit much.
Not to mention some of the variants in building in support for some of
the different SSL and authentication packages.  These are basically
the reasons I cannot see this project ever officially supporting any
specific binary.  It should really be the maintainer of the binary
that does the support because there are too many factors involved.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/
 
   

RE: Check Client Version in hook

[Geoff Rowell]

Philipp Leusmann  wrote on Wednesday, March
03, 2010 11:41 AM:
> Great, information if mergeinfo is available if all we need to do. (We
want to make sure only mergeinfo-supporting > clients are allowed, as
proposed in

>
> Maybe the way to do so (as shown in
 ) should also make it
into > the book.
>

This is also provided by the "FilterCapabilities" tag of the Subversion Hook
Framework.

http://sourceforge.net/apps/mediawiki/svnhook

There's an example under "Hook Configuration File Examples".
---
Geoff Rowell
geoff.row...@gmail.com

Issue using SVN Perl bindings on Ubuntu 9.10 - TypeError

[Kyle Joe-CNST08]

I'm trying to port some existing (crufty old) perl code from a Fedora
Core 5 server running Perl 5.8.8 and SVN 1.3.2, to a new server running
Ubuntu 9.10 with Perl 5.10.0 and SVN 1.6.5. The package for libsvn-perl
is 1.6.5dfsg-1ubuntu1.  In each case, the local server is (normally)
accessing SVN on the local server. 
 
The error reported is:
 
TypeError in method 'svn_auth_cred_simple_t_password_set', argument 2 of
type 'char const *'

when attempting to create a new client connection via:
 
 $ctx = new SVN::Client(
  auth => [SVN::Client::get_simple_provider(),
  SVN::Client::get_simple_prompt_provider(\&simple_prompt,2),
  SVN::Client::get_username_provider()],
  log_msg => [\&log_msg_provider]
  );
 
sub simple_prompt {
 my $cred = shift;
 my $realm = shift;
 my $default_username = shift;
 my $may_save = shift;
 my $pool = shift;
 my $username = lc($USERNAME);
 $cred->username($username);
 my $password = $PASSWORD;
 $cred->password($password);
}
 
The old server has no problem connecting to itself, or to the new server
using that code.  The new server cannot connect either to itself or to
the old server, in both cases the TypeError error is generated. 
 
I tried searching the mailing list, didn't see anything recent regarding
the perl bindings or SWIG that seemed relevant, nor did I find any
documentation changes to the call parameters. 
 
Is there something I should be doing differently here? Suggestions as to
how to proceed?
--
Joe Kyle
--jjkd--
 

Re: Check Client Version in hook

[Stein Somers]

Just be aware that these hooks disallow all commits, not just commits of 
merges, where the svnbook advice applies. There's not much better you 
can do, because it's impossible to tell from an "old" transaction if it 
contains a merge or only genuine, original changes.


If you'd still like to allow old clients to commit particular kinds of 
changes (like tagging), or in particular branches, it's not that easy.


--
Stein

Re: Programming a Watcher File

[Les Mikesell]

On 3/3/2010 11:06 AM, Bob Archer wrote:

On Tue, Mar 2, 2010 at 11:39 PM, Andrey Repin
wrote:

Sorry, my head is a bit crippled for now, and your post contains too

much

cross-references to be understandable in my current state.
Could you please put it in simple terms, how you see your potential

system

works?


We have both development teams in India and in New York. When the
Indian development team makes changes, the New York QA team needs to
be notified, so they know what to test. When the New York development
team checks something in, the Indian QA team needs to be notified.
This will currently be for a single project, so I have to specify
those files in that project that need to be watched.


I do this kind of stuff with cruise control. It will watch for check-ins and 
kick of tasks which can include emails if you want. I tie this in with CI 
builds... of course, cruise control doesn't have to run a build... it could 
just do publish/notify tasks if you want.

You can also set up a project in cruise control that watches it's own config 
file that you put into svn. When this config file is changed cruise control 
will update the WC it is in and then re-intialize with the new config info. The 
config file is where email addresses and such would be stored.

I would rather go this way than writing my own script.


Hudson would be able to do this sort of thing too.  And probably do 
whatever action you wanted the person to take after noticing the file 
changed...


--
  Les Mikesell
   lesmikes...@gmail.com

Re: SVN Server Best Practices?

[B Smith-Mannschott]

2010/3/3 Mariusz Droździel :
> Hello,
>
> After spending almost 2 days on recovering broken FSFS, which turned
> out to be broken for over year already I have a question. What are
> suggested best practices for SVN Repo? Some kind of cronbot which
> would do a verify and a full checkout dialy comes to mind. What else?
> Are there any scripts to do dialy checks on repo out there already?
> What do you suggest? Thanks in advance.
>

one idea:

I have read-only (svnsync) clones of all my important repositories in
a separate building from the real svn server. This happened more by
accident than by design: my continuous build checks out from the
clones instead of the original repository. That way, I don't have to
worry about my build jobs flooding the central server with polling to
see if anything has changed yet. (There is some of this, however,
since there's a cron job to keep the repositories up-to-date.

This has helped me diagnose and repair repository corruption in one
case, and it gives me a warm fuzzy feeling (despite the fact that I've
been told that the central svn server is backed up).

// ben

Re: Programming a Watcher File

[David Weintraub]

On Wed, Mar 3, 2010 at 12:06 PM, Bob Archer  wrote:
> I do this kind of stuff with cruise control. It will watch for check-ins and 
> kick of tasks
> which can include emails if you want. I tie this in with CI builds... of 
> course, cruise control
> doesn't have to run a build... it could just do publish/notify tasks if you 
> want.

We have Hudson, and I could do something similar. However, the problem
is that for the same file, I have to notify Group "C" if Group "A"
does a check in, and Group "D" if Group "B" does a checkin. That makes
things a bit more difficult. Plus, it might get to the point where
certain sets of files in a single project will send notifications to a
particular user.

-- 
David Weintraub
qazw...@gmail.com

Re: Programming a Watcher File

[David Weintraub]

On Wed, Mar 3, 2010 at 10:09 AM, Larry Shatzer, Jr.  wrote:>
> A while ago, I wrote something on top of SVN::Notify with a similar feature,
> of having a property define who got an email. I threw it up on CPAN
> at http://search.cpan.org/~larrysh/SVN-Notify-Filter-Watchers-0.09/ It
> worked pretty good. I have since moved jobs, and we use FishEye, which has a
> way to setup notifications, and use that instead. So if it has any problems,
> send me a patch, and I will apply it.

Thanks for the link. I'll take a look at it. Something like Fisheye
may be the best way to go. I need to see what might be available in
the open source world. That might be cleaner and easier than some roll
your own setup.

It just occurred to me that this is a bit unique. This isn't a
developer saying what they're watching. It's their manager saying
"You're watching these files!". That's pretty unique.

-- 
David Weintraub
qazw...@gmail.com

RE: Programming a Watcher File

[Bob Archer]

> On Tue, Mar 2, 2010 at 11:39 PM, Andrey Repin 
> wrote:
> > Sorry, my head is a bit crippled for now, and your post contains too
> much
> > cross-references to be understandable in my current state.
> > Could you please put it in simple terms, how you see your potential
> system
> > works?
> 
> We have both development teams in India and in New York. When the
> Indian development team makes changes, the New York QA team needs to
> be notified, so they know what to test. When the New York development
> team checks something in, the Indian QA team needs to be notified.
> This will currently be for a single project, so I have to specify
> those files in that project that need to be watched.

I do this kind of stuff with cruise control. It will watch for check-ins and 
kick of tasks which can include emails if you want. I tie this in with CI 
builds... of course, cruise control doesn't have to run a build... it could 
just do publish/notify tasks if you want.

You can also set up a project in cruise control that watches it's own config 
file that you put into svn. When this config file is changed cruise control 
will update the WC it is in and then re-intialize with the new config info. The 
config file is where email addresses and such would be stored.

I would rather go this way than writing my own script.

BOb

Re: Programming a Watcher File

[David Weintraub]

On Tue, Mar 2, 2010 at 11:39 PM, Andrey Repin  wrote:
> Sorry, my head is a bit crippled for now, and your post contains too much
> cross-references to be understandable in my current state.
> Could you please put it in simple terms, how you see your potential system
> works?

We have both development teams in India and in New York. When the
Indian development team makes changes, the New York QA team needs to
be notified, so they know what to test. When the New York development
team checks something in, the Indian QA team needs to be notified.
This will currently be for a single project, so I have to specify
those files in that project that need to be watched.

I decided to make this hook script a bit more general than for this
specific circumstance. What if there are separate teams for each
branch that need to be notified? What if other teams want their files
to be watched?

> If having a custom (and client-customizable) configuration is all you ever
> want, there's a hint: hook script can access repository as easy as any other
> local file. Just do "svn cat" on required file and parse it's content as
> normal.
>
> However, be very wary of access rights on the mentioned configuration file.

I am using "svnlook cat" which is a bit faster since I don't have to
go through the Subversion server. I will be setting the rights on this
configuration file, so only the managers can modify it. Plus, I'll get
an email whenever the configuration file itself gets modified.

Originally, I was thinking about using properties to set the watch. If
I want a particular directory tree watched, I could put a sol:watch
property on that directory, and anytime a file in that directory tree
gets modified, I'll email the users.

However, how do you find all of these properties? If I check in a file
svn://host/project/dir/dir2/dir3/file, I'd have to check all the
parent directories for the property (that's five different directories
to check, plus the file itself). And, I'd have to do that for each
file changed. Plus, how do developers find all of their watches?
Therefore, I decided it would be better to have a single configuration
file for the watches.

Another possibility is to have a directory where users can put their
own watch definitions. I have an access control script that can easily
be setup so that barry.cfg can only be changed by barry and david.cfg
can only be changed by david. But, that means getting a list of these
watch files (svnlook tree), and then checking opening up each one to
construct my watch list. That might take too long.

-- 
David Weintraub
qazw...@gmail.com

Re: Check Client Version in hook

[Oliver Specht]

Ryan Schmidt schrieb:

On Mar 3, 2010, at 09:29, Oliver Specht wrote:


Ryan Schmidt schrieb:

On Mar 3, 2010, at 09:09, Oliver Specht wrote:

I want to check the client version in a commit hook. Can I do that? I saw that 
there are only two parameters in the script template.

Is there any documentation about all the parameters a hook script gets?

There is no way to check the version of the client. You can check the 
capabilities of the client in a limited way, which you can use to know for 
example whether the client has merge tracking support or not.

Hi,
thanks for the quick response. How do I check the merge tracking support? This 
is exactly what I am trying to do...



Check this thread:

http://www.svnforum.org/2017/viewtopic.php?t=6527

Don't forget to Reply All so this discussion stays on the mailing list.


All right, I will check the link.

Thanks for your help,

Oliver

Re: Check Client Version in hook

[Philipp Leusmann]

Great, information if mergeinfo is available if all we need to do. (We want to 
make sure only mergeinfo-supporting clients are allowed, as proposed in 


Maybe the way to do so (as shown in 
 ) should also make it into 
the book.

Regards,
 Philipp

Am 03.03.2010 um 16:18 schrieb Ryan Schmidt:

> 
> On Mar 3, 2010, at 09:09, Oliver Specht wrote:
> 
>> I want to check the client version in a commit hook. Can I do that? I saw 
>> that there are only two parameters in the script template.
>> 
>> Is there any documentation about all the parameters a hook script gets?
> 
> There is no way to check the version of the client. You can check the 
> capabilities of the client in a limited way, which you can use to know for 
> example whether the client has merge tracking support or not.
> 
> 

Re: Check Client Version in hook

[Ryan Schmidt]

On Mar 3, 2010, at 09:29, Oliver Specht wrote:

> Ryan Schmidt schrieb:
>> On Mar 3, 2010, at 09:09, Oliver Specht wrote:
>>> I want to check the client version in a commit hook. Can I do that? I saw 
>>> that there are only two parameters in the script template.
>>> 
>>> Is there any documentation about all the parameters a hook script gets?
>> There is no way to check the version of the client. You can check the 
>> capabilities of the client in a limited way, which you can use to know for 
>> example whether the client has merge tracking support or not.
> 
> Hi,
> thanks for the quick response. How do I check the merge tracking support? 
> This is exactly what I am trying to do...


Check this thread:

http://www.svnforum.org/2017/viewtopic.php?t=6527

Don't forget to Reply All so this discussion stays on the mailing list.

Re: Check Client Version in hook

[Stein Somers]

On 03/03/2010 16:18, Ryan Schmidt wrote:

You can check the capabilities of the client in a limited way


Limited indeed, as far as I understand. You get the client information 
in the start-commit hook. If you want to correlate it with the contents 
of the transaction proposed, you have to be in the pre-commit hook, and 
how can you get to that client information then? Your start-commit must 
have saved it to file? Assuming that once a start-commit is launched, no 
other transaction can be started.


--
Stein

Re: Tigris binary packages for Windows

[Konstantin Kolinko]

2010/3/3 Mark Phippard :
>
>> I used Tigris binaries before, but since 1.6.9 I am using the
>> Collabnet ones. I wish those were available as a zip archive (or with
>> a command to unpack the installer), though.
>
> Any reason that is critical to you?  The installer does little more
> than unpack to a location and add to PATH.  You can add /S to command
> line to run it silent as well as specify the location.  I doubt the
> small install UI is the problem though.
>

It is not critical. I am quite happy with what I already have for the price
(many thanks for providing these for free).

It is just that I already have HTTPD installed and configured, and the only
HTTPD bits what I need from the bundle are mod_dav_svn and mod_authz_svn.

Best regards,
Konstantin Kolinko

Re: missing error messages

[Stefan Sperling]

On Wed, Mar 03, 2010 at 04:06:08PM +0100, Janus Weil wrote:
> Dear subversion team,
> 
> I noticed that recent svn releases fail to display many error messages.
> 
> Example: Doing "svn co svn+ssh://some...@gcc.gnu.org/svn/gcc/trunk
> trunk" without having the proper ssh keys for user 'someone'. The svn
> versions I tried were 1.6.3, 1.6.5 and 1.6.9. With 1.6.3 I get:
> 
> Permission denied (publickey,gssapi-with-mic).
> svn: Network connection closed unexpectedly
> 
> But if I do the same with 1.6.5 or 1.6.9, the first line is missing
> and I only get the rather nebulous message about the unexpected
> closing of the network connection, without seeing the reason for that.
> 
> It's even worse if e.g. my private key has the wrong permissions for
> some reason. In this case svn 1.6.3 displays a very bold warning:
> 
> @@@
> @ WARNING: UNPROTECTED PRIVATE KEY FILE!  @
> @@@
> Permissions 0755 for '~/.ssh/id_dsa' are too open.
> It is recommended that your private key files are NOT accessible by others.
> This private key will be ignored.
> bad permissions: ignore key: ~/.ssh/id_dsa
> Permission denied (publickey,gssapi-with-mic).
> svn: Network connection closed unexpectedly
> 
> Again, with newer releases one only gets the last line, without any
> chance of finding out what the problem is.
> 
> Is this a known bug?

This is probably a side-effect of the fix for issue #2580 done in
Subversion 1.6.5. Since then, Subversion passes '-q' to ssh to avoid
the message 'Terminated by signal 15' being printed whenever ssh exists
upon being terminated by Subversion in a friendly manner.
This particular output from ssh would confuse users assuming the output
came from svn, and make them believe svn had crashed. Of course, '-q'
might also suppress some other messages printed by ssh, such as the
"unprotected key file" warning.

I guess we should make the error message for svn+ssh connection failures
advise people to remove the '-q' flag from the ssh invocation in
~/.subversion/config to debug SSH connection problems.
The patch below does this:

  $ svn ls svn+ssh://svntest/ 
  svn: Unable to connect to a repository at URL 'svn+ssh://svntest'
  svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
in the [tunnels] section of your Subversion configuration file.
  svn: Network connection closed unexpectedly

(Above, 'svntest' is an SSH host alias to localhost with a port where nothing
is listening.)

Do you think this would help?

Stefan


Index: subversion/libsvn_ra_svn/client.c
===
--- subversion/libsvn_ra_svn/client.c   (revision 918491)
+++ subversion/libsvn_ra_svn/client.c   (working copy)
@@ -463,6 +463,7 @@ static svn_error_t *make_tunnel(const char **args,
   apr_status_t status;
   apr_proc_t *proc;
   apr_procattr_t *attr;
+  svn_error_t *err;
 
   status = apr_procattr_create(&attr, pool);
   if (status == APR_SUCCESS)
@@ -516,7 +517,15 @@ static svn_error_t *make_tunnel(const char **args,
 
   /* Guard against dotfile output to stdout on the server. */
   *conn = svn_ra_svn_create_conn(NULL, proc->out, proc->in, pool);
-  SVN_ERR(svn_ra_svn_skip_leading_garbage(*conn, pool));
+  err = svn_ra_svn_skip_leading_garbage(*conn, pool);
+
+  if (err)
+return svn_error_quick_wrap(
+ err,
+ _("To better debug SSH connection problems, remove the -q "
+   "option from 'ssh' in the [tunnels] section of your "
+   "Subversion configuration file."));
+
   return SVN_NO_ERROR;
 }
 

Re: Tigris binary packages for Windows

[Mark Phippard]

On Wed, Mar 3, 2010 at 10:25 AM, Konstantin Kolinko
 wrote:
> I, personally, do not know with what VS version official Apache HTTPD
> binaries (*.msi) are built with, but the ones from
> http://www.apachelounge.com/ that I am using (many thanks to them for
> providing those)  are built with VC 2008.

I do not doubt that there are places where users can get a proper
Apache, but I guarantee if we provide binaries via tigris that
requires this, the lists will be flooded with users having weird
problems because they did not know.

Even though some people do not like it, this is why we bundle Apache
with the CollabNet binaries.  We are ultimately concerned with helping
people easily setup and run a SVN server and having them get their own
Apache is just a recipe for problems.

> I used Tigris binaries before, but since 1.6.9 I am using the
> Collabnet ones. I wish those were available as a zip archive (or with
> a command to unpack the installer), though.

Any reason that is critical to you?  The installer does little more
than unpack to a location and add to PATH.  You can add /S to command
line to run it silent as well as specify the location.  I doubt the
small install UI is the problem though.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

SVN Server Best Practices?

[Mariusz Droździel]

Hello,

After spending almost 2 days on recovering broken FSFS, which turned
out to be broken for over year already I have a question. What are
suggested best practices for SVN Repo? Some kind of cronbot which
would do a verify and a full checkout dialy comes to mind. What else?
Are there any scripts to do dialy checks on repo out there already?
What do you suggest? Thanks in advance.

-- 
Mariusz Drozdziel

Re: Tigris binary packages for Windows

[Konstantin Kolinko]

2010/3/3 Mark Phippard :
> (...)
> One other "pain" I thought of is that ideally the binaries should be
> built using MSVC 6.0 (I am assuming DJ has not changed that).  Since
> the httpd binaries are built using that you can have problems if a
> newer Visual Studio is used for mod_dav_svn.  You also have to deal
> with distributing the MS runtime libraries if a newer version is used.
>
> The "pain" is that is not possible to obtain a legal copy of MSVC 6.0
> anymore.  So unless you already have a copy you cannot get it.
>
> Building with Visual Studio 2008 is a lot simpler but has these other
> problems to contend with.
>

I, personally, do not know with what VS version official Apache HTTPD
binaries (*.msi) are built with, but the ones from
http://www.apachelounge.com/ that I am using (many thanks to them for
providing those)  are built with VC 2008.

I had to install VC 2008 redistributable package, that can be downloaded here:
www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

I used Tigris binaries before, but since 1.6.9 I am using the
Collabnet ones. I wish those were available as a zip archive (or with
a command to unpack the installer), though.

This is for a 32-bit OS.

Best regards,
Konstantin Kolinko

Re: Check Client Version in hook

[Ryan Schmidt]

On Mar 3, 2010, at 09:09, Oliver Specht wrote:

> I want to check the client version in a commit hook. Can I do that? I saw 
> that there are only two parameters in the script template.
> 
> Is there any documentation about all the parameters a hook script gets?

There is no way to check the version of the client. You can check the 
capabilities of the client in a limited way, which you can use to know for 
example whether the client has merge tracking support or not.

Check Client Version in hook

[Oliver Specht]

Hi,
I want to check the client version in a commit hook. Can I do that? I 
saw that there are only two parameters in the script template.


Is there any documentation about all the parameters a hook script gets?

Thanks,
Oliver

missing error messages

[Janus Weil]

Dear subversion team,

I noticed that recent svn releases fail to display many error messages.

Example: Doing "svn co svn+ssh://some...@gcc.gnu.org/svn/gcc/trunk
trunk" without having the proper ssh keys for user 'someone'. The svn
versions I tried were 1.6.3, 1.6.5 and 1.6.9. With 1.6.3 I get:

Permission denied (publickey,gssapi-with-mic).
svn: Network connection closed unexpectedly

But if I do the same with 1.6.5 or 1.6.9, the first line is missing
and I only get the rather nebulous message about the unexpected
closing of the network connection, without seeing the reason for that.

It's even worse if e.g. my private key has the wrong permissions for
some reason. In this case svn 1.6.3 displays a very bold warning:

@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE!  @
@@@
Permissions 0755 for '~/.ssh/id_dsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: ~/.ssh/id_dsa
Permission denied (publickey,gssapi-with-mic).
svn: Network connection closed unexpectedly

Again, with newer releases one only gets the last line, without any
chance of finding out what the problem is.

Is this a known bug?

Cheers,
Janus

Re: Programming a Watcher File

[Larry Shatzer, Jr.]

On Wed, Mar 3, 2010 at 1:57 AM, Johan Corveleyn  wrote:

>
> Some time ago, we were thinking of maintaining some
> notification-configuration inside versioned properties on directories
> in svn. The idea was simply to be able to put a (comma-separated, or
> new-line separated or whatever) list of email addresses in some
> property (let's call it "watchers") on directories. In the simple
> case, just the top level directories actually. Post-commit hook would
> then see which top-level directories were affected, and use those
> email addresses to send commit mails. This then avoids the need to
> setup and maintain mailinglists ... It might be possible to come up
> with a more elaborate system to put more configuration in such
> properties (like people watching only certain authors on certain
> directories/files etc).
>
> I didn't really think it through (there could be some nasty details,
> performance issues in crawling up the directory structure, ...),
> because we decided not to implement it. In the end, we decided it
> would be much easier to just setup some mailinglists, for the simple
> stuff we needed...
>
> Just my .02 €
>
> Johan
>


A while ago, I wrote something on top of SVN::Notify with a similar feature,
of having a property define who got an email. I threw it up on CPAN at
http://search.cpan.org/~larrysh/SVN-Notify-Filter-Watchers-0.09/ It worked
pretty good. I have since moved jobs, and we use FishEye, which has a way to
setup notifications, and use that instead. So if it has any problems, send
me a patch, and I will apply it.

-- Larry

Re: Tigris binary packages for Windows

[Mark Phippard]

On Wed, Mar 3, 2010 at 5:46 AM, Troy Simpson  wrote:
> A minimum level of support would be a good thing to agree on.  Bear in mind 
> the pre-stated
> complexities in handling too many supported installations.  Maybe start at 
> the baseline of 2.2x
> apache support and see if a volunteer is able to deliver builds for that?

When you talk about Apache 2.2 support I assume you mean you need
mod_dav_svn and not just to have SVN compiled against Apache 2.2's
version of APR?

One other "pain" I thought of is that ideally the binaries should be
built using MSVC 6.0 (I am assuming DJ has not changed that).  Since
the httpd binaries are built using that you can have problems if a
newer Visual Studio is used for mod_dav_svn.  You also have to deal
with distributing the MS runtime libraries if a newer version is used.

The "pain" is that is not possible to obtain a legal copy of MSVC 6.0
anymore.  So unless you already have a copy you cannot get it.

Building with Visual Studio 2008 is a lot simpler but has these other
problems to contend with.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Tigris binary packages for Windows

[Olivier Sannier]

Geoff Rowell wrote:

sNop wrote on Wednesday, March 03, 2010 7:39 AM:
   

Well, I, for one, would need the Apache 2.2 bindings but I do not need
the Python bindings at all, which I suspect most users don't either.
So basic binaries with 2.2 support would be perfect for starters

   

The same, only need Apache 2.2 modules and compiled subversion, other
binding aren't so important for end user, which are useing subversion
  for versioning own projects.

And without installer! ;) Only copy to the Program Files and go on

 

Anyone who uses ViewVC for enhanced browsing of Subversion repositories will
be interested in the Python bindings.


Yes, of course.
The debate here is to find a minimal set of options to restart creating 
win32 builds. Once the minimal set works, it will be easier to add the 
rest of it.

Re: Broken Revision in FSFS Repo

[Mariusz Droździel]

2010/3/3 Mariusz Droździel :

> Well, actually at first this one seemed to be quite trivial. Its
> enough to raise Apache loglevel to debug in order to see the exact
> filenames in mod_authnz_ldap logs.

Ok, in the end the solution described by Martin worked great. Thanks
big time! Small tip for anyone who will run into this problem and read
this topic. Raise apache loglevel to debug. If your sync fails, just
do checkout of the failing revision. You will exactly see which file
is broken. After denying access you can continue the sync with no
problem.

Out of 100k files I lost historical data for only 5 (newest versions
are there in the local copy), so its not that bad after all.

-- 
Mariusz Drozdziel

RE: Tigris binary packages for Windows

[Geoff Rowell]

sNop wrote on Wednesday, March 03, 2010 7:39 AM:
>> Well, I, for one, would need the Apache 2.2 bindings but I do not need 
>> the Python bindings at all, which I suspect most users don't either.
>> So basic binaries with 2.2 support would be perfect for starters
>>
> The same, only need Apache 2.2 modules and compiled subversion, other
> binding aren't so important for end user, which are useing subversion
>  for versioning own projects.
>
> And without installer! ;) Only copy to the Program Files and go on
>
Anyone who uses ViewVC for enhanced browsing of Subversion repositories will
be interested in the Python bindings.

---
Geoff Rowell
geoff.row...@gmail.com

RE: Update failed with "is not a working copy" message on externals

[Giulio Troccoli]

> The problem is that you're using file externals combined with
> putting the external locally in a directory which is not
> already a working copy. That's not supported for file externals.
>
> See
> http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html.
> Somewhere near the end it says:
>
> [[[
> Warning
>
> While directory externals can place the external directory at
> any depth, and any missing intermediate directories will be
> created, file externals must be placed into a working copy
> that is already checked out.
> ]]]

How did I miss that? ;-)

> I guess you have a couple of options:
> - use a dir external instead of a file external
> - put the file external locally directly under the current
> dir (which is already a working copy path), or in a subdir of
> which you are sure that it's already a working copy path
> - "enhance" subversion to support this :)

Thanks Johan. I had already adviced my user to put the file in an already 
existing directory as a workaround. I think we will stick with that.

Giulio


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

Re: Update failed with "is not a working copy" message on externals

[Johan Corveleyn]

On Wed, Mar 3, 2010 at 12:52 PM, Giulio Troccoli
 wrote:
>
>
>>
>
>
> Linedata Services (UK) Ltd
> Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
> Registered in England and Wales No 3027851    VAT Reg No 778499447
>
> -Original Message-
>
>
>> From: Andy Levy [mailto:andy.l...@gmail.com]
>> Sent: 03 March 2010 11:31
>> To: Giulio Troccoli
>> Cc: users@subversion.apache.org
>> Subject: Re: Update failed with "is not a working copy"
>> message on externals
>>
>> On Wed, Mar 3, 2010 at 05:14, Giulio Troccoli
>>  wrote:
>> > Hello,
>> >
>> > We are starting using externals to publish some
>> documentation for our customer. The repository contains test
>> files and documentation about the testing. Some of these
>> files and docs need to be made available to our customer. So
>> I thought of creating a Public folder and define the
>> svn:external property to pull down only the bits that we need.
>> >
>> > As part of the process however we decided to also reorganise the
>> > documents, especially because some of the original file are buried
>> > into 5 or more directories. An example of svn:external would be
>> >
>> > ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/5.11.23
>> > 5.31/5.11.23
>> >
>> > This works very well, creating the 5.31 and 5.11.23
>> directories. However, if we want to pull down a single file, e.g.
>> >
>> >
>> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20d
>> ata%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
>>  "5.31/basic data cleansing/End To End _basic data cleansing.xls"
>> >
>> > then svn update fails with the message
>> >
>> > Fetching external item into '5.31\basic data cleansing\End
>> To End _basic data cleansing.xls'
>> > svn: warning: '5.31\basic data cleansing' is not a working copy
>> >
>> > I thought I couldn't pull down a single file but only
>> directories but
>> > the manual says I can, and if I change the external as
>> >
>> >
>> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20d
>> ata%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
>>  "End To End _basic data cleansing.xls"
>> >
>> > then the file is retrieved.
>> >
>> > I have looked in the archive and the only related message I
>> found is a
>> > very old one about subversion 1.2.3
>> > http://svn.haxx.se/tsvnusers/archive-2005-12/0068.shtml
>> >
>> > So, it seems to me this is a bug. I was able to write a
>> little ksh script (attached) to reproduced the problem.
>>
>> Not only does it seem like a bug, it seems like this one.
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3368
>
> I don't know about that. I tried the reproduction script at the top of that 
> bug report and it works, which is not surprising since the report says it has 
> been fixed in 1.6.6 (and I'm using 1.6.9).

The problem is that you're using file externals combined with putting
the external locally in a directory which is not already a working
copy. That's not supported for file externals.

See http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html.
Somewhere near the end it says:

[[[
Warning

While directory externals can place the external directory at any
depth, and any missing intermediate directories will be created, file
externals must be placed into a working copy that is already checked
out.
]]]

So I don't think this really qualifies as a bug, more as a "known
limitation" (possibly there is already some "enhancement" request in
the issue tracker for this, but I haven't looked). The reason for this
limitation is probably that file externals are implemented quite
differently from directory externals (file externals are implemented
internally with the "switch" functionality, so that's probably why it
needs a working copy directory to begin with).

I guess you have a couple of options:
- use a dir external instead of a file external
- put the file external locally directly under the current dir (which
is already a working copy path), or in a subdir of which you are sure
that it's already a working copy path
- "enhance" subversion to support this :)

Johan

Re: Tigris binary packages for Windows

[sNop]

Hi all,

> Well, I, for one, would need the Apache 2.2 bindings but I do not need
> the Python bindings at all, which I suspect most users don't either.
> So basic binaries with 2.2 support would be perfect for starters
>

The same, only need Apache 2.2 modules and compiled subversion, other
binding aren't so important for end user, which are useing subversion
for versioning own projects.

And without installer! ;) Only copy to the Program Files and go on





signature.asc
Description: OpenPGP digital signature

Re: Tigris binary packages for Windows

[Jan Hendrik]

Concerning Re: Tigris binary packages for Wind
Olivier Sannier wrote on 3 Mar 2010, 11:27, at least in part:

> Troy Simpson wrote:
> > For base-level support, we narrowed that down to apache 2.2x.  Do we really
> > need to support all the python builds? They were a great service from D.J.
> > Heap, but now that we don't have that, do we really need to ditch all
> > windows builds?  What we could look at is a standard base-level windows
> > build that most people use.  Personally, I just use a windows client, as do
> > many users - I don't even use the apache bindings, nor do many windows
> > users.  We could leave specialised builds to teams who want to support them
> > which in theory would make the job at this end much easier.
> >
> Well, I, for one, would need the Apache 2.2 bindings but I do not need 
> the Python bindings at all, which I suspect most users don't either.
> So basic binaries with 2.2 support would be perfect for starters

Seconded.  Apache 2.2 is a must, language bindings are not 
needed here, nor OpenSSL.  But I would highly prefer to continue 
with BDB repository (which I understand from previous postings is 
one of the harder things of the complex build process unfortunately).

JH
---
Freedom quote:

 Live free or die.
   -- New Hampshire State Motto

Re: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org

[Pete Hatton]

Quoting "Stein Somers" :


Much easier is to unsubscribe from this spambot by sending an empty
e-mail to users-unsubscr...@subversion.tigris.org


Thanks - that was what I was looking for. Seems to have worked as well.

Pete Hatton
-
E-mail:  p...@monolight.org
Webpage: http://www.monolight.org
-

RE: Update failed with "is not a working copy" message on externals

[Giulio Troccoli]

>


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

-Original Message-


> From: Andy Levy [mailto:andy.l...@gmail.com]
> Sent: 03 March 2010 11:31
> To: Giulio Troccoli
> Cc: users@subversion.apache.org
> Subject: Re: Update failed with "is not a working copy"
> message on externals
>
> On Wed, Mar 3, 2010 at 05:14, Giulio Troccoli
>  wrote:
> > Hello,
> >
> > We are starting using externals to publish some
> documentation for our customer. The repository contains test
> files and documentation about the testing. Some of these
> files and docs need to be made available to our customer. So
> I thought of creating a Public folder and define the
> svn:external property to pull down only the bits that we need.
> >
> > As part of the process however we decided to also reorganise the
> > documents, especially because some of the original file are buried
> > into 5 or more directories. An example of svn:external would be
> >
> > ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/5.11.23
> > 5.31/5.11.23
> >
> > This works very well, creating the 5.31 and 5.11.23
> directories. However, if we want to pull down a single file, e.g.
> >
> >
> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20d
> ata%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
>  "5.31/basic data cleansing/End To End _basic data cleansing.xls"
> >
> > then svn update fails with the message
> >
> > Fetching external item into '5.31\basic data cleansing\End
> To End _basic data cleansing.xls'
> > svn: warning: '5.31\basic data cleansing' is not a working copy
> >
> > I thought I couldn't pull down a single file but only
> directories but
> > the manual says I can, and if I change the external as
> >
> >
> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20d
> ata%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
>  "End To End _basic data cleansing.xls"
> >
> > then the file is retrieved.
> >
> > I have looked in the archive and the only related message I
> found is a
> > very old one about subversion 1.2.3
> > http://svn.haxx.se/tsvnusers/archive-2005-12/0068.shtml
> >
> > So, it seems to me this is a bug. I was able to write a
> little ksh script (attached) to reproduced the problem.
>
> Not only does it seem like a bug, it seems like this one.
> http://subversion.tigris.org/issues/show_bug.cgi?id=3368

I don't know about that. I tried the reproduction script at the top of that bug 
report and it works, which is not surprising since the report says it has been 
fixed in 1.6.6 (and I'm using 1.6.9).

Giulio

Re: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org

[Ludwig Hügelschäfer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Stein Somers wrote on 03.03.10 12:21:
> There was a thread "spam being forwarded from
> ad...@subversion.apache.org" at the end of January which was actually
> about spam from ad...@subversion.tigris.org).
> 
> The address to complain is supposed to be feedback {_AT_} tigris.org
> 
> Much easier is to unsubscribe from this spambot by sending an empty
> e-mail to users-unsubscr...@subversion.tigris.org

Unsubscribe doesn't help. It'd much better to instruct the tigris.org
mailserver to answer with 5xx directly in the SMTP dialog to every mail
targeted to us...@subversion.tigris.org instead of first taking it and
let mailman bouncing it afterwards. This is the only way to keep out
spammers.

Ludwig
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJLjkzjAAoJEA52XAUJWdLj/YgH/ieLvalqu5KGPu1E6Qwt26M8
O9x0oip+hhJBxSJNHPQwcxs2cqB7zqq1vPG+Fp4MW609+OXTsaqKlJw5wEq/UzTp
iK0IlAyZXCpROsz2MUz+Uy3vE+/Crm3yWdSiHWBTpeOrV9WUCDdb6IaSBlQ7mSt2
Fidk0vfky2zUn9gxXl0S7vAjdMPggCXoMTe2TRDuUyKiO3Da3C0eu0OfoqCJa36o
aNL/CaohQZZReJCtWixR8Wv+8HrZghfk8tcsj+rBHNY3D1sip7SxcbViO/ik4jTT
Dm7Lb5FlpA4m4L1MO3CZDY3JyxuoG2ZOXH2yxGXB51qm1VP5RFK96M/fsXDT3uQ=
=mVxs
-END PGP SIGNATURE-

Re: Update failed with "is not a working copy" message on externals

[Andy Levy]

On Wed, Mar 3, 2010 at 05:14, Giulio Troccoli
 wrote:
> Hello,
>
> We are starting using externals to publish some documentation for our 
> customer. The repository contains test files and documentation about the 
> testing. Some of these files and docs need to be made available to our 
> customer. So I thought of creating a Public folder and define the 
> svn:external property to pull down only the bits that we need.
>
> As part of the process however we decided to also reorganise the documents, 
> especially because some of the original file are buried into 5 or more 
> directories. An example of svn:external would be
>
> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/5.11.23 5.31/5.11.23
>
> This works very well, creating the 5.31 and 5.11.23 directories. However, if 
> we want to pull down a single file, e.g.
>
> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20data%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
>  "5.31/basic data cleansing/End To End _basic data cleansing.xls"
>
> then svn update fails with the message
>
> Fetching external item into '5.31\basic data cleansing\End To End _basic data 
> cleansing.xls'
> svn: warning: '5.31\basic data cleansing' is not a working copy
>
> I thought I couldn't pull down a single file but only directories but the 
> manual says I can, and if I change the external as
>
> ^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20data%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
>  "End To End _basic data cleansing.xls"
>
> then the file is retrieved.
>
> I have looked in the archive and the only related message I found is a very 
> old one about subversion 1.2.3 
> http://svn.haxx.se/tsvnusers/archive-2005-12/0068.shtml
>
> So, it seems to me this is a bug. I was able to write a little ksh script 
> (attached) to reproduced the problem.

Not only does it seem like a bug, it seems like this one.
http://subversion.tigris.org/issues/show_bug.cgi?id=3368

Re: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org

[Stein Somers]

There was a thread "spam being forwarded from 
ad...@subversion.apache.org" at the end of January which was actually 
about spam from ad...@subversion.tigris.org).


The address to complain is supposed to be feedback {_AT_} tigris.org

Much easier is to unsubscribe from this spambot by sending an empty 
e-mail to users-unsubscr...@subversion.tigris.org


--
Stein

Re: Broken Revision in FSFS Repo

[Mariusz Droździel]

2010/3/3 Mariusz Droździel :

> I am forwarding the original post below, in case someone else will
> encounter similar problem. In my case the issue is, that I have no
> idea which files are broken. While doing sync or checkout I just get
> the following error in logs:

Well, actually at first this one seemed to be quite trivial. Its
enough to raise Apache loglevel to debug in order to see the exact
filenames in mod_authnz_ldap logs.

Now I get a request which fails, but it ask for over 1000k files.
After blocking out whole dir I can actually sync whole repo. I will
have to work out a script to find out which of those files
actually fails.

Working on this now, looks like I will be able to recover everything
but few files.

Thanks a lot for suggestions!

-- 
Mariusz Drozdziel

RE: Tigris binary packages for Windows

[Troy Simpson]

A minimum level of support would be a good thing to agree on.  Bear in mind the 
pre-stated complexities in handling too many supported installations.  Maybe 
start at the baseline of 2.2x apache support and see if a volunteer is able to 
deliver builds for that?


Regards,

Troy


From: Bojan Resnik [mailto:resn...@gmail.com] 
Sent: Wednesday, 3 March 2010 8:32 PM
To: users@subversion.apache.org
Subject: Re: Tigris binary packages for Windows

2010/3/3 Olivier Sannier 
Troy Simpson wrote:
For base-level support, we narrowed that down to apache 2.2x.  Do we really
need to support all the python builds? They were a great service from D.J.
Heap, but now that we don't have that, do we really need to ditch all
windows builds?  What we could look at is a standard base-level windows
build that most people use.  Personally, I just use a windows client, as do
many users - I don't even use the apache bindings, nor do many windows
users.  We could leave specialised builds to teams who want to support them
which in theory would make the job at this end much easier.
  
Well, I, for one, would need the Apache 2.2 bindings but I do not need the 
Python bindings at all, which I suspect most users don't either.
So basic binaries with 2.2 support would be perfect for starters

Agreed, Apache 2.2 bindings are must for me as well. Python and Ruby bindings 
would be nice, but our process doesn't depend on those.

--
Bojan Resnik

RE: Tigris binary packages for Windows

[Cooke, Mark]

> Troy Simpson wrote:
> > For base-level support, we narrowed that down to apache 2.2x.
> > Do we really need to support all the python builds? They were
> > a great service from D.J. Heap, but now that we don't have
> > that, do we really need to ditch all windows builds?  What we
> > could look at is a standard base-level windows build that most
> > people use.  Personally, I just use a windows client, as do
> > many users - I don't even use the apache bindings, nor do many
> > windows users.  We could leave specialised builds to teams who
> > want to support them which in theory would make the job at this
> > end much easier.
> >
> Well, I, for one, would need the Apache 2.2 bindings but I do 
> not need the Python bindings at all, which I suspect most users
> don't either.
>
> So basic binaries with 2.2 support would be perfect for starters
> 
As a windows user (and now admin) of Trac (trac.edgewall.org) I have
always appreciated the python bindings as a necessary part of the
package.  It is one of the reasons that I was able to propose and am now
implementing Trac and subversion at work (which mandates windoze instead
of linux).

I looked at building what we needed from source but do not have time
allocated nor access to virtual machines (or even permission to install
all the requisite packages!) to be able to do it myself.

So, many thanks to D J Heap, Troy Simpson & co for all the hard work and
a plea to continue to support apache and bindings...

~ Mark C

RE: thrash emails from admin -- was: Fwd: Notice about your recentmessage to us...@subversion.tigris.org

[Jon Foster]

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: Tigris binary packages for Windows

[Bojan Resnik]

2010/3/3 Olivier Sannier 

> Troy Simpson wrote:
>
>> For base-level support, we narrowed that down to apache 2.2x.  Do we
>> really
>> need to support all the python builds? They were a great service from D.J.
>> Heap, but now that we don't have that, do we really need to ditch all
>> windows builds?  What we could look at is a standard base-level windows
>> build that most people use.  Personally, I just use a windows client, as
>> do
>> many users - I don't even use the apache bindings, nor do many windows
>> users.  We could leave specialised builds to teams who want to support
>> them
>> which in theory would make the job at this end much easier.
>>
>>
> Well, I, for one, would need the Apache 2.2 bindings but I do not need the
> Python bindings at all, which I suspect most users don't either.
> So basic binaries with 2.2 support would be perfect for starters
>

Agreed, Apache 2.2 bindings are must for me as well. Python and Ruby
bindings would be nice, but our process doesn't depend on those.

--
Bojan Resnik

Re: Tigris binary packages for Windows

[Olivier Sannier]

Troy Simpson wrote:

For base-level support, we narrowed that down to apache 2.2x.  Do we really
need to support all the python builds? They were a great service from D.J.
Heap, but now that we don't have that, do we really need to ditch all
windows builds?  What we could look at is a standard base-level windows
build that most people use.  Personally, I just use a windows client, as do
many users - I don't even use the apache bindings, nor do many windows
users.  We could leave specialised builds to teams who want to support them
which in theory would make the job at this end much easier.
   
Well, I, for one, would need the Apache 2.2 bindings but I do not need 
the Python bindings at all, which I suspect most users don't either.

So basic binaries with 2.2 support would be perfect for starters

Re: Broken Revision in FSFS Repo

[Mariusz Droździel]

2010/3/3 Kutter, Martin :

I am forwarding the original post below, in case someone else will
encounter similar problem. In my case the issue is, that I have no
idea which files are broken. While doing sync or checkout I just get
the following error in logs:

[Wed Mar 03 11:07:53 2010] [error] [client 192.168.16.18] Provider
encountered an error while streaming a REPORT response.  [500, #0]
[Wed Mar 03 11:07:53 2010] [error] [client 192.168.16.18] A failure
occurred while driving the update report editor  [500, #185005]
[Wed Mar 03 11:07:53 2010] [error] [client 192.168.16.18]
Decompression of svndiff data failed  [500, #185005]

I have no idea how to find out which files are broken. While doing
checkout I get the message like:

A svn/dir1/dir2/dir3/dir4/file.a
A svn/dir1/dir2/dir3/dir4/file.b
A svn/dir1/dir2/dir3/dir4/file.c
A svn/dir1/dir2/dir3/dir4/file.d
svn: REPORT z '/svn/!svn/vcc/default': Decompression of svndiff data failed

Turns out that I can actually check out whole svn/dir1/dir2/dir3/dir4
and even svn/dir1/dir2/dir3/, with no error whatsoever.

Original post included:

> The steps:
>
> 1. set up path-based authorization using svnserve or
> Apache httpd. See the SVN Book on how to do this.
>
> 2. Deny access to the broken files to anyone in the
> auth config. This looks like this:
> [Path/To/Broken/File]
> * =
>
> 3. Set up a mirror of the repository using svnsync.
> See again the SVN Book on how to do this - typically
> it involves running
>
> svnsync init destination source
> svnsync sync destination
>
> Svnsync will ignore files it does not have access to,
> so you get a mirror of your repo without the broken files.
>
> 4. Create a dump of the synced repository using
> svnadmin dump
>
> Now you can move your old repository to a save place,
> re-create it and load the created dump into it.


-- 
Mariusz Drozdziel

Re: thrash emails from admin -- was: Fwd: Notice about your recent message to us...@subversion.tigris.org

[Pete Hatton]

Quoting "marc gonzalez-carnicer" :


it's been already several weeks since the migration to apache, and i am
getting these annoying emails all the time. can't the mailing list be tuned
for avoiding these messages? am i the only one to get them?


No, I'm also getting them as well.

What's annoying is I can't find the un-subscribe information anywhere  
for the old list and also ad...@subversion.tigris.org is a  
non-deliverable address. I suspect my unsubscribe to  
ad...@subversion.tigris.org request just got bounced to the  
us...@subversion.tigris.org - sorry if it did.


Anyone know the unsubscribe information for the old list?

Pete Hatton
-
E-mail:  p...@monolight.org
Webpage: http://www.monolight.org
-

Update failed with "is not a working copy" message on externals

[Giulio Troccoli]

Hello,

We are starting using externals to publish some documentation for our customer. 
The repository contains test files and documentation about the testing. Some of 
these files and docs need to be made available to our customer. So I thought of 
creating a Public folder and define the svn:external property to pull down only 
the bits that we need.

As part of the process however we decided to also reorganise the documents, 
especially because some of the original file are buried into 5 or more 
directories. An example of svn:external would be

^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/5.11.23 5.31/5.11.23

This works very well, creating the 5.31 and 5.11.23 directories. However, if we 
want to pull down a single file, e.g.

^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20data%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
 "5.31/basic data cleansing/End To End _basic data cleansing.xls"

then svn update fails with the message

Fetching external item into '5.31\basic data cleansing\End To End _basic data 
cleansing.xls'
svn: warning: '5.31\basic data cleansing' is not a working copy

I thought I couldn't pull down a single file but only directories but the 
manual says I can, and if I change the external as

^/api/5.31/Completed%20Projects%20(non-iTest%20docs)/basic%20data%20cleansing/End%20To%20End%20_basic%20data%20cleansing.xls
 "End To End _basic data cleansing.xls"

then the file is retrieved.

I have looked in the archive and the only related message I found is a very old 
one about subversion 1.2.3 
http://svn.haxx.se/tsvnusers/archive-2005-12/0068.shtml

So, it seems to me this is a bug. I was able to write a little ksh script 
(attached) to reproduced the problem.

Both svn server and client are 1.6.9

Regards,
Giulio Troccoli


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447






external-test.ksh
Description: external-test.ksh

RE: Tigris binary packages for Windows

[Troy Simpson]

For base-level support, we narrowed that down to apache 2.2x.  Do we really
need to support all the python builds? They were a great service from D.J.
Heap, but now that we don't have that, do we really need to ditch all
windows builds?  What we could look at is a standard base-level windows
build that most people use.  Personally, I just use a windows client, as do
many users - I don't even use the apache bindings, nor do many windows
users.  We could leave specialised builds to teams who want to support them
which in theory would make the job at this end much easier.


Regards,

Troy

> -Original Message-
> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: Wednesday, 3 March 2010 7:54 AM
> To: Johan Corveleyn
> Cc: Daniel Shahaf; users@subversion.apache.org
> Subject: Re: Tigris binary packages for Windows
> 
> On Tue, Mar 2, 2010 at 4:48 PM, Johan Corveleyn 
> wrote:
> 
> > I also whish you (or anyone who tries to build subversion on Windows)
> > good luck. It can be done, but it isn't easy. I for one spent a lot
> of
> > time getting it to work on my machine, just to experiment with some
> > simple things. Now I have a working build setup, but I wouldn't
> > consider it standard by any means (and don't have more time to invest
> > in standardizing this build).
> >
> > I actually started from Daniel Shahaf's Makefile, which he mentioned
> > above. See my experiences here:
> > http://svn.haxx.se/users/archive-2009-09/0305.shtml
> 
> I do not want to jinx myself for the next time I have to setup a new
> system, but I do not find it that difficult.  I have been building SVN
> on Windows for years and have set it up on a number of new systems. I
> usually get it all working right the first time now.
> 
> It is certainly a "pain in the ***" but it is not that hard.  The
> worst part is just that building SVN means building a whole lot of
> other software first and tracking down dependencies for those build
> processes like Perl/Python that you might not otherwise have
> installed.
> 
> Personally, I would steer people away from volunteering for this task
> because I know what a pain it is.  Building the basic binaries is not
> too hard, but doing it for all of the bindings and dealing with things
> like providing different versions of the binaries built against
> different Python versions or Apache versions gets to be a bit much.
> Not to mention some of the variants in building in support for some of
> the different SSL and authentication packages.  These are basically
> the reasons I cannot see this project ever officially supporting any
> specific binary.  It should really be the maintainer of the binary
> that does the support because there are too many factors involved.
> 
> --
> Thanks
> 
> Mark Phippard
> http://markphip.blogspot.com/

Re: thrash emails from admin -- was: Fwd: Notice about your recent message to us...@subversion.tigris.org

[Felix Gilcher]

Hi Marc,

there was a discussion about these emails a while ago. It seems there is an 
error with the old, deactivated tigris mailing list that allows these emails to 
get through. However, since they only get through on the old, deactivated list 
you might as well unsubscribe from that list.  

cheers

felix

On Mar 3, 2010, at 10:04 AM, marc gonzalez-carnicer wrote:

> it's been already several weeks since the migration to apache, and i am 
> getting these annoying emails all the time. can't the mailing list be tuned 
> for avoiding these messages? am i the only one to get them?
> 
> 
> 
> -- Forwarded message --
> From: 
> Date: 2010/3/3
> Subject: Notice about your recent message to us...@subversion.tigris.org
> To: us...@subversion.tigris.org
> 
> 
> We are sorry, but email posting to this discussion is not allowed.
> 
> 
> -- Missatge reenviat --
> From: Jahan 
> To: us...@subversion.tigris.org
> Date: Tue, 2 Mar 2010 20:05:04 -0600
> Subject: An e-card from Jahan for you
> 
> Alternate link if the e-card does not display correctly
> 
>   
> me and domino turning and burning
> 
> 
> 
> SGIWLNpaFjEnmQsBaMm 
> 
> adverts. first fucking sex So chicken toscana soup recipe macaroni grill far 
> the wife is winning navel fetish escort with i j a 22 pistol valueprivate 
> mansion bikini contest 11 mili avital nude spottings meltaway mint candy 
> recipe can anyone help me 
> 
> Jahan (us...@subversion.tigris.org)
> practicing to make it right
> View more pictures !
> 
> Sent by Jahan from IP 94.102.63.90 at Mar 03, 2010 at 02:05 AM (Gallery time) 
> 

--
Felix Gilcher

Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München

T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28

felix.gilc...@bitextender.com
http://www.bitextender.com/

Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever

Re: Broken Revision in FSFS Repo

[Mariusz Droździel]

2010/3/2 Kutter, Martin :

> This sounds a bit like our issue discussed in thread
> "Corrupted FSFS commit" just a few days ago on this list.
> We managed to create a copy of the repository without the corrupted
> files using path-based authorization and svnsync.

Could you give me some more insight on how exactly you performed the
restore? I read up on your problem a bit, but theres no any details.
Cloning my repo ends up the same way as everything does:

Copied properties for revision 1024.
Committed revision 1025.
Copied properties for revision 1025.
Committed revision 1026.
Copied properties for revision 1026.
Transmitting file data
...
svnsync: Decompression of svndiff data failed

> However, I'm a bit concerned about the issue arising again: Is there
> some error in svn which allows for corrupted FSFS revisions to
> enter into the repository?

I read up a lot of problem-posts on the net, and theres a lot of
people complaining about broken revs in their repo. Unfortunately the
only solution which pops is the third party fsfsverify.py, which is
failing in my case. I saw some posts about cases, when fsfsverify.py
didn't worked, but usually there was no further information on if and
how they managed to recover the data. Other solutions with dumping.
cloning, skipping rev didn't worked, as I mentioned in the OP. My
subversion version is 1.5.1.

-- 
Mariusz Drozdziel

Re: Programming a Watcher File

[Johan Corveleyn]

On Wed, Mar 3, 2010 at 5:39 AM, Andrey Repin  wrote:
> Greetings, David Weintraub!
>
>> One of the tech leads wants to be able to program a watch file, so
>> that when a certain set of developers change a particular file,
>> certain other developers get notified. Thus, we need to be able to
>> program what files, what developers do the commit, and what developers
>> receive the notification. I'd like to do this, so this developer can
>> maintain this file himself instead of me having to maintain it which
>> means it can't be a text file on the Subversion server.
>
> Sorry, my head is a bit crippled for now, and your post contains too much
> cross-references to be understandable in my current state.
> Could you please put it in simple terms, how you see your potential system
> works?
>
>> I'm working with something like this now. I have a configuration file
>> where you setup the various parameters (specifying files via globbing
>> or regex), who does the commit, and who receives the email. The
>> configuration file sits in the source repository, so this tech lead
>> has access to it.
>
>> I was wondering if anyone already has a post-commit hook script like
>> this already setup. I know there's one included in Subversion, but
>> this one uses a text file that's accessible to the hook script and its
>> setup isn't that flexible.
>
>> If not, I'll finish up the one I'm working on.
>
> If having a custom (and client-customizable) configuration is all you ever
> want, there's a hint: hook script can access repository as easy as any other
> local file. Just do "svn cat" on required file and parse it's content as
> normal.
>
> However, be very wary of access rights on the mentioned configuration file.

Some time ago, we were thinking of maintaining some
notification-configuration inside versioned properties on directories
in svn. The idea was simply to be able to put a (comma-separated, or
new-line separated or whatever) list of email addresses in some
property (let's call it "watchers") on directories. In the simple
case, just the top level directories actually. Post-commit hook would
then see which top-level directories were affected, and use those
email addresses to send commit mails. This then avoids the need to
setup and maintain mailinglists ... It might be possible to come up
with a more elaborate system to put more configuration in such
properties (like people watching only certain authors on certain
directories/files etc).

I didn't really think it through (there could be some nasty details,
performance issues in crawling up the directory structure, ...),
because we decided not to implement it. In the end, we decided it
would be much easier to just setup some mailinglists, for the simple
stuff we needed...

Just my .02 €

Johan

RE: strange problem with subversion merge

[Giulio Troccoli]

> Thanks a lot. I have gone through the link you have provided
> and now the merge is working well :-) That link gives very
> good clarification. Do you have any experience to work with
> esvn or aptana ? I don't  know how merging works with these
> GUI based tool and looking for the info.
> Anyways, thanks a lot once more.

I'm glad you resolved your issue. Unfortunately, I have no experience with esvn 
or aptana. I don't even use TortoiseSVN (apart from basci operations like 
checkout and commit), so no GUI experience for me.


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447