Re: Problem running on simple svn commands on CentOs

[L'oiseau2nuit]

Thanks for helping :-)


> svn --version
>

Currently indicates 1.7.5

[root@host]# svn --version
svn, version 1.7.5 (r1336830)
   compiled Aug  9 2012, 18:21:35

Copyright (C) 2012 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* 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


This would mean all my rollback attempts were useless anyway... hmmm...




> svn help upgrade
>

upgrade: Upgrade the metadata storage format for a working copy.
usage: upgrade [WCPATH...]

  Local modifications are preserved.

Valid options:
  -q [--quiet] : print nothing, or only summary information

Global options:
  --username ARG   : specify a username ARG
  --password ARG   : specify a password ARG
  --no-auth-cache  : do not cache authentication tokens
  --non-interactive: do no interactive prompting
  --trust-server-cert  : accept SSL server certificates from unknown
 certificate authorities without prompting (but
only
 with '--non-interactive')
  --config-dir ARG : read user configuration files from directory
ARG
  --config-option ARG  : set user configuration option in the format:
 FILE:SECTION:OPTION=[VALUE]
 For example:
 servers:global:http-library=serf


So what I do not understand is why when attempting to upgrade my working
copies, it says "upgrade command not found" ... oO


It seems to work a bit better today ! I managed to 'svn up' all my working
copies but still two of them are missing (not checked out by my script) and
still, when trying to check them out :

svn checkout svn://
zone.spip.org/spip-zone/_plugins_/champs_extras/core/trunk/champs_extras_core

i got the following message :

svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/champs_extras_core' is too old (format 10,
created by Subversion 1.6)

For the two of them. Weird isn't it ?

When I try 'svn upgrade' it returns :

[root@host _trunk]# svn upgrade
svn: E155019: Can't upgrade
'/var/www/vhosts/.*.**/httpdocs/spip/plugins/_api-dist/_trunk'
as it is not a pre-1.7 working copy directory
svn: E02: Can't open file
'/var/www/vhosts/.*.**/httpdocs/spip/plugins/_api-dist/_trunk/.svn/entries':
No such file or directory

There's a thin line between me and the solution but ... :-/

Anyway, thanks again for the help ;)



-- 
*Etienne.
*

Re: Install SVN from YUM, change Sqlite3 library path

[Nico Kadel-Garcia]

On Thu, Aug 9, 2012 at 10:15 AM, Tilsley, Jerry M.
 wrote:
> All,
>
> I was able to compile and install the version of SQLite I needed out into the 
> public area.  Then I downloaded the source of an earlier version of 
> subversion and when I configured, it pulled in the sqlite.h file for the 
> correct version.  Now all is working for ALL my users as expected!
>
> Thanks,
>
> Jerry

Unless you installed it as an RPM and block yum from updating
subversion, this will break the next time subversion is updated in
your basic OS updates or if it is pulled in from dependencies for
another component, such as "git2svn".

The sqlite.h you are using should not be considered the "correct
version", seriously. It is apparently a non-standard, distributed
out-of-band version of SQLite and not part of the basic CentOS or RHEL
operating system and, in my experienced opinion, should not be used
for anything but that propietary software, to avoid precisely such
problems.

Why is it being found? Is there  LD_LIBRARY_PATH being set somewhere
with a non-standard path, is /etc/ld.so.conf being set oddly, or does
it actually include an out-of-date RPM for SQLite that is triggering
these version conflicts?

Re: Is there a way to post a comment to a subversion issue without agreeing to colabnet terms?

[Mark Phippard]

On Thu, Aug 9, 2012 at 2:36 PM, Katherine Marsden
 wrote:

> Anyway if  I cannot add the comment myself I would most appreciate if
> someone could add this comment and answer the question in the issue.  Thank
> you for your time.
>
> Kathey
>
> Comment
> issue 2725 Add ability to push configuration options into JavaHL
> http://subversion.tigris.org/issues/show_bug.cgi?id=2725
> Am I correct that this feature would provide the capability for ignoring
> whitespace to subceclipse:
> http://subclipse.tigris.org/issues/show_bug.cgi?id=1200 ?

To answer your question, No. Issue 2725 is not related to the
Subclipse option you mentioned.  Subversion's JavaHL blame method does
not expose an equivalent of the command line -x option.

https://subversion.apache.org/docs/javahl/1.7/org/apache/subversion/javahl/ISVNClient.html

So you would need to file a Subversion issue to enhance the blame
method to expose this as an option, such as adding an ignoreWhitespace
boolean on the method.

-- 
Thanks

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

Re: files in db/locks

[Daniel Shahaf]

rog7...@web.de wrote on Thu, Aug 09, 2012 at 19:18:40 +0200:
> Hello,
> 
> I'm wondering about some files in the subfolders of db/locks
> (Subversion 1.6, FSFS). The existence of a lot of files in this
> directory seems to slow down some operations, especially with
> TortoiseSVN. I understand, that each locked file in the repository
> leads to a file (or two?) in db/locks. But what is the intention of
> files in this directory, if there are no locks in a repository?
> 
> We have a repository, which had some locked files. These locks have
> been removed and the output of 'svnadmin lslocks ...' is empty, now.
> But db/locks still contains files. All of them look like the example
> below. They contain only a different amount of hashes, but no path
> to locked files in the repository.
> 
> --
> K 8
> children
> V 99
> a9025cf28195868e96018bbceeda0822
> d2fb526b8531d2ad89ddb92cfd0b9db4
> 00ff6f20f3a3286f3c9567e346ddd755
> 
> END
> --
> 
> 
> I found some explanation about the internal structure of FSFS, but
> didn't understand all parts regarding the db/lock folder:
> 
> http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
> 
> I'm not subscribed to this list and would appreciate being
> explicitly Cc:ed in any response. Thanks.
> 

If you lock /foo/bar/baz then db/locks/${hash} files are created for each of / ,
/foo , /foo/bar  .

Consequently, if (a) there are no locks in the repository, and (b) no
locks are being added or deleted (eg: the server is in read-only mode),
then it ought to be safe to remove all those hashes.

See libsvn_fs_fs/locks.c (and .h) for the gory details...


> 
> Ingo