Do all SVN clients run with all SVN servers?

[Rob Pointer]

Ah so there was my misunderstanding on the question. The question was
regarding using the client to connect via a web server (i.e. dav svn
protocol) I was assuming a direct repo connection. i should read properly
before replying :)

rob


On Friday, 30 March 2012, Mark Phippard wrote:

> On Fri, Mar 30, 2012 at 7:53 AM, Rob Pointer 
> wrote:
>
>> Forgive me if I am misunderstanding here however SVN clients cannot be
>> 'forward' compatible.  i.e. an svn 1.4 client will not work with a 1.6
>> server (repository format differs) and checking out in this manner would
>> produce an error saying that the expected repository format was incorrect.
>
>
> An SVN 1.0 client can checkout from an SVN 1.7 server just fine.
>  Obviously it will not support new features like merge tracking and tree
> conflicts, but the features that existed for a 1.0 client will still work.
>  The same would be true for 1.1, 1.2, 1.3, 1.4. 1.5 and 1.6 clients.  Heck,
> I am sure there are several pre-1.0 client versions that would still work
> properly.
>
> The only time a client would see the sort of errors you mention would be
> when using the file:// protocol.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>


-- 
*Rob Pointer MSc*
Software Specialist and Consultant
rpoin...@clearvision-cm.com 

*
Tel: +44 (0) 845 459 9530
**
**
 
  

  
*

RE: Problem with partial check out

[Bert Huijben]

Hi,

 

Are you sure you checked out the right directory from boost.

I performed a 

$ svn co http://svn.boost.org/svn/boost/trunk boost

(as recommended on http://www.boost.org/users/download/#repository)

on my 2 year old notebook without solid state disk. (Just a simple 7200rpm
2.5” drive)

 

And I got a working copy with just a 29 MB .svn/wc.db

The working coy contains 37383 nodes

And 33537 pristine files.

 

An fully recursive svn update from the root of this working copy takes about
2.5 seconds on the working copy. (A bit more if updates come in)

Probably with a hot filesystem cache, but stil...

 

My guess is that you accidentally checked out the root of the repository
instead of just trunk. You should never do that unless you really understand
what you are doing. (That would check out all files in all different
variants, etc.)

 

 

The ‘only this item’ update performs a single operation with network
initiation for every selected item. Usually that is orders of magnitude
slower than performing a recursive operation on the root. (Subversion is
fully optimized for recursive operations; not for single item operations)

 

Bert

 

From: Elmar Teitge [mailto:elmar.tei...@ultra-it.de] 
Sent: vrijdag 30 maart 2012 23:35
To: users@subversion.apache.org
Subject: Problem with partial check out

 

Hello,

 

I have a problem with partial checkout of the repository from the boost c++
library.

 

First I guessed, that this is a problem with Tortoise SVN, because there
have been problems with the TSVN

cache in the past. Switching off the caching mechanism showed, that this is
not the cause of the problem.

 

The total discussion with the TSVN developers is attached below.

 

Deleting the whole content of a folder from the working copy by doing an
“update to revision” with option

“only this item” is running over 30 hours and there is absolutely no
measurably progress with a solid state disk.

 

Doing an clean-up process takes only about an hour.

 

Is this an known issue … can anyone help with this topic ???

 

Thanks.

 

Best regards,

 

Elmar

 

 

 

 



 

 

Hello Elmar,

 

What you mean by a bug?  That database access when database is stored on a
solid state drive is slow? I would say it is not a bug, it is physics.

 

In essence I would say that there are many small transactions and each
updates the database, and writes are slow.

 

If you want to dig further

 

1) look for SQLite knowledge.  There are some subtle ways how the database
can be tuned. It is some specific subject and I cannot help you with it.

 

 

2) look at the mailing lists at subversion.apache.org  and their archives .

 

Performance of working copy operations is sometimes discussed there. Though
usually people are faced with it when trying to work over network (e.g.
client running on Windows accessing wc stored on a network drive somewhere).
That is one more scenario where performance is known to be poor.

 

 

3) the database size of 500 Mb is bad.  You have too many single files to
manage. :/

 

As I mentioned, svn cleanup would not shrink it.  There exist some sqlite
commands that can claim unused space in a database file, but you would need
an sql client to execute them, not svn client.

 

 

Best regards,

Konstantin Kolinko

 



 

 

 

Hello Konstantin, 

 

thanks for your response. 

 

I have done a new trial for checking out the repository ... 

 

Two folders were checked out, the branches and the sandbox folder ... I I
tried again dumping the content of the sandbox folders by "update to
revision" with option "only this item" ... that was running about 5 hours,
than I cancelled this process in the update dialog ...

 

I had a look in the .svn folder and found out, that the SQLite database file
was 570 MB in size ! 

 

So I decided to do an experiment and deleted all pristine content and all
the files in the working copy folders ... in the next step I have done the

 

clean-up process like you described it ... 

 

After the clean-up process, the database file is still 570 MB large ... 

 

... and an update process with "only this item" is still in progress with no

 

result ... 

 

I am sure, that my problem is caused by a bug. 

 

But how to do a trace, that helps to find that bug ? 

 

Best regards, 

 

Elmar 

 

 

 

 

-Ursprüngliche Nachricht- 

Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 

Gesendet: Sonntag, 25. März 2012 22:37 

An: us...@tortoisesvn.tigris.org 

Betreff: Re: Partial Checkout Problem 

 

2012/3/25 Elmar Teitge : 

> Hello Konstantin,

> 

> thank you for your advice.

> 

> To point 1, I have selected the folder that shall be cleared from

> subfolders, called "sandbox" and then selected "update to revision" in the

 

> context menu with selected option "only this item".

> 

> To point 2, I have done a few cycles doing the update in point 1 and 

> doing

 

> an clean-up 

Any chance of backporting gnome-keyring or kwallet to RHEL 4 compatibility? Just asking....

[Nico Kadel-Garcia]

I'm spending way too much time backporting 1.6.17 work to RHEL 4, to
publish for Repoforge. So far so good, I'm working from Mike Bauer work at
plos.org, and tying it to my old Repoforge work for 1.6.x, and that's based
on Fedora 16 source RPM's on the last go-round. No big problem so far, it's
just a lot of testing changes one at a time.

But there are some side packages that just won't work for RHEL 4. In
particular, the "--with-kwallet" option isn't workable with such an old
KDE, and the "--with-gnome-keyring" won't build with such an old DBus.
(I've got workarounds for --with-kwallet for RHEL 6 compilation, but
--with-kwallet doesn't work for RHEL 5, either.)

I can disable them from package compilation for RHEL 4, but is there anyone
familiar enough with those tools to try backporting them? I realize RHEL 4
is on extended support only, but sometimes migrating people off of old
systems really benefits from access to supported source control tools.

Re: Any chance of backporting gnome-keyring or kwallet to RHEL 4 compatibility? Just asking....

[Stefan Sperling]

On Sat, Mar 31, 2012 at 10:50:31AM -0400, Nico Kadel-Garcia wrote:
> I'm spending way too much time backporting 1.6.17 work to RHEL 4, to
> publish for Repoforge. So far so good, I'm working from Mike Bauer work at
> plos.org, and tying it to my old Repoforge work for 1.6.x, and that's based
> on Fedora 16 source RPM's on the last go-round. No big problem so far, it's
> just a lot of testing changes one at a time.
> 
> But there are some side packages that just won't work for RHEL 4. In
> particular, the "--with-kwallet" option isn't workable with such an old
> KDE, and the "--with-gnome-keyring" won't build with such an old DBus.
> (I've got workarounds for --with-kwallet for RHEL 6 compilation, but
> --with-kwallet doesn't work for RHEL 5, either.)
> 
> I can disable them from package compilation for RHEL 4, but is there anyone
> familiar enough with those tools to try backporting them? I realize RHEL 4
> is on extended support only, but sometimes migrating people off of old
> systems really benefits from access to supported source control tools.

Who are you building these package for? Do the users really require the
kwallet/gnome password store features? If I were you and I was building
these RHEL4 packages for the general public I would decide that these
features are not critical enough to warrant the backporting effort.

Keep in mind that you are essentially talking about backporting large
chunks of KDE/Gnome and the underlying toolkits (QT and GTK). I doubt
anybody would want to do this for fun.