svnsync: Got unexpected element svn::open-directory

[War man]

 Hi

I have been running svnsync between 2 repositories (master using CollabNet
Subversion 1.6.2 and slave using 1.6.6 over http) for 3 months and it has
worked flawlessly.
The repository is about 600MB with mostly source code, about 7000 revisions
and a lot of branches (with the resulting large mergeinfo properties).

Suddenly last week one revision failed to sync with error message:
svnsync: Got unexpected element svn::open-directory
and the apache log saying:
Provider encountered an error while streaming a REPORT response. [500, #0]
Problem replaying revision [500, #190004]

First time this happened I just dump/loaded the whole repository again and
the syncing worked again for a while. Today the same error came back.

In the slave repository a new folder is created for every failed syncing
under db/transactions (for example 6909-545.txn) which has an increasing
index after it.

What can I do to fix this? What more information do I need to post to get
some help?

Any help would be much appreciated.

BR
Kristian

Re: Question about excessive mergeinfo

[Ulrich Eckhardt]

On Monday 11 January 2010, Stein Somers wrote:
> > I think SVN wants you to not copy the file/dir but instead to merge the
> > revision where it was added to the branch.
>
> Interesting idea, but as far as I get it it seems a complicated process:
>   - In the WC's target directory, merge a part of the changeset that
> created (or last moved) the wanted subdirectory. So now we're no longer
> only merging root directories.
>   - Inside the new subdirectory, merge the rest of the history of the
> source subdirectory.


Why only merge a part of the initial changeset? Did it contain multiple 
unrelated changes? If so, that's IMHO the first sin, one changeset should 
only contain one logical change, otherwise merging becomes a b1tch.

> And why would SVN not like copies? Forget that I wrote "from another
> branch", it happens inside a branch too (i.e. if the only active
> mergeinfo is in a parent directory shared by source and target of the
> copy). If you do a simple WC -> WC copy, you get no additional
> mergeinfo. If you do a URL -> WC copy on the same paths and revisions,
> you get explicit/excessive mergeinfo on top. I'm pretty sure that's a
> bug. But never mind, I can elide it myself. We'll see in 1.7.

Actually, if I merge a revision that only touches a subdir but don't target 
the root but the subdir instead, I also get explicit mergeinfo. If SVN was 
better, it would see that merging to the root would be the same and put the 
mergeinfo there. Alas, this feature is not implemented yet. However, I 
wouldn't call it a bug that SVN can't read my mind. And I'm sure some people 
would object when I merge to a subdir and suddenly SVN changes its parent's 
mergeinfo.


Cheers!

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: reuse of tag to keep stable URLs?

[Andrey Repin]

Greetings, Brian H. Toby!

> I am trying to get beyond my rather simple use of svn and would like  
> some advice. My goal is to have two releases of a package available,  
> one bleeding edge and the other stable. I want to keep the URLs to  
> both releases stable. This seems like a reasonably common thing that  
> one would want, but google has failed to find this discussed (probably  
> because I am using the wrong lingo to describe what I want.) Anyway, I  
> can see two ways to implement this:

> 1) Keep the bleeding-edge release in the trunk and use a tagged  
> version for the stable release. When I am ready to make a new stable  
> release, I delete the stable tagged release from the repository and  
> then copy the trunk reusing the same tag name.

> 2) keep the stable release as the trunk and work on the bleeding-edge  
> release as a branch. When I am ready to make a new stable release, I  
> use merge --reintegrate and commit to update the stable release and  
> then delete and recreate the  bleeding-edge branch.

> Option 2 seems to be the way that svn is designed to be used, but is  
> more complex. I guess it is more robust, if someone commits a change  
> to the stable. Are there any other reasons to go that route? Is there  
> an even better choice?

Nope. It's the case 1. You branching stable version to tags, leaving /trunk as
your workplace.
Could as well copy to branches:
copy /trunk to /tag/
delete /branch/stable
copy /tags/ to /branch/stable

/trunk is your mainstream, especially if you're working mainly alone on the
project.
If you need space for experimenting, or if you need to backport some changes
from trunk to stable, you create a new branch from stable branch, port
whatever you want to it, then merge it back to stable and delete the one you
used to backport.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 12.01.2010, <14:00>

Sorry for my terrible english...

SVN Server change Issue

[Miao Zhu]

HI Dear,

   I have a question about svn server change task.

   The status now we are at is:

   - we have 2 svn servers, one for daily-work using (http://svn.com,  
ip:10.0.9.120), another one is for svn server back up (http://svn_bak.com 
ip:10.0.9.121)
   - and both these 2 servers share the same storage which hosts the svn 
repositories (the storage is mounted as NFS directory)

   So, my question is:
   ===
   if we have svn server down, we want to start to work on svn_bak server.
   Most of users checked out source code with ip address( 
http://10.0.9.120/svnrep1 ) ,
   so if I change the ip address of svn back up server from 10.0.9.121 to 
10.0.9.120.  Can users work well without any change on their local working copy?

   I have checked the repository UUID of checked out working copy from each svn 
server are the same.

  So I think may be we can just change the ip address on the back up server to 
match the down svn server to make users work on going.

  But I'm not sure, would you please help to confirm this?

Thanks!


MIAO ZHU


<>

Fwd: Unable to change a commit message

[Johan Corveleyn]

[forwarding to users list, which I accidentally forgot to include]

On Mon, Jan 11, 2010 at 10:19 PM, Kari McNair  wrote:
> I'm trying to remove an invalid character from the end of a commit message.
> All the correct hooks are invoked but when I use...
> $ svn propset -r 671 --revprop svn:log "message" URL
> ...the command prompt window just hangs. I tried changing the message
> through TortoiseSVN but when I go to save the new message, it freezes. I've
> even just tried editing it from a Mac through Terminal and that just hangs
> as well. Anyone have any other ideas?

Only thing I can think of is that your pre-revprop-change hook causes
the hang. Can you share the contents of that hook?

Otherwise, as a first step, try to add some debug logging code to the
pre-revprop-change hook (echo some stuff to a file at the beginning of
your hook, and at the end). So you can see at least if the hook is
entered and exited correctly ...

Alternatively, if you don't care deeply about this issue, you can also
change log messages on the server itself by using the svnadmin command
(bypassing hooks if necessary):
-
$ svnadmin help setlog
setlog: usage: svnadmin setlog REPOS_PATH -r REVISION FILE

Set the log-message on revision REVISION to the contents of FILE.  Use
--bypass-hooks to avoid triggering the revision-property-related hooks
(for example, if you do not want an email notification sent
from your post-revprop-change hook, or because the modification of
revision properties has not been enabled in the pre-revprop-change
hook).

NOTE: Revision properties are not versioned, so this command will
overwrite the previous log message.

Valid options:
 -r [--revision] ARG      : specify revision number ARG (or X:Y range)
 --bypass-hooks           : bypass the repository hook system
-

Regards,
Johan

Re: SVN Server change Issue

[Ulrich Eckhardt]

On Tuesday 12 January 2010, Miao Zhu wrote:
>The status now we are at is:
>
>- we have 2 svn servers, one for daily-work using (http://svn.com, 
> ip:10.0.9.120), another one is for svn server back up (http://svn_bak.com
> ip:10.0.9.121) - and both these 2 servers share the same storage which
> hosts the svn repositories (the storage is mounted as NFS directory)

I believe network-mounted repositories are mentioned in the FAQ - they can 
generate problems. The preferred solution would be to replicate the 
repository using svnsync.

>if we have svn server down, we want to start to work on svn_bak server.
>Most of users checked out source code with ip address(
> http://10.0.9.120/svnrep1 ) , so if I change the ip address of svn back up
> server from 10.0.9.121 to 10.0.9.120.  Can users work well without any
> change on their local working copy?

Yes, that should work. Using some DNS-server hacking, you wouldn't even need 
to switch IPs of the servers, only the IP a virtual server is resolved to.

Otherwise, 'svn switch --relocate' allows rebinding a WC to a changed 
repository URL.

> I have checked the repository UUID of checked out working copy from each
> svn server are the same.

Yes, the UUID is a property of the repository and not affected by the server.

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: reuse of tag to keep stable URLs?

[Bob Archer]

> I am trying to get beyond my rather simple use of svn and would
> like
> some advice. My goal is to have two releases of a package
> available,
> one bleeding edge and the other stable. I want to keep the URLs to
> both releases stable. This seems like a reasonably common thing
> that
> one would want, but google has failed to find this discussed
> (probably
> because I am using the wrong lingo to describe what I want.)
> Anyway, I
> can see two ways to implement this:
> 
> 1) Keep the bleeding-edge release in the trunk and use a tagged
> version for the stable release. When I am ready to make a new
> stable
> release, I delete the stable tagged release from the repository and
> then copy the trunk reusing the same tag name.

Why not just merge the rev from trunk that you want to release into your stable 
branch/tag? Then create a tag for that version in case you need an older 
version sometime. If you never commit into stable branch other than merges 
there should never be conflicts. 

This seems cleaner to me than deleting and recreating branches. 

BOb

Re: reuse of tag to keep stable URLs?

[Brian H. Toby]

Thanks very much. (BTW, your english here was just about perfect.)

On Jan 12, 2010, at 5:06 AM, Andrey Repin wrote:


Greetings, Brian H. Toby!


I am trying to get beyond my rather simple use of svn and would like
some advice. My goal is to have two releases of a package available,
one bleeding edge and the other stable. I want to keep the URLs to
both releases stable. This seems like a reasonably common thing that
one would want, but google has failed to find this discussed  
(probably
because I am using the wrong lingo to describe what I want.)  
Anyway, I

can see two ways to implement this:



1) Keep the bleeding-edge release in the trunk and use a tagged
version for the stable release. When I am ready to make a new stable
release, I delete the stable tagged release from the repository and
then copy the trunk reusing the same tag name.



2) keep the stable release as the trunk and work on the bleeding-edge
release as a branch. When I am ready to make a new stable release, I
use merge --reintegrate and commit to update the stable release and
then delete and recreate the  bleeding-edge branch.



Option 2 seems to be the way that svn is designed to be used, but is
more complex. I guess it is more robust, if someone commits a change
to the stable. Are there any other reasons to go that route? Is there
an even better choice?


Nope. It's the case 1. You branching stable version to tags,  
leaving /trunk as

your workplace.
Could as well copy to branches:
copy /trunk to /tag/
delete /branch/stable
copy /tags/ to /branch/stable

/trunk is your mainstream, especially if you're working mainly alone  
on the

project.
If you need space for experimenting, or if you need to backport some  
changes

from trunk to stable, you create a new branch from stable branch, port
whatever you want to it, then merge it back to stable and delete the  
one you

used to backport.


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 12.01.2010, <14:00>

Sorry for my terrible english...




Brian H. Toby, Ph.D.office: 630-252-5488
Senior Physicist/Section Head for Scientific Software
Advanced Photon Source
9700 S. Cass Ave, Bldg. 401/B4192work cell: 630-327-8426
Argonne National Laboratory
Argonne, IL 60439-4856 e-mail: brian dot toby at anl dot gov

"We will restore science to its rightful place, and wield technology's  
wonders... We will harness the sun and the winds and the soil to fuel  
our cars and run our factories...  All this we can do. All this we  
will do."

Re: Question about excessive mergeinfo

[Geoff Rowell]

On Mon, Jan 11, 2010 at 8:28 AM, Stein Somers  wrote:
> No explanation here, and not the same symptoms, but you're not the only one
> struggling with it. I have a pre-commit hook to detect mergeinfo below root,
> and remove it whenever it occurs, which is rare. The repository has only
> mergeinfo on root directories, merges are done only on roots, no switched or
> shallow WC. No externals either. Still, svn 1.6.6 tries to push excessive
> mergeinfo your way. Luckily only plain and simple recursive mergeinfo.
>
> When copying by URL a subdirectory from another branch to somewhere in a WC,
> the new subdirectory always gets a mergeinfo property. Its value is a copy
> of the mergeinfo of the root of the source branch (where this "root" is an
> interpretation of course; more accurately, it is the nearest (and only)
> higher directory that has a mergeinfo property, relative to the copied
> subdirectory). Not surprisingly, the new mergeinfo is a subset of the
> mergeinfo of the current working copy root: fewer branches listed, fewer
> revisions listed. In my interpretation of the rules, this mergeinfo is
> entirely useless. So no thank you, I don't commit it.
>
Yes. My developers have seen this unwanted addition of mergeinfo from
URL copying, too.

The mergeinfo restriction in the hook has proven invaluable in
preventing a commit of it.
--
Geoff Rowell
geoff.row...@gmail.com

how to identify the version of mod_dav_svn installed

[Marc Lustig]

Although we have installed SVN 1.6.6, the web-page delivered reports 1.4.6

Could someone advise how to identify the version of mod_dav_svn
apache-module that is installed?

Ty.

Re: how to identify the version of mod_dav_svn installed

[Ryan Schmidt]

Quoting Marc Lustig:


Although we have installed SVN 1.6.6, the web-page delivered reports 1.4.6

Could someone advise how to identify the version of mod_dav_svn
apache-module that is installed?


I think you've already discovered how: look on the web page. It says  
1.4.6. You have mod_dav_svn from Subversion 1.4.6. Or at least, you  
did when Apache started. If you've since then updated mod_dav_svn,  
restart Apache to see this change.

Re: svn15-shlibs package dependencies

[Ryan Schmidt]

Quoting capmac:


I'm having trouble installing.  Mac Mini Intel Core Duo running OS X 10.6.2:



mini-Core-Duo:~ adminkoff$ fink install svn15-shlibs


[snip]


Can anybody help?


You appear to be using the Fink package manager, with which I'm not  
familiar. I didn't see the word "error" in your output, so I don't  
know if an error is actually occurring or whether Fink is working as  
intended. You should ask for help in a Fink support venue. Once you  
have used Fink to install Subversion, if you have trouble using it,  
you can ask again here.


As an alternative to Fink, Subversion installs great using the  
MacPorts package manager ("sudo port install subversion"), and  
standalone binary packages are also available for download from  
CollabNet.


http://www.macports.org/

http://www.open.collab.net/downloads/community/

Re: reuse of tag to keep stable URLs?

[Stein Somers]

"Moving tags" may be the lingu you were looking for.

--
Stein

NetDrive and SVN autoversioning - keep getting Broken pipe

[Gunther Mayer]

Hi guys,

I'm not sure if anyone here is working with the following combination 
(or similar):


Server: svn 1.6.5 (latest) + apache 2.2.12 (latest) on ubuntu 
karmic(9.10) 64bit

Client: Windows XP or Vista, NetDrive 1.0.8.11 (latest)

Server is configured to do autoversioning via WebDAV as per svnbook:


   DAV svn
   SVNParentPath /var/svn
   SVNAutoversioning on
   ModMimeUsePathInfo on


My client can mount(connect) this "drive" just fine and browse through 
the directory hierarchy but when trying to open any files they are 
corrupted because they're only half retrieved from the server (tried it 
on a couple of large text files). Every now and then NetDrive reports 
errors but nothing helpful. At the same time the following appears in my 
apache error logs over and over again:


[Tue Jan 12 13:42:32 2010] [error] [client xx.xx.xx.xx] (32)Broken pipe: 
Could not write data to filter.  [500, #0]
[Tue Jan 12 13:42:32 2010] [error] [client xx.xx.xx.xx] Unable to 
deliver content.  [500, #0]


and occasionally

[Tue Jan 12 13:42:31 2010] [error] [client 196.7.14.173] Unable to 
deliver content.  [500, #0]
[Tue Jan 12 13:42:31 2010] [error] [client 196.7.14.173] (104)Connection 
reset by peer: Could not write data to filter.  [500, #0]


This happens almost all the time and makes my repo kind of useless on 
Windows (no, tortoisesvn won't work because we're dealing with very 
non-technical users...). I know NetDrive is commercial software but 
firstly it did come recommended in the svn book with supposedly no known 
issues and secondly it is (apart from WebDrive) my only option when it 
comes to mounting my svn repository as a file system on Windows. It 
seems like some kind of buffering problem but not sure how helpful the 
Novell support will be in trouble shooting this one...


Any help or pointers would be greatly appreciated.

Gunther

Re: Assertion fail on TortoiseSVN Update

[Konstantin Kolinko]

2010/1/12 Leonardo Kausilas :
> Hi, I'm Leonardo and I'm a svn and TortoiseSVN user.
>
> Yesterday, I was working with TortoiseSVN, deleting a subfolder and when I
> try to update the parent folder,  the attached bug alert shown .
> Previously, the delete of the subfolder operation stop with errors and I
> should do it again (with success).
> Next, on the update, this bug alert shown.
>
> If you think that is a real bug, I'll write a complete bug report and send
> it to dev mailing list.

It is already fixed in SVN 1.6.6, that was released by the end of October 2009.

There is a "CHANGES" file at the root of SVN 1.6.x branch source code tree
that lists issues fixed in 1.6.x.


Best regards,
Konstantin Kolinko

Jira ticket notification hook?

[Aaron Turner]

Hi Everyone,

My company is moving from Trac (which has excellent SVN integration)
to Jira which seems to be a bit lacking.  One big issue is that we'd
like people who are watching a ticket get a notification of the commit
when a commit references that ticket.  Jira doesn't seem to support
that natively and most of our users don't want to be notified about
*every* commit- just the commits referencing tickets they care about.

I was hoping someone here was aware of a svn hook script which
implements this feature?

Thanks,
Aaron

-- 
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
"carpe diem quam minimum credula postero"

online tutorial on setting up new subversion/trac repo?

[Robert P. J. Day]

  can someone recommend a decent online tutorial to set up a new
subversion repo plus trac (that's relevant for fedora 12)?  i found
this:

http://www.yolinux.com/TUTORIALS/LinuxSubversionAndTracServer.html

but it seems to be overly verbose and doesn't specifically mention f12
(although i'm sure most of it is perfectly fine).

  i'm after the minimum presentation to get something like that going
as a demo, so i'm quite willing to skip things like, say, advanced
authentication (at least for now).

  if i have to rewrite that tutorial for fedora, then i'm willing to
post the final results somewhere.

  thoughts?

rday
--



Robert P. J. Day   Waterloo, Ontario, CANADA

Linux Consulting, Training and Kernel Pedantry.

Web page:  http://crashcourse.ca
Twitter:   http://twitter.com/rpjday

Re: how to identify the version of mod_dav_svn installed

[Marc Lustig]

thanks for the hint.
Can I just grab the mod_dav_svn.so and mod_authz.so files from Collabnet's 
1.6.6-rpm distribution and replace the existing modules with it? Or will it 
result in compatibility issues with the Apache-server?


Am 12.01.2010 um 16:43 schrieb Ryan Schmidt:

> Quoting Marc Lustig:
> 
>> Although we have installed SVN 1.6.6, the web-page delivered reports 1.4.6
>> 
>> Could someone advise how to identify the version of mod_dav_svn
>> apache-module that is installed?
> 
> I think you've already discovered how: look on the web page. It says 1.4.6. 
> You have mod_dav_svn from Subversion 1.4.6. Or at least, you did when Apache 
> started. If you've since then updated mod_dav_svn, restart Apache to see this 
> change.
> 
> 
> 

malformed file problem -- version 1.5.7

[James D. Parra]

Hello,

One of my users committed a file to svn and now some users are getting a
'malformed file' error. These users can no longer check out or commit.
'Svnadmin verify /svnrepos' doesn't show any problems, however 'malformed
file' appears when I do a nightly dump export; 

svnadmin dump /svnrepos > /backup/svnrepos.svn_dump

* Dumped revision 11529.
svnadmin: Malformed file


I believe the problem lies within revision numbers 11530 and 11532.  Other
users who are working on other projects are not having problems. We are
currently at revision 11784.  Is there a way that I can repair this?

Many thanks in advance,

James

sync bug -> corrupted proxy repo

[Andersen, Krista]

Twice I have seen one of my proxy repositories become corrupted due to an 
apparent bug in the svnsync sync process.  Has anyone else seen this type of 
behavior from Subversion?

I am able to move the corrupted proxy-repo and recreate it again without error 
- but I am a bit concerned about the stability of Subversion since this is the 
second time in two months that I have had to fix this issue.

Here is a comparison the output of the svn log -v for the offending revisions 
(324,325) on both the corrupted and non-corrupted proxy repo.  ***Notice a 
different author, earlier time for later rev, different action, different path, 
and different rev copied from***

[svnad...@subserver:/home/Svn/repos/OPT]> svn log -r 323:325 -v 
http://subserver/OPT/OPT.corrupted


r323 | optauto | 2010-01-06 06:22:07 +0200 (Wed, 06 Jan 2010) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.122/OptBackEnd (from /trunk/OptBackEnd:322)

Iteration 5.4.0.122 label.

r324 | svnservice | 2010-01-06 05:24:01 +0200 (Wed, 06 Jan 2010) | 1 line
Changed paths:
   R /tags/ITR_5.4.0.122/OptBackEnd (from /trunk/OptBackEnd:322)

Iteration 5.4.0.122 label.

r325 | svnservice | 2010-01-06 05:24:08 +0200 (Wed, 06 Jan 2010) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.122/OptFrontEnd (from /trunk/OptFrontEnd:323)

Iteration 5.4.0.122 label.


[svnad...@subserver:/home/Svn/repos/OPT]> svn log -r 323:325 -v 
http://subserver/OPT/OPT


r323 | optauto | 2010-01-06 06:22:07 +0200 (Wed, 06 Jan 2010) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.122/OptBackEnd (from /trunk/OptBackEnd:322)

Iteration 5.4.0.122 label.

r324 | optauto | 2010-01-06 06:22:08 +0200 (Wed, 06 Jan 2010) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.122/OptFrontEnd (from /trunk/OptFrontEnd:323)

Iteration 5.4.0.122 label.

r325 | optauto | 2010-01-06 06:22:09 +0200 (Wed, 06 Jan 2010) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.122/OPT (from /trunk/OPT:324)

Iteration 5.4.0.122 label.



Also, here is a comparison the output of the svn log -v for more offending 
revisions (49,50) on both the corrupted and non-corrupted proxy repo.  
***Notice again, the different authors, earlier time for later rev, different 
actions, different path, and different rev copied from***


[svnad...@subserver:/home/Svn/repos/OPT]> svn log -r 48:50 -v 
http://subserver/OPT/OPT.corrupted

r48 | optauto | 2009-11-09 19:19:19 +0200 (Mon, 09 Nov 2009) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.118/OptBackEnd (from /trunk/OptBackEnd:47)

Iteration 5.4.0.118 label.

R49 | svnservice | 2009-11-09 18:19:03 +0200 (Mon, 09 Nov 2009) | 1 line
Changed paths:
   R /tags/ITR_5.4.0.118/OptBackEnd (from /trunk/OptBackEnd:47)

Iteration 5.4.0.118 label.

R50 | svnservice | 2009-11-09 18:19:12 +0200 (Mon, 09 Nov 2009) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.118/OptFrontEnd (from /trunk/OptFrontEnd:48)

Iteration 5.4.0.118 label.


[svnad...@subserver:/home/Svn/repos/OPT]> svn log -r 48:50 -v 
http://subserver/OPT/OPT


r48 | optauto | 2009-11-09 19:19:19 +0200 (Mon, 09 Nov 2009) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.118/OptBackEnd (from /trunk/OptBackEnd:47)

Iteration 5.4.0.118 label.

r49 | optauto | 2009-11-09 19:19:20 +0200 (Mon, 09 Nov 2009) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.118/OptFrontEnd (from /trunk/OptFrontEnd:48)

Iteration 5.4.0.118 label.

r50 | optauto | 2009-11-09 19:19:21 +0200 (Mon, 09 Nov 2009) | 1 line
Changed paths:
   A /tags/ITR_5.4.0.118/OPT (from /trunk/OPT:49)

Iteration 5.4.0.118 label.



My master repo is on sparc-solaris2.10, apache2.2.10, Subversion 1.6.3 and is 
physically located in NY.  I use standard post-commit hook script to launch the 
svnsync sync command after each commit.  My proxy repo is x86-solaris2.10 and 
is physically located in Tel Aviv.

The user shown in the corrupted revs is our admin account.  The other actions 
just 

HELP! Can't commit anymore: svn: PROPFIND ... Service Unavailable

[Peter Koellner]

Hi!

I am working on a slightly outdated OpenSuSE system that has
subversion 1.4.4 installed.
Since an hour or so, I can't do any commits anymore. Everything else
seems to work, but no commits.

I even checked out a fresh working copy with

svn co http://localhost/svn/meinefc/branches/RELEASE-BETA test

which worked, but all I get on commit is:

Hinzufügen meinefc/test.txt
svn: Übertragen fehlgeschlagen (Details folgen):
svn: PROPFIND Anfrage fehlgeschlagen auf
»/svn/meinefc/branches/RELEASE-BETA/sites/all/modules/meinefc/test.txt«
svn: PROPFIND von
»/svn/meinefc/branches/RELEASE-BETA/sites/all/modules/meinefc/test.txt«:
503 Service unavailable (http://localhost)
svn: Ihre Logmeldung wurde in einer Temporärdatei abgelegt:
svn:'/home/koellpe/test/sites/all/modules/svn-commit.tmp'


Everything else works. checkout, update, access but no commit!
I have restarted apache, and I don't see any error
messages. Everything worked until an hour ago, there were no
configuration changes.

There are no log messages, no further error messages, no verbose
messages, no debug messages.

Does anybody have any idea how to solve this? This is extremely
urgent, since I am in the middle of a very complicated product
update and had to put the web site offline until finishing this update
operation


--
peter koellner 

Re: Troubles with VirtualHost configuration: never asked for password

[Andrey Repin]

Greetings, Will Scheidegger!

> I'm having a hard time configuring my virtual host to restrict access to my
> subversion repository. This is what my conf looks like:

> #Virtual Host Configuration

> 
> ServerName svn.domain.com

> 
> Order Allow,Deny
> Allow from all

> DAV svn
> SVNPath /usr/local/svn/myproject
> AuthType Basic
> AuthName "Subversion Repository"
> AuthUserFile /etc/subversion/passwd
> Require valid-user
> 
> 


> Without the "Order Allow,Deny" + "Allow from all" directive the default
> virtual host configuration takes over and access is denied ("Server sent
> unexpected return value (403 Forbidden) in response to OPTIONS request...").
> But with the directives I'm never asked for a password. According to all the
> manuals I consulted on the web, this setup _should_ challenge the user for a
> password (stored in /etc/subversion/passwd). Do I need to configure
> something else, i.e. modify stuff in /usr/local/svn/myproject/conf?

Try running svn command with --no-auth-cache switch.
Not really see what's wrong with your setup...
For a convenience, here's my own configuration of authorization block (It
using SSPI module, however, you have to replace relevant directives by ones
suitable for your auth scheme):


ServerName svn.mydomain.local
ServerAlias svn.example.org

DocumentRoot "C:/home/svn"
AddDefaultCharset utf-8

ErrorLog "C:/home/svn/.log/error_log"
CustomLog "C:/home/svn/.log/access_log" common env=!SVN-ACTION
CustomLog "C:/home/svn/.log/svn_access_log" svn env=SVN-ACTION


# some private stuff here to make all things to work straight



Order allow,deny
# Limit access to single local IP
# unless we have working authorization scheme
Allow from 192.168.1.10


DAV svn
SVNParentPath "C:/home/svn"



Allow from all

AuthName "Subversion repository"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIOfferBasic On
SSPIOmitDomain On
SSPIUsernameCase lower
SSPIBasicPreferred Off

# only developers may access the repository
Require group "EXAMPLE\CVS"

# And they should obey to SVN user permissions file

AuthzSVNAccessFile "C:/home/svn/.registry"






--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 13.01.2010, <4:28>

Sorry for my terrible english...

RE: Merging binary files with ancestry

[Srilakshmanan, Lakshman]

Hi All,

This was an issue I raised 6mths ago and lost track.
Any feedback is greatly appreciated.

When merging binary files from branch to trunk, it is reported as **
Updated **. But there is ** NO ** change  in the Working Copy and
nothing to commit.

Is this a side-effect of resolving bug 2403.
http://subversion.tigris.org/issues/show_bug.cgi?id=2403

Thanks
Lakshman
-Original Message-
From: Srilakshmanan, Lakshman 
Sent: Thursday, 2 July 2009 11:54 AM
To: us...@subversion.tigris.org
Subject: RE: Merging binary files with ancestry

Hi All,

Further investigation revealed, in my opinion, the strange behaviour is
an outcome of resolving bug 2403 and/or 1319

The issues below, explains the behaviour (I experienced) during svn
merge of binary files with ancestry. ie the merge screen displays that
the binary file was ** Updated **. But there is ** NO ** change  in the
Working Copy and nothing to commit.

Could the more experienced users please advise me if this should be
raised as an issue.

http://subversion.tigris.org/issues/show_bug.cgi?id=2403

Below is an extract from the log for bug 2403.

  /* Special case:  if a binary file isn't locally modified, and is
 exactly identical to the 'left' side of the merge, then don't
 allow svn_wc_merge to produce a conflict.  Instead, just
 overwrite the working file with the 'right' side of the merge.
*/


http://subversion.tigris.org/issues/show_bug.cgi?id=1319


Thanks
Lakshman 

-Original Message-
From: Srilakshmanan, Lakshman
[mailto:lakshman.srilakshma...@police.vic.gov.au]
Sent: Thursday, 11 June 2009 2:37 PM
To: us...@subversion.tigris.org
Subject: Merging binary files with ancestry

Hi All,

I submitted this post to the user forum on Friday 5/6/2009 but can't
find it :(

I have searched svn mailing list and goggled for an answer all day. I
will be grateful to anyone who can answer my question and put me out of
my misery as a logical explanation is eluding me and driving me insane.

Any help in this is greatly appreciated.


I came across an interesting issue while performing a merge on binary
files with and without using ancestry.
I am currently using svn 1.4.6

Step 0. Create a branch (MergeTest2) from trunk (note : trunk should
contain a binary file) (r29) Step 1. modify a binary file in trunk. (ie
copy another binary file on top of an existing file) and commit it (r30)
Step 2. merge trunk into branch and commit  http://host/svn/sgs/trunk
r29:30  (r31)
Step 3. merge branch into trunk. http://host/svn/sgs/trunk
http://host/svn/sgs/branch/MergeTest2


Step 3 will display that the binary file was ** Updated **. But there is
** NO ** change  in the Working Copy. 

If you perform Step 3 with --ignore-ancestry then there is ** nothing **
on the display and no change in the Working Copy either. (what I would
expect).

My question is why would the --ignore-ancestry flag cause a difference
in merge display when there is ** NO change ** in the ancestry to start
with.


svn log the binary file in branch "MergeTest2" shows the following Note
: r25 & r27 are from trunk ** before ** creating the MergeTest2 branch.
This proves that svn is maintaining the ancestry relationship.


r31 | UsrID | 2009-06-05 17:12:09 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
   M /branch/MergeTest2/BIN.exe

received update from trunk at rev30

r29 | UsrID | 2009-06-05 17:07:41 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
   A /branch/MergeTest2 (from /trunk:28)

Copied remotely

r27 | UsrID | 2009-06-05 16:54:45 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
   M /trunk/BIN.exe

Modified file

r25 | UsrID | 2009-06-05 16:50:01 +1000 (Fri, 05 Jun 2009) | 1 line
Changed paths:
   A /trunk/BIN.exe

Test for merging binary files



Thanks
Lakshman



EMAIL DISCLAIMER

This email and any attachments are confidential. They may also be
subject to copyright.

If you are not an intended recipient of this email please immediately
contact us by replying to this email and then delete this email. 

You must not read, use, copy, retain, forward or disclose this email or
any attachment.

We do not accept any liability arising from or in connection with
unauthorised use or disclosure of the information contained in this
email or any attachment.

We make reasonable efforts to protect against computer viruses but we do
not accept liability for any liability, loss or damage caused by any
computer virus contained in this email.