Re: Help with Mac repositry permissions

[Ryan Schmidt]

On Sep 8, 2010, at 01:58, Erik Andersson wrote:

> Not really sure about mac..

It's UNIX.

> but what I would do in linux would be:
> 
> sudo find /path/to/repo -type f -exec chmod 660 {} \; 
> sudo find /path/to/repo -type d -exec chmod 2770 {} \; 
> sudo chown -R root.www-data /path/to/repo

The user and group apache runs under on Mac OS X 10.5 and later is _www. (On 
10.4 and earlier it is www.) Unless he changed it in httpd.conf.

Is version 1.6 compatible with version 1.5 to upgrade subversion repository?

[c-aries]

Hi all, my company wanna upgrade subversion's repository from version 1.5 to
version 1.6.
Is version 1.6 compatible with version 1.5?
Many Thanks.

-- 
Gmail签名:喜欢是淡淡的

Re: Is version 1.6 compatible with version 1.5 to upgrade subversion repository?

[Michael Diers]

On 2010-09-08 09:34, c-aries wrote:
> Hi all, my company wanna upgrade subversion's repository from version
> 1.5 to version 1.6.
> Is version 1.6 compatible with version 1.5?

Yes. Refer to section "Comnpatibility Concerns" in the Subversion 1.6
release notes.

http://subversion.apache.org/docs/release-notes/1.6.html
http://subversion.apache.org/docs/release-notes/1.6.zh.html

-- 
Michael Diers, elego Software Solutions GmbH, http://www.elego.de

RE: Help with Mac repositry permissions

[Giulio Troccoli]

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Matthew Allen [mailto:f...@memecode.com]
> Sent: 08 September 2010 07:41
> To: users@subversion.apache.org
> Subject: Help with Mac repositry permissions
>
> Hi I started a serverfault question about mac svn repo permissions:
> http://serverfault.com/questions/171647/what-are-the-correct-u
> sergroup-for-a-mac-svn-apache-install
>
> But haven't got any response yet, anyone on here care to help?
>

You don't really say what the problem is, not here or in the serverfault report.

I know you have set up Apache but do you access the repository using the 
http:// protocol? Or do you use svn:// or file:// ?

Also, what are the permissions of /Users ?

Giulio

Detecting CR eol

[Giulio Troccoli]

I am writing a pre-commit hook script in perl. One of the requirement is that 
all files (luckly they are all text files) have the svn:eol-style property set 
to LF and the actual eol is indeed LF. If that's not the case I will reject the 
commit and direct the user to a page on our intranet to explain what to do to 
fix it.

My problem is how to detect whether the eol is LF and nothing else. I'm 
developing on Linux (Centos 5) and Perl 5.10. Subversion is 1.6.9, if it 
matters.

I thought about using the dos2unix utility (we only use Windows or Linux) and 
then check that the file hasn't changed, but it seems a lot of processing.

My second idea was to use a regular expression to check each line of each file. 
This way at least I would stop as soon as I find an eol that is not LF, saving 
some processing. I still need to svn cat each file into an array I think.

I know this is a common requirement but I don't know whether anyone has already 
done it in Perl. I would be greatful for any comment or suggestions of course.

Giulio


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Re: Help with Mac repositry permissions

[Matthew Allen]

-- Original Message --
To: Matthew Allen (f...@memecode.com)
From: Erik Andersson (kir...@gmail.com)
Subject: Re: Help with Mac repositry permissions
Date: 8/9/2010 4:58:47p

> Hi
>
> Not really sure about mac.. but what I would do in linux would be:
>
>
> sudo find /path/to/repo -type f -exec chmod 660 {} \;
> sudo find /path/to/repo -type d -exec chmod 2770 {} \;
> sudo chown -R root.www-data /path/to/repo
>
>
> How do you remove the global permissions?

The only difference I had to the above commands was:

sudo find /path/to/repo -type d -exec chmod 770 {} \;

I don't know what the "2" does in front of the 770. But it looks like it still 
works... so maybe thats all there is to it?

> What error message do you get?

If I removed the global permissions then I would not be able to access the repo 
via the https interface anymore. The exact error message escapes me though, it 
was a few weeks ago.

So anyway I followed the above commands and it seems to be working from the 
local network... the big test will be tomorrow when I try and get to my repo 
from work.
--
Matthew Allen

RE: Help with Mac repositry permissions

[Giulio Troccoli]

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Matthew Allen [mailto:f...@memecode.com]
> Sent: 08 September 2010 10:35
> To: Giulio Troccoli
> Subject: RE: Help with Mac repositry permissions
>
> The problem is that I want to make sure this is secure, and
> the fact that it seems to be using the webserver seems to be
> using the global permissions indicates to me that the repo
> files are not being correctly protected. If someone gets into
> my machine then they can see the repo. I want to limit access
> to a) the webserver process or b) a local terminal user.

Please respond to the list as well, usually by clicking on Reply-All. Also, 
don't top-post.

> Also the /Users folder perms is:
>   drwxr-xr-x   6 root  admin   204 18 Aug 10:03 Users

Now, there's your answer. The user that runs theweb server, _www, has 
permission to access /Users only becuase of the others permissions __r-x.

You could change the ownership of /Users to _www but I guess the /Users 
contains also the home directories of your users so this woldn't be acceptable.

Why don't you create a directory directly under / owned by _www and access by 
_www only, for example

mkdir /repos
chown _www /repos
chmod 700 /repos
cp -R /Users/Svn /repos

Check that the permission of /repos/Svn are still correct and then amend your 
web server configuration file so that the repository points to /repos/Svn and 
not /Users/Svn

Giulio

Re: Detecting CR eol

[Csaba Raduly]

Hi Giulio,

On Wed, Sep 8, 2010 at 10:25 AM, Giulio Troccoli  wrote:
> I am writing a pre-commit hook script in perl. One of the requirement is that 
> all files (luckily they are all text files) have the svn:eol-style property 
> set to LF and the actual eol is indeed LF. If that's not the case I will 
> reject the commit and direct the user to a page on our intranet to explain 
> what to do to fix it.
>
> My problem is how to detect whether the eol is LF and nothing else. I'm 
> developing on Linux (Centos 5) and Perl 5.10. Subversion is 1.6.9, if it 
> matters.
>
> I thought about using the dos2unix utility (we only use Windows or Linux) and 
> then check that the file hasn't changed, but it seems a lot of processing.
>
> My second idea was to use a regular expression to check each line of each 
> file. This way at least I would stop as soon as I find an eol that is not LF, 
> saving some processing. I still need to svn cat each file into an array I 
> think.
>

You need to use svnlook cat, but there is no need to read all its
output into memory. You can process it line-by-line.
Here's an outline (completely untested)

#!/usr/bin/perl -w
use strict;

my ($REPOS, $TXN) = @ARGV;

my $crlf = 0;

... determine the list of files
my @files = `svnlook changed -t $TXN $REPOS`;
chomp @files; # remove the newline at the end
s/^U\s+// for @files; # remove the leading U

FILE:
foreach my $file (@files) {
  open (SVN, "svnlook cat $file |") or die "open pipe failed: $!"
  while () # read from the pipe, one line at a time
  {
chomp; # cut the platform-specific line end. On Unix, this drops
the \n but keeps the \r
if ( /^M$/ ) { # last character is a \r (a.k.a. Control-M)
  $crlf = 1; last FILE;
}
  }
  close(SVN) or die "close pipe failed: $!" # it is very important to
check the close on pipes
}

if ($crlf)
{
  die "$file contains DOS line endings";
}


-- 
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

Regression for issue:2362 ?

[Weirdan]

Hello

I'm using svn v1.6.12 and it seems that calling 'svn info --xml' on a file
in an unversioned directory still causes svn to produce broken xml:

[weir...@localhost /home/sam/trunk] mkdir dir

[weir...@localhost /home/sam/trunk] touch dir/file

[weir...@localhost /home/sam/trunk] svn info --xml dir/file





svn: 'dir' is not a working copy

[weir...@localhost /home/sam/trunk] svn --version

svn, version 1.6.12 (r955767)

   compiled Aug  5 2010, 15:04:19


> Copyright (C) 2000-2009 CollabNet.

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

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


> The following repository access (RA) modules are available:


> * ra_neon : Module for accessing a repository via WebDAV protocol using
> Neon.

  - handles 'http' scheme

  - handles 'https' scheme

* ra_svn : Module for accessing a repository using the svn network protocol.

  - with Cyrus SASL authentication

  - handles 'svn' scheme

* ra_local : Module for accessing a repository on local disk.

  - handles 'file' scheme

* ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.

  - handles 'http' scheme

  - handles 'https' scheme


> [weir...@localhost /home/sam/trunk]


While the output is not exactly the same as in this ticket:
http://subversion.tigris.org/issues/show_bug.cgi?id=2887 ,  it seems to be
similar enough to call this a regression.

I'd comment on original issue, but it doesn't seem to be possible, so I'm
posting this to the mailing list hoping someone from dev team would pick
this up.

-- 
  Best regards,
  Bruce Weirdan mailto:
weir...@gmail.com

Re: Detecting CR eol

[Campbell Allan]

On Wednesday 08 Sep 2010, Csaba Raduly wrote:
> Hi Giulio,
>
> On Wed, Sep 8, 2010 at 10:25 AM, Giulio Troccoli  wrote:
> > I am writing a pre-commit hook script in perl. One of the requirement is
> > that all files (luckily they are all text files) have the svn:eol-style
> > property set to LF and the actual eol is indeed LF. If that's not the
> > case I will reject the commit and direct the user to a page on our
> > intranet to explain what to do to fix it.
> >
> > My problem is how to detect whether the eol is LF and nothing else. I'm
> > developing on Linux (Centos 5) and Perl 5.10. Subversion is 1.6.9, if it
> > matters.
> >
> > I thought about using the dos2unix utility (we only use Windows or Linux)
> > and then check that the file hasn't changed, but it seems a lot of
> > processing.
> >
> > My second idea was to use a regular expression to check each line of each
> > file. This way at least I would stop as soon as I find an eol that is not
> > LF, saving some processing. I still need to svn cat each file into an
> > array I think.
>
> You need to use svnlook cat, but there is no need to read all its
> output into memory. You can process it line-by-line.
> Here's an outline (completely untested)
>
> #!/usr/bin/perl -w
> use strict;
>
> my ($REPOS, $TXN) = @ARGV;
>
> my $crlf = 0;
>
> ... determine the list of files
> my @files = `svnlook changed -t $TXN $REPOS`;
> chomp @files; # remove the newline at the end
> s/^U\s+// for @files; # remove the leading U
>
> FILE:
> foreach my $file (@files) {
>   open (SVN, "svnlook cat $file |") or die "open pipe failed: $!"
>   while () # read from the pipe, one line at a time
>   {
> chomp; # cut the platform-specific line end. On Unix, this drops
> the \n but keeps the \r
> if ( /^M$/ ) { # last character is a \r (a.k.a. Control-M)
>   $crlf = 1; last FILE;
> }
>   }
>   close(SVN) or die "close pipe failed: $!" # it is very important to
> check the close on pipes
> }
>
> if ($crlf)
> {
>   die "$file contains DOS line endings";
> }

I don't believe you have to go to so much trouble in the pre-commit hook. If 
you have set the svn:eol-style property then subversion will ensure the file 
has those line endings on checkout and update them when committing into the 
repository. So all the hook needs to do is check for the property. See the 
book for more details

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.eol-style

I'd also normally expect the line ending style to be set to native so windows 
and unix users don't trample the existing incompatible line endings. The only 
reason perhaps for checking each file explicitly would be if there was 
something else needing the files to be in a particular format, ie releases to 
customers from a developer machine rather than an official build server that 
would check out a clean copy each time.

-- 

__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__

RE: Detecting CR eol

[Giulio Troccoli]

> I don't believe you have to go to so much trouble in the
> pre-commit hook. If you have set the svn:eol-style property
> then subversion will ensure the file has those line endings
> on checkout and update them when committing into the
> repository. So all the hook needs to do is check for the
> property. See the book for more details
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advan
> ced.props.special.eol-style

I'm not sure. Are you saying that if I set the svn:eol-style property to LF, 
for example, and my file has at least one line ending with CRLF, then 
Subversion will reject the commit? The book doesn't quite say that, and that 
wasn't my understanding on how the property works.

> I'd also normally expect the line ending style to be set to
> native so windows and unix users don't trample the existing
> incompatible line endings. The only reason perhaps for
> checking each file explicitly would be if there was something
> else needing the files to be in a particular format, ie
> releases to customers from a developer machine rather than an
> official build server that would check out a clean copy each time.

The requirement, to have LF, came a long time ago. I remeber having problems 
with svn:eol-style set to native. I think Subversion did not checkout the files 
with the correct EOL based on the platform, but maybe that was because the 
files were actually being committed with mixed EOLs.

G


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Renaming a branch

[Jeremy Mordkoff]

Is there a safe way to rename a branch? I'm worried about all my
mergeinfo's

RE: Renaming a branch

[Giulio Troccoli]

> Is there a safe way to rename a branch? I'm worried about all
> my mergeinfo's

If you have merged only from trunk and haven't merged from this branch, I don't 
see a problem in using s imple svn mv.


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

RE: Renaming a branch

[Jeremy Mordkoff]

> > Is there a safe way to rename a branch? I'm worried about all
> > my mergeinfo's
> 
> If you have merged only from trunk and haven't merged from this
branch, I don't see a problem
> in using s imple svn mv.
> 
I wish it was that simple

branches/rel_2_5_3 merges to branches/rel_2_5 which merges to trunk

I want to rename rel_2_5 to rel_2_6

RE: Renaming a branch

[Giulio Troccoli]

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Jeremy Mordkoff [mailto:j...@zeevee.com]
> Sent: 08 September 2010 14:33
> To: Giulio Troccoli; users@subversion.apache.org
> Subject: RE: Renaming a branch
>
> > > Is there a safe way to rename a branch? I'm worried about all my
> > > mergeinfo's
> >
> > If you have merged only from trunk and haven't merged from this
> branch, I don't see a problem
> > in using s imple svn mv.
> >
> I wish it was that simple
>
> branches/rel_2_5_3 merges to branches/rel_2_5 which merges to trunk
>
> I want to rename rel_2_5 to rel_2_6

rel_5_2 has *only* received merges, either from trunk or any other branch, is 
that correct? Then again a move is sufficient. The mergeinfo in the new branch, 
rel_2_6, will refer to rel_2_5_3 which you are not renaming. The problem would 
be if you had merged rel_2_5 to, let's say, rel_3_0. In that case you would 
need to edit the svn:mergeinfo property (using svn propedit not svn propset).

G

Howto minimize 'svn cat' network traffic

[Martin Rakhmanov]

I've found some tips like using serf library instead of neon to lower network 
traffic 'svn cat' generates but still it produces more than 50 packets. Is 
there a way to tweak it so there are about two-three packets for this?

Thanks in advance

Re: Detecting CR eol

[Ulrich Eckhardt]

On Wednesday 08 September 2010, Giulio Troccoli wrote:
> I remeber having problems with svn:eol-style set to native. I think
> Subversion did not checkout the files with the correct EOL based on
> the platform, but maybe that was because the files were actually
> being committed with mixed EOLs. 

It works for me.

That said, typical errors seem to be sharing working copies between different 
OSs, like Windows and Cygwin or Linux.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RE: Detecting CR eol

[Giulio Troccoli]

> On Wednesday 08 September 2010, Giulio Troccoli wrote:
> > I remeber having problems with svn:eol-style set to native. I think
> > Subversion did not checkout the files with the correct EOL based on
> > the platform, but maybe that was because the files were
> actually being
> > committed with mixed EOLs.
>
> It works for me.
>
> That said, typical errors seem to be sharing working copies
> between different OSs, like Windows and Cygwin or Linux.

We don't share working copies, of that I'm sure.

I'll do some testing, after all we were using SVN 1.3, if not even 1.2, at that 
time.

G


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Re: Subversion encountered a serious problem - during svn update

[Daniel Shahaf]

Just write a loop in some language that does

for (i = 0; i <= HEAD; i++)
call(fsfsverify, i);
 
Patrick Fletcher wrote on Tue, Sep 07, 2010 at 16:43:02 -0400:
> I see. I have no idea which revisions are problematic as a whole, I have
> only run into specific cases, of which the only way I could get around and
> continue working was to dump working copy and checkout HEAD again. 
> 
> Only reason cygwin came into picture was to run the .sh file.
> 
> I have already run and the normal svnadmin verify which says everything is
> fine... Still trying to pinpoint where and what the actual problem is. The
> info in the first email was just to try to help. I have no idea what the
> actual problem could be. I believe you said this was a more thorough
> examination (may turn up things svnadmin verify will not). Can I command
> line the fsfsverify.py to check every revision? If not, can I just write
> something to do it for me iteratively... Obviously don't want to fix (-f)
> anything yet as I don't know where the problem lies, but I can find no
> explanation of the other flags available and I am python nub.
> 
> Thanks for bearing with me!
> 
> Patrick Fletcher
> Marquis Software Development
> Business Phone: (850) 877-8864 x132
> Business Fax: (850) 877-0359
> 
> 
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de] 
> Sent: Tuesday, September 07, 2010 4:30 PM
> To: Patrick Fletcher
> Cc: Tony Sweeney; users@subversion.apache.org
> Subject: Re: Subversion encountered a serious problem - during svn update
> 
> On Tue, Sep 07, 2010 at 03:09:15PM -0400, Patrick Fletcher wrote:
> > Ahh... Thanks a bunch. The Python file indeed had similar errors. Now when
> I
> > run I get:
> > 
> > 
> > patri...@desk28 /cygdrive/g/Subversion
> > $ ./verify-revisions.sh Repositories/eomis_1_6_12
> > /usr/bin/seq: invalid floating point argument: 93909
> > Try `/usr/bin/seq --help' for more information.
> > 
> > 
> > 93909 is HEAD revision. Any ideas?
> 
> I'm not a windows expert so the script may fail on cygwin.
> I've tested it on Linux and BSD.
> 
> But if you already know which revisions are problematic, you don't need
> my script. Just run fsfsverify.py on the problematic revisions directly.
> For instance: fsfsverify.py /path/to/repos/db/revs/0/42
> 
> Stefan
> 
> 

Re: Howto minimize 'svn cat' network traffic

[Daniel Shahaf]

How about

% wget http://svn.apache.org/repos/asf/subversion/trunk/CHANGES?p=874150

(and did you mean "packets" or "round trips" or "requests"...)

Martin Rakhmanov wrote on Wed, Sep 08, 2010 at 09:26:56 -0400:
> I've found some tips like using serf library instead of neon to lower network 
> traffic 'svn cat' generates but still it produces more than 50 packets. Is 
> there a way to tweak it so there are about two-three packets for this?
> 
> Thanks in advance
> 

Re: Renaming a branch

[Daniel Shahaf]

Giulio Troccoli wrote on Wed, Sep 08, 2010 at 14:36:45 +0100:
> The problem would be if you had merged rel_2_5 to, let's say, rel_3_0. In
> that case you would need to edit the svn:mergeinfo property (using svn
> propedit not svn propset).
> 

Are you sure?  AFAIK the mergeinfo logic takes care about moves and
interprets peg revisions correctly, etc.

> G

Re: Help with Mac repositry permissions

[Tyler Roscoe]

On Wed, Sep 08, 2010 at 07:47:28PM +1000, Matthew Allen wrote:
>   sudo find /path/to/repo -type d -exec chmod 770 {} \;
> 
> I don't know what the "2" does in front of the 770. But it looks like it 
> still works... so maybe thats all there is to it?

The 2 controls the sticky bit. Mode 2770 says read-write-execute
permissions for user and group and the group sticky bit set to on.

See the chmod(1) man page for details on what sticky bits do.

tyler

Re: Detecting CR eol

[Campbell Allan]

On Wednesday 08 Sep 2010, Giulio Troccoli wrote:
> > I don't believe you have to go to so much trouble in the
> > pre-commit hook. If you have set the svn:eol-style property
> > then subversion will ensure the file has those line endings
> > on checkout and update them when committing into the
> > repository. So all the hook needs to do is check for the
> > property. See the book for more details
> >
> > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advan
> > ced.props.special.eol-style
>
> I'm not sure. Are you saying that if I set the svn:eol-style property to
> LF, for example, and my file has at least one line ending with CRLF, then
> Subversion will reject the commit? The book doesn't quite say that, and
> that wasn't my understanding on how the property works.
>

Before sending my previous reply I had tested it with a file changed using 
unix2dos. Prior to the commit svn diff only shows the text changes ignoring 
the line endings. I haven't explicitly tested changing a single line ending 
within the file but have done a quick concatenation test with half the file 
with LF and the other half CRLF. When committed the entire file in the 
working copy is changed to LF.

The part of the book that I felt was relevant is when the line ending is set 
to native subversion will store the file in the repository with LF's only. 
The client is then changing this to reflect the preferences of the client OS.

> > I'd also normally expect the line ending style to be set to
> > native so windows and unix users don't trample the existing
> > incompatible line endings. The only reason perhaps for
> > checking each file explicitly would be if there was something
> > else needing the files to be in a particular format, ie
> > releases to customers from a developer machine rather than an
> > official build server that would check out a clean copy each time.
>
> The requirement, to have LF, came a long time ago. I remeber having
> problems with svn:eol-style set to native. I think Subversion did not
> checkout the files with the correct EOL based on the platform, but maybe
> that was because the files were actually being committed with mixed EOLs.
>
> G
>
>
> Linedata Limited
> Registered Office: 85 Gracechurch St., London, EC3V 0AA
> Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

This may have occurred if the property was set after the files had been 
versioned with the mixed line endings but I'm only guessing. Whenever I've 
set the property I've also ran the dos2unix command on the files. We've not 
noticed any problems with the value being set to native and we're running a 
fairly old server (1.4.6) with mainly 1.5 clients.

-- 

__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__

RE: Subversion encountered a serious problem - during svn update

[Patrick Fletcher]

Thanks Daniel. Please verify:

- call fsfsverify.py with no flags set for every single revision
iteratively?

>>> fsfsverify.py [repo]/db/revs/[?]/[?]

What kind of output to expect? Is a verbose process or can I just watch for
any output?

If corruption is found from output, do I run on single revision with -f flag
or reply to thread with results? What are other flags (can't find
documentation and may be missing something obvious)?

Thanks again.

Patrick Fletcher
Marquis Software Development
Business Phone: (850) 877-8864 x132
Business Fax: (850) 877-0359


-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Wednesday, September 08, 2010 10:17 AM
To: Patrick Fletcher
Cc: 'Stefan Sperling'; 'Tony Sweeney'; users@subversion.apache.org
Subject: Re: Subversion encountered a serious problem - during svn update

Just write a loop in some language that does

for (i = 0; i <= HEAD; i++)
call(fsfsverify, i);
 
Patrick Fletcher wrote on Tue, Sep 07, 2010 at 16:43:02 -0400:
> I see. I have no idea which revisions are problematic as a whole, I have
> only run into specific cases, of which the only way I could get around and
> continue working was to dump working copy and checkout HEAD again. 
> 
> Only reason cygwin came into picture was to run the .sh file.
> 
> I have already run and the normal svnadmin verify which says everything is
> fine... Still trying to pinpoint where and what the actual problem is. The
> info in the first email was just to try to help. I have no idea what the
> actual problem could be. I believe you said this was a more thorough
> examination (may turn up things svnadmin verify will not). Can I command
> line the fsfsverify.py to check every revision? If not, can I just write
> something to do it for me iteratively... Obviously don't want to fix (-f)
> anything yet as I don't know where the problem lies, but I can find no
> explanation of the other flags available and I am python nub.
> 
> Thanks for bearing with me!
> 
> Patrick Fletcher
> Marquis Software Development
> Business Phone: (850) 877-8864 x132
> Business Fax: (850) 877-0359
> 
> 
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de] 
> Sent: Tuesday, September 07, 2010 4:30 PM
> To: Patrick Fletcher
> Cc: Tony Sweeney; users@subversion.apache.org
> Subject: Re: Subversion encountered a serious problem - during svn update
> 
> On Tue, Sep 07, 2010 at 03:09:15PM -0400, Patrick Fletcher wrote:
> > Ahh... Thanks a bunch. The Python file indeed had similar errors. Now
when
> I
> > run I get:
> > 
> > 
> > patri...@desk28 /cygdrive/g/Subversion
> > $ ./verify-revisions.sh Repositories/eomis_1_6_12
> > /usr/bin/seq: invalid floating point argument: 93909
> > Try `/usr/bin/seq --help' for more information.
> > 
> > 
> > 93909 is HEAD revision. Any ideas?
> 
> I'm not a windows expert so the script may fail on cygwin.
> I've tested it on Linux and BSD.
> 
> But if you already know which revisions are problematic, you don't need
> my script. Just run fsfsverify.py on the problematic revisions directly.
> For instance: fsfsverify.py /path/to/repos/db/revs/0/42
> 
> Stefan
> 
> 

Re: Detecting CR eol

[Ryan Schmidt]

On Sep 8, 2010, at 07:45, Campbell Allan wrote:
> On Wednesday 08 Sep 2010, Csaba Raduly wrote:
> I don't believe you have to go to so much trouble in the pre-commit hook. If 
> you have set the svn:eol-style property then subversion will ensure the file 
> has those line endings on checkout and update them when committing into the 
> repository. So all the hook needs to do is check for the property. See the 
> book for more details

I understood this was the client's responsibility. So while the official 
Subversion client does this, and presumably the reputable other clients that 
use the Subversion libraries do this, there is nothing on the server side that 
enforces that this is the case. I know it is possible to get files with the 
wrong eol style into the repository by loading a dump file; maybe it is also 
possible using language bindings. So checking in a pre-commit hook script that 
line endings of files with svn:eol-style set are indeed LF seems like a smart 
idea to me.

Re: Detecting CR eol

[Ryan Schmidt]

On Sep 8, 2010, at 10:27, Campbell Allan wrote:

> Before sending my previous reply I had tested it with a file changed using 
> unix2dos. Prior to the commit svn diff only shows the text changes ignoring 
> the line endings. I haven't explicitly tested changing a single line ending 
> within the file but have done a quick concatenation test with half the file 
> with LF and the other half CRLF. When committed the entire file in the 
> working copy is changed to LF.

As I recall, if a file with svn:eol-style set has inconsistent line endings 
(e.g. some LF, some CRLF), Subversion will reject the commit and require the 
user to make the file's line endings consistent before proceeding. Though I 
don't know whether this is happening on the client or on the server.


> The part of the book that I felt was relevant is when the line ending is set 
> to native subversion will store the file in the repository with LF's only. 
> The client is then changing this to reflect the preferences of the client OS.

My understanding is that if svn:eol-style is set to *any value* then the 
repository stores the file with LF line endings and the client does eol 
translation to your desired style.

Re: Subversion encountered a serious problem - during svn update

['Daniel Shahaf']

The real answer is "read Stefan's script and do whatever it does".

The core is this:

### equivalent to: for ($revision = 1; $revision <= $head_rev; 
$revision++)
for revision in `$_seq $head_rev`
do
if [ -n "$shards" ]
then
shard_dir="`expr $revision / $shards`"
else
shard_dir=""
fi

if [ -f "$repository/db/revs/${shard_dir}.pack" ]
then
echo -n "Repository $repository has packing enabled "
echo "but fsfsverify.py does not support packed FSFS "
echo "repositories - skipping"
break
fi

echo -n "Checking $repository r${revision}: "
fsfsverify.py "$repository/db/revs/$shard_dir/$revision" 
>/dev/null
if [ "$?" != "0" ]
then
echo "BAD"
bad_revs="$bad_revs $revision"
else
echo "ok"
fi

done


So (more below):

Patrick Fletcher wrote on Wed, Sep 08, 2010 at 11:49:58 -0400:
> Thanks Daniel. Please verify:
> 
> - call fsfsverify.py with no flags set for every single revision
> iteratively?
> 
> >>> fsfsverify.py [repo]/db/revs/[?]/[?]
> 

Yes.

> What kind of output to expect? Is a verbose process or can I just watch for
> any output?
> 

Ignore stdout.  If there is anything on stderr, I suppose you can post
it here.  (As long as the output contains only offsets and checksums,
there is no confidentiality issue in posting it here.)

> If corruption is found from output, do I run on single revision with -f flag
> or reply to thread with results? What are other flags (can't find
> documentation and may be missing something obvious)?
> 

As the script stands, it's "post back to the thread".  The -f flag is
the "attempt to fix" flag.

> Thanks again.
> 
> Patrick Fletcher
> Marquis Software Development
> Business Phone: (850) 877-8864 x132
> Business Fax: (850) 877-0359
> 
> 
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: Wednesday, September 08, 2010 10:17 AM
> To: Patrick Fletcher
> Cc: 'Stefan Sperling'; 'Tony Sweeney'; users@subversion.apache.org
> Subject: Re: Subversion encountered a serious problem - during svn update
> 
> Just write a loop in some language that does
> 
>   for (i = 0; i <= HEAD; i++)
>   call(fsfsverify, i);
>  
> Patrick Fletcher wrote on Tue, Sep 07, 2010 at 16:43:02 -0400:
> > I see. I have no idea which revisions are problematic as a whole, I have
> > only run into specific cases, of which the only way I could get around and
> > continue working was to dump working copy and checkout HEAD again. 
> > 
> > Only reason cygwin came into picture was to run the .sh file.
> > 
> > I have already run and the normal svnadmin verify which says everything is
> > fine... Still trying to pinpoint where and what the actual problem is. The
> > info in the first email was just to try to help. I have no idea what the
> > actual problem could be. I believe you said this was a more thorough
> > examination (may turn up things svnadmin verify will not). Can I command
> > line the fsfsverify.py to check every revision? If not, can I just write
> > something to do it for me iteratively... Obviously don't want to fix (-f)
> > anything yet as I don't know where the problem lies, but I can find no
> > explanation of the other flags available and I am python nub.
> > 
> > Thanks for bearing with me!
> > 
> > Patrick Fletcher
> > Marquis Software Development
> > Business Phone: (850) 877-8864 x132
> > Business Fax: (850) 877-0359
> > 
> > 
> > -Original Message-
> > From: Stefan Sperling [mailto:s...@elego.de] 
> > Sent: Tuesday, September 07, 2010 4:30 PM
> > To: Patrick Fletcher
> > Cc: Tony Sweeney; users@subversion.apache.org
> > Subject: Re: Subversion encountered a serious problem - during svn update
> > 
> > On Tue, Sep 07, 2010 at 03:09:15PM -0400, Patrick Fletcher wrote:
> > > Ahh... Thanks a bunch. The Python file indeed had similar errors. Now
> when
> > I
> > > run I get:
> > > 
> > > 
> > > patri...@desk28 /cygdrive/g/Subversion
> > > $ ./verify-revisions.sh Repositories/eomis_1_6_12
> > > /usr/bin/seq: invalid floating point argument: 93909
> > > Try `/usr/bin/seq --help' for more information.
> > > 
> > > 
> > > 93909 is HEAD revision. Any ideas?
> > 
> > I'm not a windows expert so the script may fail on cygwin.
> > I've tested it on Linux and BSD.
> > 
> > But if you already know which revisions are problematic, you don't need
> > my script. Just run fsfsverify.py on the problematic revisions directly.
> > For instance: fsfsverify.py /path/to/repos/db/revs/0/42
> > 
> > Stefan
> >

RE: Subversion encountered a serious problem - during svn update

[Patrick Fletcher]

> The real answer is "read Stefan's script and do whatever it does".

Not at all helpful. I thought this is where I am supposed to ask questions
that I do not know the answer to... I would not ask anything without trying
to figure it out myself first, up to a certain point. Is it reasonable to
ask me to go decipher a scripting language that I do not recognize? If I had
any idea of what it is trying to do I would have done that myself and not
asked the **specific** questions that I asked. I did appreciate the exchange
up to this point.

Subversion blows our current team provider out of the water. I love it. I
preach it to our office and anyone else who will listen. This has been the
only problem so far migrating the old repository with full history
while maintaining current builds and in-house products and allowing seamless
switch over, which has been quite a task. This is an error that I have not
understood from the start of the original posting to the thread, and still
do not understand. I would really prefer to know what it even means in
layman's terms from someone who might know as well as fix, as opposed to
just fix. Maybe it could be avoided in a different manner, but I don't write
c or shell scripts or python for that matter so I am at a huge loss there. I
do not know the inner workings of Subversion.. I understand you are all
volunteers and I think what you do is awesome, and that you are not required
to answer any questions posted to the group. I appreciate it all very much,
and what the whole open source community does for all of us. Couldn't do
what I do without it, but if I need a bit of help, I do not feel responses
like this are necessary.

Patrick Fletcher
Marquis Software Development
Business Phone: (850) 877-8864 x132
Business Fax: (850) 877-0359


-Original Message-
From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] 
Sent: Wednesday, September 08, 2010 1:41 PM
To: Patrick Fletcher
Cc: 'Stefan Sperling'; 'Tony Sweeney'; users@subversion.apache.org
Subject: Re: Subversion encountered a serious problem - during svn update

The real answer is "read Stefan's script and do whatever it does".

The core is this:

### equivalent to: for ($revision = 1; $revision <= $head_rev;
$revision++)
for revision in `$_seq $head_rev`
do
if [ -n "$shards" ]
then
shard_dir="`expr $revision / $shards`"
else
shard_dir=""
fi

if [ -f "$repository/db/revs/${shard_dir}.pack" ]
then
echo -n "Repository $repository has packing enabled
"
echo "but fsfsverify.py does not support packed FSFS
"
echo "repositories - skipping"
break
fi

echo -n "Checking $repository r${revision}: "
fsfsverify.py "$repository/db/revs/$shard_dir/$revision"
>/dev/null
if [ "$?" != "0" ]
then
echo "BAD"
bad_revs="$bad_revs $revision"
else
echo "ok"
fi

done


So (more below):

Patrick Fletcher wrote on Wed, Sep 08, 2010 at 11:49:58 -0400:
> Thanks Daniel. Please verify:
> 
> - call fsfsverify.py with no flags set for every single revision
> iteratively?
> 
> >>> fsfsverify.py [repo]/db/revs/[?]/[?]
> 

Yes.

> What kind of output to expect? Is a verbose process or can I just watch
for
> any output?
> 

Ignore stdout.  If there is anything on stderr, I suppose you can post
it here.  (As long as the output contains only offsets and checksums,
there is no confidentiality issue in posting it here.)

> If corruption is found from output, do I run on single revision with -f
flag
> or reply to thread with results? What are other flags (can't find
> documentation and may be missing something obvious)?
> 

As the script stands, it's "post back to the thread".  The -f flag is
the "attempt to fix" flag.

> Thanks again.
> 
> Patrick Fletcher
> Marquis Software Development
> Business Phone: (850) 877-8864 x132
> Business Fax: (850) 877-0359
> 
> 
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
> Sent: Wednesday, September 08, 2010 10:17 AM
> To: Patrick Fletcher
> Cc: 'Stefan Sperling'; 'Tony Sweeney'; users@subversion.apache.org
> Subject: Re: Subversion encountered a serious problem - during svn update
> 
> Just write a loop in some language that does
> 
>   for (i = 0; i <= HEAD; i++)
>   call(fsfsverify, i);
>  
> Patrick Fletcher wrote on Tue, Sep 07, 2010 at 16:43:02 -0400:
> > I see. I have no idea which revisions are problematic as a whole, I have
> > only run into specific cases, of which the only way I could get around
and
> > continue working was to dump working copy and checkout HEAD again. 
> > 
> > Only reason cygwin came in

Re: Subversion encountered a serious problem - during svn update

['Daniel Shahaf']

Patrick Fletcher wrote on Wed, Sep 08, 2010 at 14:35:54 -0400:
> > The real answer is "read Stefan's script and do whatever it does".
> 
> Not at all helpful. 

Read the rest of my response then.  You asked specific questions, I told
you which part of the script contained the answers AND answered your
specific questions.

(Search for "Yes" in the previous mail.)

Daniel

RE: Subversion encountered a serious problem - during svn update

[Patrick Fletcher]

Ha! I thought that was your response along with the original script contents
in post. Seemed like you were shrugging me off. I will look back.

Patrick Fletcher
Marquis Software Development
Business Phone: (850) 877-8864 x132
Business Fax: (850) 877-0359


-Original Message-
From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] 
Sent: Wednesday, September 08, 2010 3:02 PM
To: Patrick Fletcher
Cc: 'Stefan Sperling'; 'Tony Sweeney'; users@subversion.apache.org
Subject: Re: Subversion encountered a serious problem - during svn update

Patrick Fletcher wrote on Wed, Sep 08, 2010 at 14:35:54 -0400:
> > The real answer is "read Stefan's script and do whatever it does".
> 
> Not at all helpful. 

Read the rest of my response then.  You asked specific questions, I told
you which part of the script contained the answers AND answered your
specific questions.

(Search for "Yes" in the previous mail.)

Daniel

Re: Subversion encountered a serious problem - during svn update

[Les Mikesell]

On 9/8/2010 1:35 PM, Patrick Fletcher wrote:

The real answer is "read Stefan's script and do whatever it does".


Not at all helpful. I thought this is where I am supposed to ask questions
that I do not know the answer to...


I didn't follow the whole thread here, but have you completely ruled out 
the possibility that some operation in your working copy is modifying 
the pristine copies under .svn?


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

Re: Subversion encountered a serious problem - during svn update

[Mothmonsterman]

Thats the first I've heard something like that... Great point.

I will verify that over the next day or two. Thanks!

On Sep 8, 3:17 pm, Les Mikesell  wrote:
> On 9/8/2010 1:35 PM, Patrick Fletcher wrote:
>
> >> The real answer is "read Stefan's script and do whatever it does".
>
> > Not at all helpful. I thought this is where I am supposed to ask questions
> > that I do not know the answer to...
>
> I didn't follow the whole thread here, but have you completely ruled out
> the possibility that some operation in your working copy is modifying
> the pristine copies under .svn?
>
> --
>    Les Mikesell
>     lesmikes...@gmail.com

Re: Help with Mac repositry permissions

[Ryan Schmidt]

On Sep 8, 2010, at 04:53, Giulio Troccoli wrote:

>> Also the /Users folder perms is:
>>  drwxr-xr-x   6 root  admin   204 18 Aug 10:03 Users
> 
> Now, there's your answer. The user that runs theweb server, _www, has 
> permission to access /Users only becuase of the others permissions __r-x.
> 
> You could change the ownership of /Users to _www but I guess the /Users 
> contains also the home directories of your users so this woldn't be 
> acceptable.
> 
> Why don't you create a directory directly under / owned by _www and access by 
> _www only, for example
> 
> mkdir /repos
> chown _www /repos
> chmod 700 /repos
> cp -R /Users/Svn /repos
> 
> Check that the permission of /repos/Svn are still correct and then amend your 
> web server configuration file so that the repository points to /repos/Svn and 
> not /Users/Svn

Or consider using the existing web server hierarchy Apple already established. 
There's already /Library/WebServer/Documents (the document root) and 
/Library/WebServer/CGI-Executables (the cgi-bin); consider storing your 
repositories in /Library/WebServer/Subversion (there are some Google hits for 
this so someone else thought of this before).

feature request: handle archives as like directory trees

[Ds Jstc]

 Initially I just wanted keyword substitution inside a .xltm file.  But 
really, Office 2007 documents are just zip files, and that got me 
thinking that the problem is more general.


Many of the best features of subversion only operate on text.  
Unfortunately, there are tons of compound document formats out there 
that actually *are* text, when you get right down to it.  The text just 
happens to be compressed and collected with some other stuff.


So... what if a compressed archive was extracted during checkin, and 
re-archived on checkout?  This would

(a) more easily allow for text diffs between versions of documents.
(b) permit keyword substitution
(c) allow the choice of other, more effective compression (eg, bz2) on 
the back end.


Thoughts?

Re: feature request: handle archives as like directory trees

[Ryan Schmidt]

On Sep 8, 2010, at 16:03, Ds Jstc wrote:

> Initially I just wanted keyword substitution inside a .xltm file.  But 
> really, Office 2007 documents are just zip files, and that got me thinking 
> that the problem is more general.
> 
> Many of the best features of subversion only operate on text.  Unfortunately, 
> there are tons of compound document formats out there that actually *are* 
> text, when you get right down to it.  The text just happens to be compressed 
> and collected with some other stuff.
> 
> So... what if a compressed archive was extracted during checkin, and 
> re-archived on checkout?  This would
> (a) more easily allow for text diffs between versions of documents.
> (b) permit keyword substitution
> (c) allow the choice of other, more effective compression (eg, bz2) on the 
> back end.
> 
> Thoughts?

This has come up before, and it sounds like a useful feature to me. But I don't 
use these types of documents so I haven't had a need to pursue the matter.

svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Daniel Trebbien]

I am attempting to use `svnsync` to create a local mirror of
`svn://svn.sv.gnu.org/nano`, but every time it fails at revision 619
(http://svn.savannah.gnu.org/viewvc?view=rev&root=nano&revision=619):
...
Copied properties for revision 617.
Transmitting file data ...
Committed revision 618.
Copied properties for revision 618.
svnsync: Error while replaying commit


The problem is that the log message for revision 619, 'Added Galician
translation by Jacobo Tarrío', was encoded in ISO-8859-1, and this is an illegal
UTF-8 byte sequence starting at the accented 'i'.

I attempted to set `log-encoding = ISO-8859-1` in my `~/.subversion/config`,
but this did not work. Moreover, looking through the source of `svnsync`, I
do not immediately see how to fix this problem. How do I tell `svnsync` to treat
the log messages from the repository as ISO-8859-1-encoded strings rather than
UTF-8-encoded strings?

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Daniel Shahaf]

Can you propedit the property in the repository you're syncing from?

Failing that, see normalize_string() in subversion/svnsync/sync.c.


Daniel Trebbien wrote on Wed, Sep 08, 2010 at 22:25:11 +:
> I am attempting to use `svnsync` to create a local mirror of
> `svn://svn.sv.gnu.org/nano`, but every time it fails at revision 619
> (http://svn.savannah.gnu.org/viewvc?view=rev&root=nano&revision=619):
> ...
> Copied properties for revision 617.
> Transmitting file data ...
> Committed revision 618.
> Copied properties for revision 618.
> svnsync: Error while replaying commit
> 
> 
> The problem is that the log message for revision 619, 'Added Galician
> translation by Jacobo Tarrío', was encoded in ISO-8859-1, and this is an 
> illegal
> UTF-8 byte sequence starting at the accented 'i'.
> 
> I attempted to set `log-encoding = ISO-8859-1` in my `~/.subversion/config`,
> but this did not work. Moreover, looking through the source of `svnsync`, I
> do not immediately see how to fix this problem. How do I tell `svnsync` to 
> treat
> the log messages from the repository as ISO-8859-1-encoded strings rather than
> UTF-8-encoded strings?
> 

value in 'svnadmin verify' cron job? (or is 'svnadmin hotcopy' enough?)

[svn]

Assuming a nightly 'svnadmin hotcopy' is run w/o errors, is
there value in periodically running one or both of?:

  svnadmin verify REPO-PATHNAME 2>&1 |egrep -v '^\* Verified revision [0-9]+\.'

  svnadmin dump -q --deltas REPO-PATHNAME >/dev/null

Goal of grep and redirects is to only display errors or warnings.

--
Does a successful 'svnadmin hotcopy' indicate a clean bill of
health for the repository, or might 'svnadmin verify' still
locate problems?

Would like to detect corruption in repository as soon as possible.

--
thanks
Tom

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Daniel Trebbien]

On Wed, Sep 8, 2010 at 3:58 PM, Daniel Shahaf  wrote:
> Can you propedit the property in the repository you're syncing from?

No, as I only have read access to `svn://svn.sv.gnu.org/nano`.

> Failing that, see normalize_string() in subversion/svnsync/sync.c.

I looked at the trunk sources for `svnsync`, but the
`normalize_string` function appears to adjust line ending style only.
I think that a call to `svn_subst_translate_string`
(http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) needs to be
added in the `svnsync_normalize_revprops` function when `propname` is
"svn:log".

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Daniel Trebbien]

On Wed, Sep 8, 2010 at 4:39 PM, Daniel Trebbien  wrote:
> I think that a call to `svn_subst_translate_string`
> (http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) needs to be
> added in the `svnsync_normalize_revprops` function when `propname` is
> "svn:log".

After applying the following patch to `subversion/svnsync/sync.c`, I
can confirm that the "svnsync: Error while replaying commit" error
disappears, allowing the sync to complete, and that the problem is
indeed a log message encoding issue:
diff --git a/subversion/svnsync/sync.c b/subversion/svnsync/sync.c
index 8f7be9e..c7a5e38 100644
--- a/subversion/svnsync/sync.c
+++ b/subversion/svnsync/sync.c
@@ -114,6 +114,14 @@ svnsync_normalize_revprops(apr_hash_t *rev_props,
   /* And count this. */
   (*normalized_count)++;
 }
+
+  if (strcmp(propname, "svn:log") == 0)
+{
+  svn_string_t *new_propval;
+  SVN_ERR(svn_subst_translate_string(&new_propval,
propval, "ISO-8859-1", pool));
+  apr_hash_set(rev_props, propname, APR_HASH_KEY_STRING,
propval = new_propval);
+  (*normalized_count)++;
+}
 }
 }
   return SVN_NO_ERROR;


Here I hard-coded the encoding, but I think that the encoding to use
should be retrieved from the Subversion config file. Now the questions
are:

1. What is the best way to pass the `log-encoding` option of the
[miscellany] section to the `svnsync_normalize_revprops` function?

2. Should `svnsync` always store the log messages in UTF-8 even though
the original repository log message encoding is different?

3. Should there be separate configuration options for the log message
encoding of the source repository and the log message encoding of the
destination repository?

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Ryan Schmidt]

On Sep 8, 2010, at 18:39, Daniel Trebbien wrote:

> On Wed, Sep 8, 2010 at 3:58 PM, Daniel Shahaf  wrote:
>> Can you propedit the property in the repository you're syncing from?
> 
> No, as I only have read access to `svn://svn.sv.gnu.org/nano`.

Ask someone who has write access to that repository to fix the encoding of the 
log message. All log messages in Subversion shall be UTF-8 encoded, but I guess 
older versions of Subversion didn't necessarily enforce that.

Using PAM to authenticate user?

[Curley, John]

Has anyone use Pluggable Authentication Module (PAM) for user
authentication, within Subversion?
 
If that is currently not supported, is it possibly future option?
 
Thank you,
--John
 
 
"Living on Earth may be expensive, but it includes an annual free trip
around the Sun." 
~author unknown
 

RE: Using PAM to authenticate user?

[Curley, John]

> -Original Message-
> From: Curley, John [mailto:john.cur...@windriver.com] 
> Sent: Wednesday, September 08, 2010 11:33 PM
> To: users@subversion.apache.org
> Subject: Using PAM to authenticate user?
> 
> Has anyone use Pluggable Authentication Module (PAM) for user
authentication, within Subversion?
>  
> If that is currently not supported, is it possibly future option?
>  
> Thank you,
> --John
>  
>  
> "Living on Earth may be expensive, but it includes an annual free trip
around the Sun." 
> ~author unknown
 

I forgot to add, like RSA? 

Re: Using PAM to authenticate user?

[Alexander Skwar]

There are modules for apache out there, which allow PAM auth. Mod-auth- 
external seems to be easy to use (haven't tried it myself, though).


http://code.google.com/p/mod-auth-external/

Alexander

Am 09.09.2010 um 08:42 schrieb "Curley, John"  
:



-Original Message-
From: Curley, John [mailto:john.cur...@windriver.com]
Sent: Wednesday, September 08, 2010 11:33 PM
To: users@subversion.apache.org
Subject: Using PAM to authenticate user?

Has anyone use Pluggable Authentication Module (PAM) for user

authentication, within Subversion?


If that is currently not supported, is it possibly future option?

Thank you,
--John


"Living on Earth may be expensive, but it includes an annual free  
trip

around the Sun."

~author unknown



I forgot to add, like RSA?