Re: Picking up wrong libraries/dependencies

[Philip Martin]

Tom Hanstra  writes:

> Now I am trying to compile subversion 1.7.4.  I configure using this
> command:
>
> ./configure --prefix=/shared/svnprod/soft --with-apr=/shared/apr
> --with-apr-util=/shared/apr-util
> --with-apxs=/shared/svnprod/httpd/bin/apxs
> --with-sqlite=/shared/sqlite  --with-neon=/shared/neon
>
> Compilation works.  However, the difficulty I am running into is that
> I also have RHEL5 default versions of apr, apr-util, and sqlite on the
> server and, when I run the resulting executables, they are picking up
> the RHEL5 versions instead of the /shared versions.

Make sure you built /shared/svnprod/httpd to use /shared/apr and
/shared/apr-util.  Perhaps set LD_LIBRARY_PATH.

-- 
Philip

Re: Do all SVN clients run with all SVN servers?

[Rob Pointer]

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.

However (as far as I am aware) point releases are file (e.g. 1.6.1  and
1.6.2 clients would work with servers of 1.6 and below .

Rob

On 30 March 2012 01:50, Daniel Shahaf  wrote:

> Nico Kadel-Garcia wrote on Thu, Mar 29, 2012 at 20:33:44 -0400:
> > On Thu, Mar 29, 2012 at 8:03 AM, Daniel Shahaf  >wrote:
> >
> > > Nico Kadel-Garcia wrote on Thu, Mar 29, 2012 at 07:53:05 -0400:
> > > > On Thu, Mar 29, 2012 at 6:59 AM, Mark Phippard 
> > > wrote:
> > > >
> > > > > On Thu, Mar 29, 2012 at 6:35 AM, Ben Stover 
> > > wrote:
> > > > > > As I can see there are a couple of different SVN servers and
> mutiple
> > > SVN
> > > > > clients.
> > > > > >
> > > > > > Do all SVN clients work with all SVN servers?
> > > > > > Or are some clients tied to the usage of some special SVN
> servers?
> > > > >
> > > > > All client and servers should be interoperable, even across
> versions.
> > > > > So a 1.7 client should work with a 1.0 server and vice versa.
>  Clients
> > > > > are generally interoperable with each other on the same working
> copy
> > > > > as well.  In that scenario, all of the clients do need to be from
> the
> > > > > same major.minor Subversion version as the client working copy
> format
> > > > > typically changes between versions
> > > > >
> > > >
> > > > Some features are not backwards compatible. The syntax of
> svn:externals,
> > > > for example, has changed significantly. And there are still people
> with
> > >
> > > The old syntax is recognized by all servers and clients, and the help
> > > output documents exactly which syntaxes are not compatible with older
> > > (<=1.4) clients.
> > >
> > And RHEL 4 comes with subversion 1.1.1. It's still under extended support
> > from Red Hat: I'm trying to build a clean update to the Repoforge 1.6.17
> > that compiles on all RHEL 4 or greater releases, and it is *NOT* easy.
>
> Very nice, and good luck.  My main point was to clarify your statement
> about the compatibility of svn:externals, not to claim that 1.1 is or
> isn't supported.
>



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

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

  
*

Re: Do all SVN clients run with all SVN servers?

[Nico Kadel-Garcia]

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.
>
> However (as far as I am aware) point releases are file (e.g. 1.6.1  and
> 1.6.2 clients would work with servers of 1.6 and below .
>
>
It will *mostly* work to check out material from a new server repository
with an old client, and deal with a local working copy. There are nasty
edge cases: the syntax change in the "svn:externals" command is one of them.

This is an ongoing problem for old operating systems that should, frankly,
be obsoleted. But painful backporting is also what I get for being in the
business long enough that I remember when those systems were new

Re: Feature request: inhibiting checkout for tags and branches

[Konstantin Kolinko]

2012/3/29 coolie :
> I have an inherited repo structure that has many projects with their own
> tags and branches folders.
> Users check out the whole structure as there are common lib references etc,
> but don't need to see the full contents
> of tags or branches folders, which can be massive. I would like a property
> svn:inhibit similar to svn:ignore set on the root folder
> that limits the checkout depth to immediate (or empty) for a folder anywhere
> in the tree matching the list.
>
> By setting as a property, then a new checkout will inherit this property and
> limit the checkout depth for the named folders as required.
>
> Users can then checkout particular tag versions as normal if they require
> past versions.
>
> IMHO this will make the behavior of tags more like what the SVN manual says
> is just a "user friendly name for a revision".
> You wouldn't want to check out all revisions on the trunk, so why check out
> all revisions for tags by default?
>
> This would be a really cool improvement, as I see the problem has been
> mentioned many times on this group.

mod_dontdothat ?

http://svn.apache.org/repos/asf/subversion/branches/1.7.x/tools/server-side/mod_dontdothat/README


BTW, why are you sending your question to "subversion_us...@googlegroups.com" ?

The proper address of this mailing list is users.at.subversion.apache.org,
http://subversion.apache.org/mailing-lists.html


Best regards,
Konstantin Kolinko

Re: Do all SVN clients run with all SVN servers?

[Mark Phippard]

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/

svnsync: Error while replaying commit

[Gary]

I see a lot of reports of this error, but little in the way of
clear information as to what it might mean, or how to fix it:

$ svnsync sync file://`pwd`/dest
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .
[...]
Committed revision 79.
Copied properties for revision 79.
Transmitting file data ...
Committed revision 80.
Copied properties for revision 80.
svnsync: Error while replaying commit

Huh?

If I look at the source server log, revs 81 & 82 are "missing"
in the trunk. I imagine they are/were in a branch, which AFAIK
is no longer available. Is there any way to get around this?
Assuming that's the problem, of course.

RE: Merge bug -- svn:keywords and conflict resolution

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

> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: Thursday, March 29, 2012 4:51 AM
> To: Stephen Butler
> Cc: Varnau, Steve (Seaquest R&D); users@subversion.apache.org; Brackett,
> Faye
> Subject: Re: Merge bug -- svn:keywords and conflict resolution
> 
> Stephen Butler wrote on Thu, Mar 29, 2012 at 09:35:27 +0200:
> >
> >
> > On Mar 29, 2012, at 1:24 , Varnau, Steve (Seaquest R&D) wrote:
> >
> > > I did not get any responses on this bug report, neither confirming
> nor denying.
> >
> > We're an open community, as you know.  If something is neither
> > confirmed nor denied, then nothing happened. :-)
> >
> 
> I almost missed the rest of your reply, Stephen.  (I've left it quoted
> below; tldr: "Yes, please file an issue" :-) )
> 
> > > So I guess the next step is to file an issue?
> > >
> > > -Steve
> > >
> > >> -Original Message-
> > >> From: Varnau, Steve (Seaquest R&D)
> > [...]
> > >> ###  Here's the bug -- why do both sides of conflict show same
> content?
> > >> cat keyfile
> > >> <<< .working
> > >> $Date: 2012-03-26 10:09:19 -0700 (Mon, 26 Mar 2012) $ $Revision: 5
> > >> $ ===
> > >> $Date: 2012-03-26 10:09:19 -0700 (Mon, 26 Mar 2012) $ $Revision: 5
> > >> $
> > > .merge-right.r6
> > >> some changes
> > >> $Id$
> > >>
> >
> > FWIW, with 1.6.17 the working file has different content, including a
> > visible conflict in the first line.
> >
> > [[[
> > $ cat keyfile
> > <<< .working
> > $Date: 2012-03-29 09:15:48 +0200 (Thu, 29 Mar 2012) $ $Revision: 5 $
> > ===
> > $Date: 2012-03-29 09:15:46 +0200 (Thu, 29 Mar 2012) $ $Revision: 4 $
> > >>> .merge-right.r6
> >  some changes
> > $Id: keyfile 5 2012-03-29 07:15:48Z steve $ ]]]
> >
> > The other files are the same as with 1.7.
> >
> > In view of the incoming change to the svn:keywords property, from
> > "Date Revision" to "Id", this conflict (even in 1.6) doesn't make much
> sense to me.
> >
> > After the merge, with svn:keywords set to "Id", if we were to re-apply
> > the keyword translation, the conflict in the first line wouldn't
> > exist.  In the working copy and in^/trunk@6, the first line is simply
> > "$Date$ $Revision$", untranslated.
> >
> > I'm not sure why the first line remains expanded despite the change to
> > svn:keywords.  So, yes, please file an issue.
> >
> > Regards,
> > Steve Butler
> >
> >
> >

Re: svnsync: Error while replaying commit

[Henrik Sundberg]

Do you have a precommit hook now that was not there when revs 81-82
were committed?
Svn log will show the revisions whereever in the repository they were
made. Are they missing for real?
/$

On Fri, Mar 30, 2012 at 15:25, Gary  wrote:
> I see a lot of reports of this error, but little in the way of
> clear information as to what it might mean, or how to fix it:
>
> $ svnsync sync file://`pwd`/dest
> Committed revision 1.
> Copied properties for revision 1.
> Transmitting file data .
> [...]
> Committed revision 79.
> Copied properties for revision 79.
> Transmitting file data ...
> Committed revision 80.
> Copied properties for revision 80.
> svnsync: Error while replaying commit
>
> Huh?
>
> If I look at the source server log, revs 81 & 82 are "missing"
> in the trunk. I imagine they are/were in a branch, which AFAIK
> is no longer available. Is there any way to get around this?
> Assuming that's the problem, of course.
>

Re: relation to minfo-cnt bug Re: predecessor count for the root node-revision is wrong message

[Jason Wong]

On Wed, Mar 28, 2012 at 12:00 PM, Daniel Shahaf  wrote:
> Jason Wong wrote on Wed, Mar 28, 2012 at 11:49:20 -0700:
>> dump-noderev.pl /repo /
>> -
>> id: 0.0.r62104/28771
>> type: dir
>> pred: 0.0.r62103/28680
>> count: 62071
>> text: 62104 27520 1238 1238 ea635421e867454f9f7bc503c8160a2c
>> cpath: /
>> copyroot: 0 /
>> minfo-cnt: 25707
>> -
>>
>> dump-noderev.pl /mirror2 /
>> ---
>> id: 0.0.r62104/6122
>> type: dir
>> pred: 0.0.r62103/6039
>> count: 62104
>> text: 62104 4874 1235 1235 1f315ed2437ba5d70dba2587d9ef2d5a
>> cpath: /
>> copyroot: 0 /
>> minfo-cnt: 25707
>> ---
>>
>> Is this in line with what you expected?
>
> It's in line with my expectations, insofar as on the mirror the 'count'
> is correct.
>
> It also indicates that you weren't bitten by the minfo-cnt part of this
> bug.  As you know from the dev@ thread, Philip identified that part and
> fixed it too -- after my above email.
>
> Thanks again for your help in chasing down this bug.  It was backported
> today towards 1.7.5 too.
>
> Cheers,
>
> Daniel

Hi Daniel.

No problem. I am glad the issues are fixed. Thank you for all your help
and patience with my slow replies. It has been a busy couple of months
for me in trying find the time to do these tests.

So for correcting the "count" information in our live repository, I
should run svnsync on it at some point? Is there anything I need to do
after running that command in order to have it not link to the original?

Thanks.


Jason Wong

Re: relation to minfo-cnt bug Re: predecessor count for the root node-revision is wrong message

[Daniel Shahaf]

Jason Wong wrote on Fri, Mar 30, 2012 at 11:39:02 -0700:
> On Wed, Mar 28, 2012 at 12:00 PM, Daniel Shahaf  wrote:
> > Jason Wong wrote on Wed, Mar 28, 2012 at 11:49:20 -0700:
> >> dump-noderev.pl /repo /
> >> -
> >> id: 0.0.r62104/28771
> >> type: dir
> >> pred: 0.0.r62103/28680
> >> count: 62071
> >> text: 62104 27520 1238 1238 ea635421e867454f9f7bc503c8160a2c
> >> cpath: /
> >> copyroot: 0 /
> >> minfo-cnt: 25707
> >> -
> >>
> >> dump-noderev.pl /mirror2 /
> >> ---
> >> id: 0.0.r62104/6122
> >> type: dir
> >> pred: 0.0.r62103/6039
> >> count: 62104
> >> text: 62104 4874 1235 1235 1f315ed2437ba5d70dba2587d9ef2d5a
> >> cpath: /
> >> copyroot: 0 /
> >> minfo-cnt: 25707
> >> ---
> >>
> >> Is this in line with what you expected?
> >
> > It's in line with my expectations, insofar as on the mirror the 'count'
> > is correct.
> >
> > It also indicates that you weren't bitten by the minfo-cnt part of this
> > bug.  As you know from the dev@ thread, Philip identified that part and
> > fixed it too -- after my above email.
> >
> > Thanks again for your help in chasing down this bug.  It was backported
> > today towards 1.7.5 too.
> >
> > Cheers,
> >
> > Daniel
> 
> Hi Daniel.
> 
> No problem. I am glad the issues are fixed. Thank you for all your help
> and patience with my slow replies. It has been a busy couple of months
> for me in trying find the time to do these tests.
> 

Welcome.

> So for correcting the "count" information in our live repository, I
> should run svnsync on it at some point?

You already did, as you have a mirror.  (Maybe you created it via
dump/load.)  Now you just need to swap the mirror for the original
repository:

- stop commits
- svnsync sync URL/to/mirror2 URL/to/repo
  (or svnadmin dump -r (YOUNGEST ON MIRROR2):HEAD --deltas --incremental repo \
  | svnadmin load mirror2)
- rename repo repo.i4129-victim && rename mirror2 repo
- enable commits

> Is there anything I need to do
> after running that command in order to have it not link to the original?

You can optionally remove the svn:sync-* revprops from r0.

> 
> Thanks.
> 
> 
> Jason Wong

Problem with partial check out

[Elmar Teitge]

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 command on the whole working copy ... but the SQLite 

> database

> file did not shrink perceivable, nor the additional folders in the

pristine 

> directory, that keep the original files ...

> 

> Is it enough, to clean-up the svn status or are more options required 

> in

the 

> clean-up dialog, to get rid of the unused pristine files ?

> 

 

- The first checkbox there is enough (that is what "svn cleanup" 

command-line command does) 

  plus the last one (to apply cleanup to the nested WCs that belong to 

externals). 

 

The other checkboxes there are specific to TortoiseSVN. 

 

- The unneeded files are deleted from "pristine" directory.  Well, if 

you have 5 identical branches then there will be the same 1 pristine 

for 5 copies of a file in branches, so maybe that is why there were no 

substantial changes. 

 

- The db file does not shrink. It should not be of big size though. 

(It is possible to shrink it with some "sqlite pragma" command -- I 

have seen it once being mentioned on @subversion mailing lists). 

 

 

> To point 3, there were no modifications on that sandbox folder. 

> 

 

Best regards, 

Konstantin Kolinko 

 

 



 

 

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 s