Commit failed because I couldn't connect.

[benang]

Hi, I'm a new member in the maillist. Nice to meet all of you. Now, for my
question. This is my current system:

The SVN-client: windows xp pro + Tortoise SVN 1.6.16, Build 21511
The SVN-server: windows xp pro + WANDisco uberSVN 11.10 beta + SVN 1.6.17
+ XAMPP 1.7.4

The SVN worked for a few weeks, but today it doesn't. This is the message
from tortoise:

Commit failed (details follow):
OPTIONS of 'http://192.168.1.116:9880/NSsFS-2D-RBU/trunk': could not
connect to
server (http://192.168.1.116:9880)


I've tried to browse the link from a browser and it also didn't work. So I
guess the problem is at the apache server or so. My assumption is the
apache from uberSVN and XAMPP clashed. How do I solve this? Thanks a lot
in advance.


Fare thee well,
Bawenang R. P. P.


"127.0.0.1 sweet 127.0.0.1. There's no place like 127.0.0.1."


--

http://www.its.ac.id 

RE: Commit failed because I couldn't connect.

[Mertens, Bram]

>


Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek
VAT BE 0406.024.281, RPR Mechelen, ING  310-0092504-52, IBAN : BE64 3100 0925 
0452, SWIFT : BBRUBEBB

-Original Message-
> From: ben...@cs.its.ac.id [mailto:ben...@cs.its.ac.id]
> Sent: woensdag 14 december 2011 9:35
> To: users@subversion.apache.org
> Subject: Commit failed because I couldn't connect.
>
> Hi, I'm a new member in the maillist. Nice to meet all of you. Now, for my
> question. This is my current system:
>
> The SVN-client: windows xp pro + Tortoise SVN 1.6.16, Build 21511
> The SVN-server: windows xp pro + WANDisco uberSVN 11.10 beta + SVN
> 1.6.17
> + XAMPP 1.7.4
>
> The SVN worked for a few weeks, but today it doesn't. This is the message
> from tortoise:
>
> Commit failed (details follow):
> OPTIONS of 'http://192.168.1.116:9880/NSsFS-2D-RBU/trunk': could not
> connect to
> server (http://192.168.1.116:9880)
>
>
> I've tried to browse the link from a browser and it also didn't work. So I
> guess the problem is at the apache server or so. My assumption is the
> apache from uberSVN and XAMPP clashed. How do I solve this? Thanks a lot
> in advance.

Welcome to the list.

Don't take this wrong, it is meant to help you, but please read 
http://catb.org/~esr/faqs/smart-questions.html .

Basically you are asking someone else to do your job by saying "it doesn't 
work" and expecting someone else to take your hand and walk you through it.

A lot of people on this list are very helpful but you need to show you at least 
tried to solve it and ask specific questions.

For example: how did you come to the assumption that uberSVN and XAMPP clash?  
If it worked for a few weeks, the config seems to at least work.  What changed?

What happened?  What do the log files say?
Have you tried to telnet to port 9880 on 192.168.1.116?
Can you connect to the SVN repo on that server locally (that "sweet 127.0.0.1" 
in your signature)?

In basic troubleshooting you start with as few components as possible: just 
SVN, no remote connection, no tortoise, no web server.
Then you test by adding one component at a time.
And check the log files.

Regards

Bram

Svn version problem

[李泰]

Hi, All,
  I got a problem in svn. My server' harddisk was broken three days
ago, and  the latest backup is up to four days ago. In another word, my
svn's latest version info is from four days ago. But in my client computer,
the svn version info is from three days ago.  I meant my client computer
keeps the latest version info(including  the history info), but my server
doesn't have these lastest info.
 For example, the server's current version  number is 8, but my
client's is 10. The client's version is upper  then server's.  The server
should be synchronized to the client's. Any solution?

Thanks
Tiger

Re: Svn version problem

[Stefan Sperling]

On Wed, Dec 14, 2011 at 04:51:52PM +0800, 李泰 wrote:
> Hi, All,
>   I got a problem in svn. My server' harddisk was broken three days
> ago, and  the latest backup is up to four days ago. In another word, my
> svn's latest version info is from four days ago. But in my client computer,
> the svn version info is from three days ago.  I meant my client computer
> keeps the latest version info(including  the history info), but my server
> doesn't have these lastest info.
>  For example, the server's current version  number is 8, but my
> client's is 10. The client's version is upper  then server's.  The server
> should be synchronized to the client's. Any solution?

Your repository has travelled back in time. This cannot be undone
automatically unless you have backups of revisions 9 and 10.

What you need to do in this situation is get a separate checkout from
the restored repository (which gives you revision 8) and manually transfer
over any changed files from your other working copy which is at revision 10.
Then commit those changes to the restored repository. Dispose of your other
working copy once you are sure that all changes have been transferred.

There are many "directory tree merge" tools which can help you with
this task. One such tool is kdiff3, see
http://kdiff3.sourceforge.net/doc/dirmergeoptions.html

RE: Commit failed because I couldn't connect.

[benang]

Yeah, sorry. I know that link. And used to show them to other newbies. I
confess I haven't put the right word or enough information about this one.
I'm actually a SVN user, a mere programmer, who have just been appointed
to set up a SVN server (while also developing the app). Not exactly my
forte and comfort zone and although I've been taught about Computer
Network, I've forgotten about most of them. So, I do apologize.

Now to elaborate more:

1. I can still connect locally (that is the 127.0.0.1). And the webserver
worked just fine locally (weird).
2. I don't know a little about the XAMPP because it's already installed
there for another programmer's MySQL service, which he himself manage,
before I installed uberSVN. I don't know how he configured his XAMPP's
Apache. While for the SVN itself, I didn't do anything to the
configuration at all.
3. About the telnet. Well, it hasn't crossed my mind at all. Thanks for
pointing it up. Will try that.
4. At first, I STFG'ed about my current issue but can only find the ones
using Linux so I only have the faintest idea about where to look for the
windows version. However after reading the manual of uberSVN I finally
know where to look. There are a few of them. error_log, localhost.log,
catalina.log.

The error_log one doesn't show any error except for this warning:

[Wed Dec 14 10:40:56 2011] [notice] Parent: Created child process 3332
httpd.exe: Could not reliably determine the server's fully qualified
domain name, using 192.168.1.116 for ServerName
[Wed Dec 14 10:40:56 2011] [warn] Init: Session Cache is not configured
[hint: SSLSessionCache]
httpd.exe: Could not reliably determine the server's fully qualified
domain name, using 192.168.1.116 for ServerName

The localhost.log doesn't have anything except the Initializing /
Destroying / Closing the Spring service.

While the catalina.log only have some errors about the web application so
I don't know whether it was actually the cause or not.

Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc
SEVERE: The web application [/ubersvn] registered the JDBC driver
[org.hsqldb.jdbcDriver] but failed to unregister it when the web
application was stopped. To prevent a memory leak, the JDBC Driver has
been forcibly unregistered.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [HSQLDB Timer @111089b] but has failed to stop it. This is very
likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [net.sf.ehcache.CacheManager@120d6b7] but has failed to stop it.
This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.LDAPConnectionEntity.data] but has
failed to stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.ConfigurationEntity.data] but has
failed to stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.ComponentInstallHistoryEntity.data]
but has failed to stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.FeedEntity.data] but has failed to
stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.PermissionEntity.data] but has failed
to stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.RepositoryEntity.data] but has failed
to stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/ubersvn] appears to have started a thread
named [com.wandisco.ubersvn.entities.JenkinsEntity.data] but has failed to
stop it. This is very likely to create a memory leak.
Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
cle

RE: Commit failed because I couldn't connect.

[benang]

Nevermind. False alarm. Somehow, somebody (or something) was messing with
the firewall. I haven't really looked at the firewall settings at all. And
maybe the firewall was off the last time. Maybe it was because of a
windows update or something that activated the firewall automatically.
Anyway, thanks in advance. Sorry for the inconvenience. I've added the
port to the exception and now it's working again.

ben...@cs.its.ac.id wrote:
> Yeah, sorry. I know that link. And used to show them to other newbies. I
> confess I haven't put the right word or enough information about this one.
> I'm actually a SVN user, a mere programmer, who have just been appointed
> to set up a SVN server (while also developing the app). Not exactly my
> forte and comfort zone and although I've been taught about Computer
> Network, I've forgotten about most of them. So, I do apologize.
>
> Now to elaborate more:
>
> 1. I can still connect locally (that is the 127.0.0.1). And the webserver
> worked just fine locally (weird).
> 2. I don't know a little about the XAMPP because it's already installed
> there for another programmer's MySQL service, which he himself manage,
> before I installed uberSVN. I don't know how he configured his XAMPP's
> Apache. While for the SVN itself, I didn't do anything to the
> configuration at all.
> 3. About the telnet. Well, it hasn't crossed my mind at all. Thanks for
> pointing it up. Will try that.
> 4. At first, I STFG'ed about my current issue but can only find the ones
> using Linux so I only have the faintest idea about where to look for the
> windows version. However after reading the manual of uberSVN I finally
> know where to look. There are a few of them. error_log, localhost.log,
> catalina.log.
>
> The error_log one doesn't show any error except for this warning:
>
> [Wed Dec 14 10:40:56 2011] [notice] Parent: Created child process 3332
> httpd.exe: Could not reliably determine the server's fully qualified
> domain name, using 192.168.1.116 for ServerName
> [Wed Dec 14 10:40:56 2011] [warn] Init: Session Cache is not configured
> [hint: SSLSessionCache]
> httpd.exe: Could not reliably determine the server's fully qualified
> domain name, using 192.168.1.116 for ServerName
>
> The localhost.log doesn't have anything except the Initializing /
> Destroying / Closing the Spring service.
>
> While the catalina.log only have some errors about the web application so
> I don't know whether it was actually the cause or not.
>
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesJdbc
> SEVERE: The web application [/ubersvn] registered the JDBC driver
> [org.hsqldb.jdbcDriver] but failed to unregister it when the web
> application was stopped. To prevent a memory leak, the JDBC Driver has
> been forcibly unregistered.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [HSQLDB Timer @111089b] but has failed to stop it. This is very
> likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [net.sf.ehcache.CacheManager@120d6b7] but has failed to stop it.
> This is very likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [com.wandisco.ubersvn.entities.LDAPConnectionEntity.data] but has
> failed to stop it. This is very likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [com.wandisco.ubersvn.entities.ConfigurationEntity.data] but has
> failed to stop it. This is very likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [com.wandisco.ubersvn.entities.ComponentInstallHistoryEntity.data]
> but has failed to stop it. This is very likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [com.wandisco.ubersvn.entities.FeedEntity.data] but has failed to
> stop it. This is very likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader
> clearReferencesThreads
> SEVERE: The web application [/ubersvn] appears to have started a thread
> named [com.wandisco.ubersvn.entities.PermissionEntity.data] but has failed
> to stop it. This is very likely to create a memory leak.
> Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader

Re: What is the easiest way to copy an existing Subversion Repository to another server?

[Ulrich Eckhardt]

Am 14.12.2011 05:23, schrieb Craig Burlock:

I need to create a new clone of an existing Subversion Repository to run on
a new server. What is the easiest way of doing this?


Apart from the mentioned dump/load and svnsync, a plain filesystem copy 
works, too, provided you either use BDB on two similar systems or FSFS 
for the repository.


However, let me ask you the question if you want to move the repository 
or create a clone? The reason is that creating a clone that is not 
supposed to be a read-only mirror or backup is an error-prone operation, 
because the clone will have the same UUID but possibly a different 
history than the original.


If you just want to migrate the repo to a new server, any of the above 
methods work. You should first prevent write access to the old location 
before opening the new location though, in order to avoid these 
differing histories. If copying takes too long for your users, use 
svnsync in the background. You will further need to relocate working 
copies to the new repo URL.


Good luck!

Uli
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
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. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Invalid character "/" in revision list

[Thomas Gier]

Hello,

this is my first post to the list so first of all I'd like to say hello 
to everybody :).


I'm stuck with a problem for which even google doesn't seem to find a 
solution, so I decided to post to this list. We're using SVN  1.5.1 
(r32289) and access our repository with linux, mac (SmartSVN, IntelliJ 
plugin) and windows clients (Eclipse plugin, TortoiseSVN)


Problem:
Loading a dump into a repository fails with "Invalid character "/" in 
revision list".


After many hours of trying and searching for fixes I decided to take a 
closer look to the binary files under /db/revs. Since I know 
the affected revision (12943), I inspected the file home>/db/revs/12/12943. This file contains a line similar to this:


/path/to/some/file:1234,1235,1237/path/to/some/other/file

Other lines never have a path except at the beginning but never inside 
the revision list and they always end with a line feed  (0A in binary). 
This particular line however doesn't. Editing the file with an hex 
editor and putting an 0A at the correct position (while preserving as 
much of the revision numbers as possible) seems to do the trick.


I know that by fiddling with these entries the mergeinfo will get 
useless for this particular file/revision. I really don't like the idea 
of messing around like this but I need to make sure that the dumps 
remain usable. My backup strategy is dependent on usable dumps which are 
created every night and moved off-site. If I can't recover from a 
breakdown using the latest dump, I'm in serious trouble.


So here are my questions:
- Does anybody else have had this or a similar problem, too? What did 
he/she do to fix it?
- How can this happen? Does anybody have hints/tips for further 
investigation of the cause of this mess?
- Is there a way to correct this issue without using a binary editor on 
the db files?


Thanks a lot for reading. Any comment is much appreciated.

Cheers
Thomas Gier
Aachen, Germany

Re: Invalid character "/" in revision list

[Daniel Shahaf]

Thomas Gier wrote on Wed, Dec 14, 2011 at 17:10:26 +0100:
> Hello,
> 
> this is my first post to the list so first of all I'd like to say
> hello to everybody :).
> 
> I'm stuck with a problem for which even google doesn't seem to find
> a solution, so I decided to post to this list. We're using SVN
> 1.5.1 (r32289) and access our repository with linux, mac (SmartSVN,
> IntelliJ plugin) and windows clients (Eclipse plugin, TortoiseSVN)
> 

What version of svn runs on the client side?  If it's 1.5, upgrade;
there have been robustness fixes in the last 3.5 years.

> Problem:
> Loading a dump into a repository fails with "Invalid character "/"
> in revision list".
> 
> After many hours of trying and searching for fixes I decided to take
> a closer look to the binary files under /db/revs. Since I
> know the affected revision (12943), I inspected the file  home>/db/revs/12/12943. This file contains a line similar to this:
> 
> /path/to/some/file:1234,1235,1237/path/to/some/other/file
> 

For the record, you could have run 'propget --strict' or 'diff' against
the revision in question.

> Other lines never have a path except at the beginning but never
> inside the revision list and they always end with a line feed  (0A
> in binary). This particular line however doesn't. Editing the file
> with an hex editor and putting an 0A at the correct position (while
> preserving as much of the revision numbers as possible) seems to do
> the trick.

DO NOT EDIT REVISION FILES; you just corrupted it.

The correct thing to do is a dump/load and change the property value
during that process.  Doing it by hand to a dumpfile is easier to get
right (but you will still have lengths and checksums to adjust), or you
could use some third-party dumpfile manipulation tool (some tools are
standard recommendations on this list; I don't recall which offhand).

> 
> I know that by fiddling with these entries the mergeinfo will get
> useless for this particular file/revision. I really don't like the

No, the mergeinfo will be fine; it's the rest of the changes in that
revision that will be corrupt.  And if a file text change becomes
invalid, later revisions of that file may or may not be affected.

> idea of messing around like this but I need to make sure that the
> dumps remain usable. My backup strategy is dependent on usable dumps
> which are created every night and moved off-site. If I can't recover
> from a breakdown using the latest dump, I'm in serious trouble.
> 
> So here are my questions:
> - Does anybody else have had this or a similar problem, too? What
> did he/she do to fix it?
> - How can this happen? Does anybody have hints/tips for further
> investigation of the cause of this mess?
> - Is there a way to correct this issue without using a binary editor
> on the db files?
> 
> Thanks a lot for reading. Any comment is much appreciated.
> 
> Cheers
> Thomas Gier
> Aachen, Germany

Looks like someone committed a bad svn:mergeinfo property.  Newer
servers check for this and newer clients handle that gracefully (so you
may not _have_ to fix your history).  Just don't get in the habit of
editing revision files if you care about your data.

Re: Invalid character "/" in revision list

[Daniel Shahaf]

Daniel Shahaf wrote on Wed, Dec 14, 2011 at 18:33:06 +0200:
> Thomas Gier wrote on Wed, Dec 14, 2011 at 17:10:26 +0100:
> > I know that by fiddling with these entries the mergeinfo will get
> > useless for this particular file/revision. I really don't like the
> 
> No, the mergeinfo will be fine; it's the rest of the changes in that
> revision that will be corrupt.  And if a file text change becomes
> invalid, later revisions of that file may or may not be affected.

Changing the byte-length of any directory listing, file contents, or
property hash in a revision file will potentially render unreachable
EVERY other change in that revision file.

Edits that don't change the byte-length may have less drastic effects.

Inquiry

[Troy Gaines]

I have been a satisfied long-time user of SVN.

I found the following article recently.  I have used both and this appears
(Dimensions CM is slow from our experience) to be very skewed based on user
experience.  Anyone else have a similar issue?

http://www.serena.com/products/dimensions-cm/index.html

Please let me know if this is not the correct user group.

Thanks.

Re: Inquiry

[Andy Levy]

On Wed, Dec 14, 2011 at 12:02, Troy Gaines  wrote:
> I have been a satisfied long-time user of SVN.
>
> I found the following article recently.  I have used both and this appears
> (Dimensions CM is slow from our experience) to be very skewed based on user
> experience.  Anyone else have a similar issue?
>
> http://www.serena.com/products/dimensions-cm/index.html
>
> Please let me know if this is not the correct user group.

That's not an "article", it's a sales brochure. I am not at all
surprised that marketing materials by a CM product vendor cast their
own products in a more favorable light than their competitors. You can
find similar language in marketing materials published by vendors
selling SVN solutions too.

Statements like this:

"In common global development conditions, tests have shown that it is
60 times faster than IBM Rational ClearCase and 3 times faster than
Subversion."

are really hard to use in a meaningful way as they don't say anything
about *what* was tested or *how* the testing was conducted.

Your own testing with your typical workloads, or even
testing/comparisons done by an independent 3rd party with full details
of what and how they tested, would be much more informative IMHO.

Re: GnomeKeyring: not entering passwords

[rupert.thurner]

On Nov 3, 7:54 pm, Mark Phippard  wrote:
> On Thu, Nov 3, 2011 at 2:38 PM, rupert.thurner 
> wrote:
>
> > while looking for a possibility to help a user of subversion so he
> > does not need to type the server password all the time, i got hinted
> > to GnomeKeyring and seahorse. subversion offers to be compile with --
> > with-gnome-keyring option.
>
> managing your keyring and this is tied to your login session.  What we did
> for our CollabNet binaries was write a small command line tool that uses
> the GNOME keyring API but gives you a simple command line interface.  I do
> not know why GNOME does not provide one.  I would be happy to share the
> source code if you want it.
>
> With this tool you can use the command line tool to create a keyring as
> well as unlock it.  The latter is what you would want to do when you login
> (after starting the keyring-daemon).

mark, great to hear you would be able to share this tool.

btw, the keyring-libraries are now linked to the http://opencsw.org
subversion solaris build and therefor in the upcoming opencsw
subversion-1.7.2 release:
http://sourceforge.net/apps/trac/gar/changeset/16366/csw/mgar/pkg/subversion/trunk

rupert.

Re: Inquiry

[Troy Gaines]

Agreed.

I understand the marketing aspect very well.  It's sad companies are buying
into this, even the one I'm working for.  :)



On Wed, Dec 14, 2011 at 11:46 AM, Andy Levy  wrote:

> On Wed, Dec 14, 2011 at 12:02, Troy Gaines  wrote:
> > I have been a satisfied long-time user of SVN.
> >
> > I found the following article recently.  I have used both and this
> appears
> > (Dimensions CM is slow from our experience) to be very skewed based on
> user
> > experience.  Anyone else have a similar issue?
> >
> > http://www.serena.com/products/dimensions-cm/index.html
> >
> > Please let me know if this is not the correct user group.
>
> That's not an "article", it's a sales brochure. I am not at all
> surprised that marketing materials by a CM product vendor cast their
> own products in a more favorable light than their competitors. You can
> find similar language in marketing materials published by vendors
> selling SVN solutions too.
>
> Statements like this:
>
> "In common global development conditions, tests have shown that it is
> 60 times faster than IBM Rational ClearCase and 3 times faster than
> Subversion."
>
> are really hard to use in a meaningful way as they don't say anything
> about *what* was tested or *how* the testing was conducted.
>
> Your own testing with your typical workloads, or even
> testing/comparisons done by an independent 3rd party with full details
> of what and how they tested, would be much more informative IMHO.
>

Circular cleanup/checkout problem using Subversion 1.7

[Strickland, Stuart]

In attempting to pull down a copy of the trunk to my PC, I inadvertently 
accessed a file in the Subversion repository that was created on a non-Windows 
machine. The file has a name containing a less-than sign, which is illegal in 
DOS/Windows. This caused a circular condition in which Svn was unable to 
complete processing of the checkout, and further cannot execute its cleanup 
utility. Thus, cleanup cannot run because of a checkout problem; checkout 
cannot run because of a cleanup problem. Ultimately, the problem really is that 
the file cannot be renamed to its given, but illegal, name.

Subversion client is TortoiseSVN (1.7.1, Build 22161 – 64 Bit). Windows 7 PC.

Attempting to run a Svn Update causes this to appear:
Update Failed!
Error  Previous operation has not finished; run ‘cleanup’ if it was 
interrupted
Error  Please execute the ‘Cleanup’ command.
The operation failed.

An attempt to cleanup results in this dialog box message:
Cleanup failed to process the following paths:
C:\Users\myusername\svn\trunk\research
Working copy ‘C:\Users\myusername\svn\trunk\research’ locked.
‘C:\Users\myusername\svn\trunk’ is already locked.

Two suggested workarounds -- deleting the working directory, and attempting the 
cleanup at the trunk level -- have the same results.

I do see that Svn retrieved the file’s contents to a temp folder 
(C:\users\myusername\svn\.svn\tmp), but cannot rename that to the 
non-conforming filename.
Do I need to delete my entire working directory? I am essentially dead in the 
water here, as I cannot do any Subversion work in any directory.
On site, work is being done to rename or delete the offending files, but that 
will not help me in my local build area on my PC.
Suggestions welcome.



Stuart Strickland
Software Engineer
sstrickl...@carnegielearning.com
Toll Free: (888) 851-7094 x195
FAX: (412) 690-2444
[http://resources.carnegielearning.com/images/CarnegieLogoGT.png]
Revolutionary Math Curricula. Revolutionary Results.

Carnegie Learning, Inc. | 437 Grant St. 20th Floor | Pittsburgh, PA 15219
www.carnegielearning.com

Possible regression with empty checkouts of repos in 1.7.

[Thomas Dziedzic]

Hi,

I used to be able to do:
svn checkout --depth=empty svn://svn.archlinux.org/packages
cd packages
svn up pacman
rm -r pacman
svn up

and it would leave me with an empty, working copy on my computer in
subversion 1.6.17

When I upgraded to subversion 1.7.2, after doing the same set of
commands as described above,
the last svn up brings back the pacman folder into the working copy.

So far, I haven't been able to find any documented proof that this is
an intentional change.

Finally, when I run:

svn up --set-depth exclude pacman

This works as expected.

So my question is, am I experiencing a regression? Or is this new,
intended behavior with subversion 1.7?

Thanks for your time!

Re: Svn version problem

[Tiger Li]

Ok,Thank you very much!
  
  
 
  
   
  
  -- Original --
  From:  "Stefan Sperling";
 Date:  Wed, Dec 14, 2011 05:29 PM
 To:  "李泰"; 
 Cc:  "users"; 
 Subject:  Re: Svn version problem

  
On Wed, Dec 14, 2011 at 04:51:52PM +0800, 李泰 wrote:
> Hi, All,
>   I got a problem in svn. My server' harddisk was broken three days
> ago, and  the latest backup is up to four days ago. In another word, my
> svn's latest version info is from four days ago. But in my client computer,
> the svn version info is from three days ago.  I meant my client computer
> keeps the latest version info(including  the history info), but my server
> doesn't have these lastest info.
>  For example, the server's current version  number is 8, but my
> client's is 10. The client's version is upper  then server's.  The server
> should be synchronized to the client's. Any solution?

Your repository has travelled back in time. This cannot be undone
automatically unless you have backups of revisions 9 and 10.

What you need to do in this situation is get a separate checkout from
the restored repository (which gives you revision 8) and manually transfer
over any changed files from your other working copy which is at revision 10.
Then commit those changes to the restored repository. Dispose of your other
working copy once you are sure that all changes have been transferred.

There are many "directory tree merge" tools which can help you with
this task. One such tool is kdiff3, see
http://kdiff3.sourceforge.net/doc/dirmergeoptions.html

line 1652: assertion failed (parent_node || entry->schedule == svn_wc_schedule_normal)

[David Fahlander]

Got problems after an upgrade.

1) Upgraded one sub path to 1.7
2) Upgraded sub path by sub path to 1.7
3) Failed to upgrade one of the sub paths, claiming that my localhost SVN
server disconnected the socket. This happened over and over so I decided to
make a Cleanup.
4) Cleanup failed. See below.

Note: I am using SVN server on my local machine. I also have a backup
service supervising and constantly backing up my Repositories directory as
well as my working directories... if it could be that the backup tool was
trying to read at the same time the SVN operation took place. Dont know.
Other special thing is that the root directory of my repository is my
Visual Studio 2008\Projects folder and it contains lots of subdirs but only
a few of them are included in the SVN repo.

---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
(users@subversion.apache.org)
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
 line 1652: assertion failed (parent_node || entry->schedule ==
 svn_wc_schedule_normal)
---
OK
---

Re: Invalid character "/" in revision list

[Thomas Gier]

Am 14.12.2011 17:33, schrieb Daniel Shahaf:

Thomas Gier wrote on Wed, Dec 14, 2011 at 17:10:26 +0100:

Hello,

this is my first post to the list so first of all I'd like to say
hello to everybody :).

I'm stuck with a problem for which even google doesn't seem to find
a solution, so I decided to post to this list. We're using SVN
1.5.1 (r32289) and access our repository with linux, mac (SmartSVN,
IntelliJ plugin) and windows clients (Eclipse plugin, TortoiseSVN)


What version of svn runs on the client side?  If it's 1.5, upgrade;
there have been robustness fixes in the last 3.5 years.


Problem:
Loading a dump into a repository fails with "Invalid character "/"
in revision list".

After many hours of trying and searching for fixes I decided to take
a closer look to the binary files under/db/revs. Since I
know the affected revision (12943), I inspected the file/db/revs/12/12943. This file contains a line similar to this:

/path/to/some/file:1234,1235,1237/path/to/some/other/file


For the record, you could have run 'propget --strict' or 'diff' against
the revision in question.


Other lines never have a path except at the beginning but never
inside the revision list and they always end with a line feed  (0A
in binary). This particular line however doesn't. Editing the file
with an hex editor and putting an 0A at the correct position (while
preserving as much of the revision numbers as possible) seems to do
the trick.

DO NOT EDIT REVISION FILES; you just corrupted it.

The correct thing to do is a dump/load and change the property value
during that process.  Doing it by hand to a dumpfile is easier to get
right (but you will still have lengths and checksums to adjust), or you
could use some third-party dumpfile manipulation tool (some tools are
standard recommendations on this list; I don't recall which offhand).


I know that by fiddling with these entries the mergeinfo will get
useless for this particular file/revision. I really don't like the

No, the mergeinfo will be fine; it's the rest of the changes in that
revision that will be corrupt.  And if a file text change becomes
invalid, later revisions of that file may or may not be affected.


idea of messing around like this but I need to make sure that the
dumps remain usable. My backup strategy is dependent on usable dumps
which are created every night and moved off-site. If I can't recover
from a breakdown using the latest dump, I'm in serious trouble.

So here are my questions:
- Does anybody else have had this or a similar problem, too? What
did he/she do to fix it?
- How can this happen? Does anybody have hints/tips for further
investigation of the cause of this mess?
- Is there a way to correct this issue without using a binary editor
on the db files?

Thanks a lot for reading. Any comment is much appreciated.

Cheers
Thomas Gier
Aachen, Germany

Looks like someone committed a bad svn:mergeinfo property.  Newer
servers check for this and newer clients handle that gracefully (so you
may not _have_ to fix your history).  Just don't get in the habit of
editing revision files if you care about your data.


Daniel,

thanks for your comments! My gut feeling told me, that it's a bad idea 
to edit the revision files. That's why I asked on the list. For the 
record: The live server is still untouched. I edited the revision files 
in a copy of our svn server (it runs as a virtual machin.



 What version of svn runs on the client side?  If it's 1.5, upgrade;
 there have been robustness fixes in the last 3.5 years.


We have several different clients due to our heterogeneous 
infrastructure. All of them should be set up to use 1.5. An upgrade is 
definitely a good idea, discussions about doing this have just started.


I found 3 corrupted revisions so far starting at rev. 12943, HEAD was at 
14667 yesterday evening. I haven't checked in depth yet, whether all of 
the corrupted revisions are caused by the same client; my main focus is 
to get the backups up and running again. Punishing the culprit will be 
my next focus ;).


I going to search the list archives for the tools you mentioned to 
manipulate dump files. Thanks again for helping me. If there are other 
tips worth sharing these would be much appreciated.



Cheers
Thomas Gier
Aachen, Germany