Re: Assertion failed and crash with 1.7.1

[Attila Nagy]

On 10/26/11 15:37, Philip Martin wrote:

Attila Nagy  writes:


I'm trying to update a working copy of some tens of GBs with svn 1.7.1

Did you upgrade with 1.7.0 or 1.7.1?
I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm 
currently using.
The upgrade took nearly one week (I can't afford a clean checkout, 
because I have to preserve the files' inode numbers), at the start it 
was running very fast, and at the end of the week it could print a new 
directory in every 8-10 seconds, while the svn processes CPU usage was 100%.
The disks weren't touched, it seems that even with a database completely 
in the OS's buffer cache the SQL operations are pretty slow with a lot 
of files.
Could it be because some indexes are missing (or not optimized for this 
amount of files), or it is what we could get from SQLite?



$ svn up
Updating '.':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line
1582: assertion failed (action == svn_wc_conflict_action_edit ||
action == svn_wc_conflict_action_delete || action ==
svn_wc_conflict_action_replace)
Abort (core dumped)

Can you show us a gdb stack trace?
I'm sorry, this is a production machine and this error caused a major 
lockup in our business processes, so I've had to work around it, and I 
lost the core file in the process.
BTW, there was one tree conflict somewhere, it seems that an svn resolve 
solved the issue.


How many working nodes do you have?
sqlite3 .svn/wc.db "select count (*) from nodes where op_depth>  0"


The query say that I have one. (now, after the conflict resolution)

Re: read-only attribut

[Stefan Sperling]

On Wed, Oct 26, 2011 at 10:27:24PM +0200, romaric rillet wrote:
> Hi,
> 
> I have un file with the filesystem read-only attribut.
> I commit this file with .
> Since version 1.7, the filesystem read-only attribut is removed by the
> commit operation.
> 
> I would like to keep this attribut ( like with version 1.6 ).

There is built-in support for keeping this attribute.
But there are two ways to work around this limitation:

1) Use the 'asvn' script instead of 'svn', see
   https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/asvn
   This script requires bash so you need cygwin to run it on windows.

2) Set the svn:needs-lock property on the file. The file will be marked
   read-only upon checkout. Running 'svn lock' on the file will make it
   writable, and after commit the file will be read-only again.

Re: Error during svnadmin load (svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property)

[Daniel Shahaf]

Robert-Jean Denault wrote on Wed, Oct 26, 2011 at 16:27:52 -0400:
> Hello Stefan, Konstantin
> 
> I solved the problem by running a loop around svn pget, svn pset.
> 
> The svn pget returns clean log entries, so extraction the svn:log entries, 
> and resetting them cleans them up.
> 
>   #!/bin/ksh
>   rev=1
>   repo=PATH_TO_REPO
>   URL=URL_TO_REPO
>   while [ $rev -lt `svnlook youngest $repo` ]
>   do
>echo revision $rev
>svn pget svn:log  --revprop -r $rev  $URL >/tmp/svn$$.log

For the record, those kind of scripts should usually use 'propget
--strict' --- but that's probably going to reverse the effect you're
trying to apply here.

>svn pset  svn:log  --revprop -r $rev --file /tmp/svn$$.log  $URL
>let rev=rev+1

If you change this line to:
rev=`expr $rev + 1`

The script will be a valid #!/bin/sh script.

>   done
> 
> Thanks for your help,
> 
> Robert Denault
> 
> -Message d'origine-
> De : Stefan Sperling [mailto:s...@elego.de] 
> Envoyé : October 26, 2011 10:13 AM
> À : Robert-Jean Denault
> Cc : Konstantin Kolinko; users@subversion.apache.org
> Objet : Re: Error during svnadmin load (svnadmin: E125005: Cannot accept 
> non-LF line endings in 'svn:log' property)
> 
> On Wed, Oct 26, 2011 at 09:28:39AM -0400, Robert-Jean Denault wrote:
> > Hello Stefan,
> > 
> > The properties were set during commits with Tortoise SVN and SubClipse.
> 
> It's possible that subclipse clients didn't properly encode log message
> data sent to the server.
> 
> BTW, another trick to fix the issue is to copy the repository using
> svnsync. As of Subversion 1.6.3 (which is fairly old), svnsync normalizes
> all svn:* properties to LF line-endings automatically.

RE: read-only attribut

[Cooke, Mark]

> On Wed, Oct 26, 2011 at 10:27:24PM +0200, romaric rillet wrote:
> > Hi,
> > 
> > I have un file with the filesystem read-only attribut.
> > I commit this file with .
> > Since version 1.7, the filesystem read-only attribut is 
> > removed by the commit operation.
> > 
> > I would like to keep this attribut ( like with version 1.6 ).
> 
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de] 
> Sent: 27 October 2011 10:15
> Subject: Re: read-only attribut
> 
> There is built-in support for keeping this attribute.
> But there are two ways to work around this limitation:
> 
> 1) Use the 'asvn' script instead of 'svn', see
>
> https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/asvn
>This script requires bash so you need cygwin to run it on windows.
> 
> 2) Set the svn:needs-lock property on the file. The file will
>be marked read-only upon checkout. Running 'svn lock' on the
>file will make it writable, and after commit the file will
>be read-only again.

Question: why would svn fiddle with this anyway?  I would not expect svn to 
change local attributes at all (unless svn:needs-lock is set, of course).

~ mark c

Re: Assertion failed and crash with 1.7.1

[Stefan Sperling]

On Thu, Oct 27, 2011 at 10:47:51AM +0200, Attila Nagy wrote:
> On 10/26/11 15:37, Philip Martin wrote:
> >Attila Nagy  writes:
> >
> >>I'm trying to update a working copy of some tens of GBs with svn 1.7.1
> >Did you upgrade with 1.7.0 or 1.7.1?
> I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
> currently using.
> The upgrade took nearly one week (I can't afford a clean checkout,
> because I have to preserve the files' inode numbers),

This is an interesting use case, but please keep in mind that this
is not a normal use case for Subversion. Checkouts are considered
disposable. There are scenarios where getting a new checkout is the
best way to replace a broken working copy.

You will have your reasons for using Subversion this way, but if you
care about inode numbers you might want to look into tools that know
more about internals of the filesystem you are using and preserve
inode information.

> at the start
> it was running very fast, and at the end of the week it could print
> a new directory in every 8-10 seconds, while the svn processes CPU
> usage was 100%.

This sounds like a linear table scan. There might be room for
optimisation by adding another index.

> >>$ svn up
> >>Updating '.':
> >>svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line
> >>1582: assertion failed (action == svn_wc_conflict_action_edit ||
> >>action == svn_wc_conflict_action_delete || action ==
> >>svn_wc_conflict_action_replace)
> >>Abort (core dumped)
> >Can you show us a gdb stack trace?
> I'm sorry, this is a production machine and this error caused a
> major lockup in our business processes,

I'm sorry to hear that.

This assertion you ran into looks exactly like the one reported here:
http://svn.haxx.se/dev/archive-2011-10/0305.shtml

Is there a symlink in the working copy?
If so this is a known regression with updating symlinks. A fix was made
and is scheduled for release in 1.7.2.
The fix was committed in this revision:
http://svn.apache.org/viewvc?view=revision&revision=r1186944
If you apply that patch to your 1.7.1 installation the update
should succeed.

> so I've had to work around
> it, and I lost the core file in the process.
> BTW, there was one tree conflict somewhere, it seems that an svn
> resolve solved the issue.

The tree conflict was probably flagged because of the above bug.
It is spurious and can be removed via 'svn resolve'.

Re: Assertion failed and crash with 1.7.1

[Attila Nagy]

On 10/27/11 11:28, Stefan Sperling wrote:

On Thu, Oct 27, 2011 at 10:47:51AM +0200, Attila Nagy wrote:

On 10/26/11 15:37, Philip Martin wrote:

Attila Nagy   writes:


I'm trying to update a working copy of some tens of GBs with svn 1.7.1

Did you upgrade with 1.7.0 or 1.7.1?

I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
currently using.
The upgrade took nearly one week (I can't afford a clean checkout,
because I have to preserve the files' inode numbers),

This is an interesting use case, but please keep in mind that this
is not a normal use case for Subversion. Checkouts are considered
disposable. There are scenarios where getting a new checkout is the
best way to replace a broken working copy.

I hope I will never have to do that! :)
BTW, with the current (1.7) WC-implementation, what possible problems do 
you see where this would be needed?
Previously with the per-directory .svn directories it was of course much 
easier, I could checkout the WC and move the .svn directory to its 
original place.

Now I (would) have to do this for all directories...


You will have your reasons for using Subversion this way, but if you
care about inode numbers you might want to look into tools that know
more about internals of the filesystem you are using and preserve
inode information.
There is no such a thing I guess. I don't care about inodes until they 
don't change on existing files.



at the start
it was running very fast, and at the end of the week it could print
a new directory in every 8-10 seconds, while the svn processes CPU
usage was 100%.

This sounds like a linear table scan. There might be room for
optimisation by adding another index.
Maybe, but I don't know what to index, because it seems to be hard to 
get running SQLite operations out of the system.



$ svn up
Updating '.':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line
1582: assertion failed (action == svn_wc_conflict_action_edit ||
action == svn_wc_conflict_action_delete || action ==
svn_wc_conflict_action_replace)
Abort (core dumped)

Can you show us a gdb stack trace?

I'm sorry, this is a production machine and this error caused a
major lockup in our business processes,

I'm sorry to hear that.

This assertion you ran into looks exactly like the one reported here:
http://svn.haxx.se/dev/archive-2011-10/0305.shtml

Is there a symlink in the working copy?

Sure, a lot of them. (I use full operating system copies)

If so this is a known regression with updating symlinks. A fix was made
and is scheduled for release in 1.7.2.
The fix was committed in this revision:
http://svn.apache.org/viewvc?view=revision&revision=r1186944
If you apply that patch to your 1.7.1 installation the update
should succeed.
I could finally resolve the problem with some deletes and svn resolve, 
but that's great to hear!



so I've had to work around
it, and I lost the core file in the process.
BTW, there was one tree conflict somewhere, it seems that an svn
resolve solved the issue.

The tree conflict was probably flagged because of the above bug.
It is spurious and can be removed via 'svn resolve'.

Yes, this was the problem.

Thanks!

AW: Assertion failed and crash with 1.7.1

[Markus Schaber]

Hi,

> Von: Attila Nagy [mailto:b...@fsn.hu] 
> BTW, with the current (1.7) WC-implementation, what possible problems do you 
> see where this would be needed?
> Previously with the per-directory .svn directories it was of course much 
> easier, I could checkout the WC and move the .svn directory to its original 
> place.
> Now I (would) have to do this for all directories...

If you have uncommitted property modifications, copies or moves in the working 
copy, a lossless transition (or repair) of the WC to 1.7 should be possible in 
the following ways:

1) Preparation: Delete all .svn subdirectories in the working copy

2) create a separate checkout.

3) move or copy the .svn subdirectory of the new checkout into the top level 
directory of the existing working copy.

Or:

1) Preparation: Delete all .svn subdirectories in the working copy

2) "svn checkout --force" in the existing working copy.

I'm not sure whether this will work fine with externals, however. :-)

Mit freundlichen Grüßen

Markus Schaber
-- 
___
We software Automation.

3S-Smart Software Solutions GmbH
Markus Schaber | Entwicklung
Memminger Str. 151 | 87439 Kempten | Tel. +49-831-54031-0 | Fax +49-831-54031-50

Email: m.scha...@3s-software.com | Web: http://www.3s-software.com 
CoDeSys Internet-Forum: http://forum.3s-software.com

Geschäftsführer: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | 
Handelsregister: Kempten HRB 6186 | USt-IDNr.: DE 167014915

Re: Assertion failed and crash with 1.7.1

[Stefan Sperling]

On Thu, Oct 27, 2011 at 09:53:11AM +, Markus Schaber wrote:
> Hi,
> 
> > Von: Attila Nagy [mailto:b...@fsn.hu] 
> > BTW, with the current (1.7) WC-implementation, what possible problems do 
> > you see where this would be needed?
> > Previously with the per-directory .svn directories it was of course much 
> > easier, I could checkout the WC and move the .svn directory to its original 
> > place.
> > Now I (would) have to do this for all directories...
> 
> If you have uncommitted property modifications, copies or moves in the 
> working copy, a lossless transition (or repair) of the WC to 1.7 should be 
> possible in the following ways:
> 

You meant to say "*no* uncommitted property modifications, copies, or moves",
right?

But even then, in general, what you suggest isn't safe.
The broken working copy might be a mixed-revision working copy and
refer to pristine files from various revisions. In which case there
is no way a new checkout can replicate the needed DB state.

> 1) Preparation: Delete all .svn subdirectories in the working copy
> 
> 2) create a separate checkout.
> 
> 3) move or copy the .svn subdirectory of the new checkout into the top level 
> directory of the existing working copy.
> 
> Or:
> 
> 1) Preparation: Delete all .svn subdirectories in the working copy
> 
> 2) "svn checkout --force" in the existing working copy.
> 
> I'm not sure whether this will work fine with externals, however. :-)

RE: Error when updating

[Wabe W]

From: Philip Martin 


Date: Tue, 25 Oct 2011 18:00:07 +0100


>People are replying to utwente.nl address in your Reply-To header.


Thanks for pointing this out. I don't use this hotmail address a lot and 
totally forgot the address in the reply-to (which stopped working about 5 years 
ago...)

>Did you checkout the new working copy to the same location as the oldworking 
>copy?  
Yes. I did.
>If so did you move/delete the old working copy first?

Yes. I moved them.

>What state is your working copy before the update that fails? 
Perfectly fine.Clean up work nicely, everything up-to-date, nothing wrong.
>Any
modifications? 
No.

I also tried a checkout of a(n existing) repository to a different location. I 
get the same error message when I try to update.

>Can you reproduce the problem with a local test
repository? I tried to reproduce the problem by making a local test repository. 
However, there's no problem anymore. It works perfectly fine.

Maybe it is like this because our SVN server has not yet been upgraded to 1.7.
Although release notes say:"Older clients and servers interoperate 
transparently with 1.7
servers and clients.  However, some of the new 1.7 features may
not be available unless both client and server are the latest 
version.  There are also cases where a new feature will work 
but will run less efficiently if the client is new and the 
server old."
It seems to me that SVN Update is not a 'new feature' and, therefore, it should 
work, right?
(Anyway, I will request an update of our server.)
Regards,

Wabe.

---
Subversion Exception!
---
In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
 line 11039: assertion failed (base_status == svn_wc__db_status_incomplete)
---
OK   
---

  

Re: Error when updating

[Stefan Sperling]

On Thu, Oct 27, 2011 at 10:20:36AM +, Wabe W wrote:
> From: Philip Martin
> >Can you reproduce the problem with a local test repository?
>
> I tried to reproduce the problem by making a local test repository.
> However, there's no problem anymore. It works perfectly fine.

Are path-based access restrictions in place on the SVN server you
are using where the update fails?
If so, is there a path which you have no access to within the working copy?

Re: Assertion failed and crash with 1.7.1

[Philip Martin]

Attila Nagy  writes:

> On 10/26/11 15:37, Philip Martin wrote:
>> Attila Nagy  writes:
>>
>>> I'm trying to update a working copy of some tens of GBs with svn 1.7.1
>> Did you upgrade with 1.7.0 or 1.7.1?
> I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
> currently using.
> The upgrade took nearly one week (I can't afford a clean checkout,
> because I have to preserve the files' inode numbers), at the start it
> was running very fast, and at the end of the week it could print a new
> directory in every 8-10 seconds, while the svn processes CPU usage was
> 100%.
> The disks weren't touched, it seems that even with a database
> completely in the OS's buffer cache the SQL operations are pretty slow
> with a lot of files.
> Could it be because some indexes are missing (or not optimized for
> this amount of files), or it is what we could get from SQLite?

There is one query/index fix in 1.7.1 but it doesn't affect upgrade.

I've not upgraded a wc as large as yours but I have just upgraded a 5GB
working copy on my desktop machine (3 years old, not hugely powerful).
It took about 45 minutes and used about 30 minutes of CPU.  There wasn't
any noticeable slowdown as the update proceeded.

I see that you are using Fibre Channel storage, perhaps there is an
SQLite issue there?  What sort of filesystem are you using?

-- 
Philip

Re: Error when updating

[Philip Martin]

Wabe W  writes:

> I also tried a checkout of a(n existing) repository to a different
> location. I get the same error message when I try to update.

This is reproducible?  You checkout some revision R1 and update to R2
and see the error?

Can you describe the changes between R1 and R2?

Is there a single revision that causes the problem: checkout R1 and
update revision by revision to R2 to determine when the error occurs.

> Maybe it is like this because our SVN server has not yet been upgraded to 1.7.
> Although release notes say:

> "Older clients and servers interoperate transparently with 1.7
> servers and clients.  However, some of the new 1.7 features 
> may
> not be available unless both client and server are the latest 
> version.  There are also cases where a new feature will work 
> but will run less efficiently if the client is new and the 
> server old."

> It seems to me that SVN Update is not a 'new feature' and, therefore,
> it should work, right?  (Anyway, I will request an update of our
> server.)  Regards,

The server version should be irrelevant.

-- 
Philip

Re: Assertion failed and crash with 1.7.1

[Mark Phippard]

On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy  wrote:

>  On 10/26/11 15:37, Philip Martin wrote:
>
> Attila Nagy   writes:
>
>
>  I'm trying to update a working copy of some tens of GBs with svn 1.7.1
>
>  Did you upgrade with 1.7.0 or 1.7.1?
>
>  I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
> currently using.
> The upgrade took nearly one week (I can't afford a clean checkout, because
> I have to preserve the files' inode numbers), at the start it was running
> very fast, and at the end of the week it could print a new directory in
> every 8-10 seconds, while the svn processes CPU usage was 100%.
> The disks weren't touched, it seems that even with a database completely in
> the OS's buffer cache the SQL operations are pretty slow with a lot of
> files.
> Could it be because some indexes are missing (or not optimized for this
> amount of files), or it is what we could get from SQLite?
>

I can see where having all that RAM could help greatly when the database is
being read, but I do not see how it would help when we are writing to the
database.  I would imagine the database does stuff to flush itself to disk
whenever a transaction is committed.  I thought this was why we see 1.7
slower than other versions via NFS, even on small working copies where the
database would fit in anyones RAM.

I would imagine svn upgrade is almost entirely writes and I recall it does
quite a few transactions.  So couldn't the linear slow down just be based on
the growth in the amount of bytes that are written to disk each time?

-- 
Thanks

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

Re: Assertion failed and crash with 1.7.1

[Attila Nagy]

On 10/27/11 13:47, Mark Phippard wrote:
On Thu, Oct 27, 2011 at 4:47 AM, Attila Nagy > wrote:


On 10/26/11 15:37, Philip Martin wrote:

Attila Nagy    writes:


I'm trying to update a working copy of some tens of GBs with svn 1.7.1

Did you upgrade with 1.7.0 or 1.7.1?

I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
currently using.
The upgrade took nearly one week (I can't afford a clean checkout,
because I have to preserve the files' inode numbers), at the start
it was running very fast, and at the end of the week it could
print a new directory in every 8-10 seconds, while the svn
processes CPU usage was 100%.
The disks weren't touched, it seems that even with a database
completely in the OS's buffer cache the SQL operations are pretty
slow with a lot of files.
Could it be because some indexes are missing (or not optimized for
this amount of files), or it is what we could get from SQLite?


I can see where having all that RAM could help greatly when the 
database is being read, but I do not see how it would help when we are 
writing to the database.  I would imagine the database does stuff to 
flush itself to disk whenever a transaction is committed.  I thought 
this was why we see 1.7 slower than other versions via NFS, even on 
small working copies where the database would fit in anyones RAM.


I would imagine svn upgrade is almost entirely writes and I recall it 
does quite a few transactions.  So couldn't the linear slow down just 
be based on the growth in the amount of bytes that are written to disk 
each time?


I've checked the disk IO stat and I couldn't see any bottlenecks there. 
In fact while upgrade-ing, I barely saw any disk IO.
Checking the process revealed a lot of random reads from the wc.db, 
which the OS could serve out of memory.
BTW, I don't have any transaction-related files next to my wc.db (I 
remember about wal, or journal named files, but I'm not a regular user 
of SQLite), and definitely couldn't see too much fsyncs.

Re: Assertion failed and crash with 1.7.1

[Attila Nagy]

On 10/27/11 12:58, Philip Martin wrote:

Attila Nagy  writes:


On 10/26/11 15:37, Philip Martin wrote:

Attila Nagy   writes:


I'm trying to update a working copy of some tens of GBs with svn 1.7.1

Did you upgrade with 1.7.0 or 1.7.1?

I've upgraded the WC with 1.7.0, then switched to 1.7.1, which I'm
currently using.
The upgrade took nearly one week (I can't afford a clean checkout,
because I have to preserve the files' inode numbers), at the start it
was running very fast, and at the end of the week it could print a new
directory in every 8-10 seconds, while the svn processes CPU usage was
100%.
The disks weren't touched, it seems that even with a database
completely in the OS's buffer cache the SQL operations are pretty slow
with a lot of files.
Could it be because some indexes are missing (or not optimized for
this amount of files), or it is what we could get from SQLite?

There is one query/index fix in 1.7.1 but it doesn't affect upgrade.

I've not upgraded a wc as large as yours but I have just upgraded a 5GB
working copy on my desktop machine (3 years old, not hugely powerful).
It took about 45 minutes and used about 30 minutes of CPU.  There wasn't
any noticeable slowdown as the update proceeded.

I see that you are using Fibre Channel storage, perhaps there is an
SQLite issue there?  What sort of filesystem are you using?


ZFS.
It it worth to make benchmarks with this WC with 1.6 and 1.7? I so, I 
can try to find the time for it.

Re: Assertion failed and crash with 1.7.1

[Philip Martin]

Mark Phippard  writes:

> I would imagine svn upgrade is almost entirely writes and I recall it does
> quite a few transactions.  So couldn't the linear slow down just be based on
> the growth in the amount of bytes that are written to disk each time?

Yes, number of transactions matters a lot.  However upgrade is a special
case that runs in a single SQLite transaction as this makes most
upgrades faster.  Maybe for really large upgrades the huge transaction
is a problem?  My 100,000 node working copy upgrades in 45 minutes.

Upgrade does a number of read queries as well as writes, but all within
the same transaction.

-- 
Philip

Re: Assertion failed and crash with 1.7.1

[Attila Nagy]

On 10/27/11 14:13, Philip Martin wrote:

Mark Phippard  writes:


I would imagine svn upgrade is almost entirely writes and I recall it does
quite a few transactions.  So couldn't the linear slow down just be based on
the growth in the amount of bytes that are written to disk each time?

Yes, number of transactions matters a lot.  However upgrade is a special
case that runs in a single SQLite transaction as this makes most
upgrades faster.  Maybe for really large upgrades the huge transaction
is a problem?  My 100,000 node working copy upgrades in 45 minutes.
I don't have too much files/directories either, currently: 1772120, 
that's only an order of magnitude bigger.
What I could see is that svn's memory usage has grown constantly during 
the operation. It started on about 20M resident and went to 
approximately 60-80M.
I don't know for sure because I lost the interest in watching it in 
about 3-4 days, so I'm just extrapolation from the last seen value 
(sixty something megabytes on day 3). :)



Upgrade does a number of read queries as well as writes, but all within
the same transaction.

I guess, you are right, maybe the big transaction caused the major 
slowdown.

AW: Assertion failed and crash with 1.7.1

[Markus Schaber]

Hi, Stefan,

Von: Stefan Sperling [mailto:s...@elego.de]
> On Thu, Oct 27, 2011 at 09:53:11AM +, Markus Schaber wrote:

> > If you have uncommitted property modifications, copies or moves in the
> working copy, a lossless transition (or repair) of the WC to 1.7 should be
> possible in the following ways:
> >
> 
> You meant to say "*no* uncommitted property modifications, copies, or
> moves", right?

Right. :-)

Re: Assertion failed and crash with 1.7.1

[Mark Phippard]

On Thu, Oct 27, 2011 at 8:12 AM, Attila Nagy  wrote:

> ZFS.
> It it worth to make benchmarks with this WC with 1.6 and 1.7? I so, I can
> try to find the time for it.
>

There are some pretty easy to run benchmarks you can run to see if 1.7 is
simply slower in your environment.  See:

https://ctf.open.collab.net/sf/projects/csvn/

If those benchmarks show 1.7 is slower for you, then that would point to
issues with the 1.7 changes in your environment.  As I mentioned earlier,
and as an example, these benchmarks show that 1.7 is slower with WC on a
network mount.

If the benchmarks show 1.7 is faster, then we could focus on scalability
issues that your working copy raises.  Maybe inefficient indexes or
something like that.

-- 
Thanks

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

upgrade to 1.7

[marc.tangrams]

Hello,
This append when i upgrade working copy after instal of version 1.7
Thanks for your help
Best regards
Marc Salama
---
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):

Fichier

'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
  ligne 1935 : échec de la vérification 
(svn_checksum_match(entry_md5_checksum,

  found_md5_checksum))
---
OK
---

tortoise 1.7 - error on repository manipulation

[Erwane Breton]

Hi,

history :
I haved a FreeBSD server (8.0-STABLE) with subversion-1.6.17_2 port.
Acces to repository is configured thrue apache 2.2 + mod_dav + dav_svn.
Of course, all works fine :)

I've got a new server on FreeBSD 8.2-STABLE with subversion-1.7.1, 
apache, mod_dav & dav_svn.

All works fine ... in checkout and update.

For migration, i've make first a rsync only, when i saw the error (cf 
bottom) i've made that more cleanly with svnadmin dump and svnadmin load.

In both cases, result is the same.

Now the error ^^

On my client (windows 7 x64 tortoise SVN), i CAN commit with Tortoise 
1.6.15 on my laptop but i CAN'T commit (or rename or delete) on my other 
computer with tortoise 1.7.1.22161


The error is always the same


Commit
Commit failed (details follow):
'/svn/site/*!svn/me*' path not found


My repository is https://xyz.coda-cola.net/svn/site/trunk

I've tried svnadmin upgrade, exactly the same.

apache debug error logs (without openSSL informations)

[Thu Oct 27 14:58:57 2011] [info] Connection: Client IP: 
82.226.xxx.xxx, Protocol: SSLv3, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
[Thu Oct 27 14:58:57 2011] [info] Initial (No.1) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 82.226.xxx.xxx] 
Path to authz file is /exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 401 to 272 : URL /svn/site/trunk
[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.2) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 82.226.xxx.xxx] 
Path to authz file is /exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access 
granted: 'erwane' OPTIONS site:/trunk
[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 188 to 126 : URL /svn/site/trunk
[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.3) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 82.226.xxx.xxx] 
Path to authz file is /exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access 
granted: 'erwane' POST site:
[Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL /svn/site/*!svn/me*


After googled, i've found only "no space left on disk" but my ZFS volume 
is completely not full.


just tried without SSL, it's the same.

really dunno where to search now :(

Thanks for help

--
Erwane Breton
 Phea
Tel: 09 51 20 23 23
Mob: 06 76 46 54 61

SVN v1.7.1 asserting / crashing - workqueue.c, line 672

[Andrey Ogorodnik]

Hello ,

WANdisco SVN v1.7.1 server. Updated to 1.7.1 from 1.7.0 because getting the
same problem on 1.7.0. Update did not help to solve an issue.

When using svn cleanup, receiving this assert/crash.

===
C:\X\trunk\SRC>svn cleanup
svn: E235000: In file '..\..\..\subversion\libsvn_wc\workqueue.c' line 672: 
assertion failed (checksum != NULL)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
===

Previous steps was to resolve tree conflict in some directory...
(Using WANdisco SVN v1.7.0 and TortoiseSVN v1.7.0)

Any ideas what to do now?

-- 
Best regards,
 Andrey  mailto:ogorodni...@mail.ru

Working Copy Upgrade Error

[Ayden Young]

On Windows 7 Enterprise.

 

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

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.1\ext\subversion\subversion
\libsvn_wc\util.c'

line 300: assertion failed (svn_uri_is_canonical(repos_url, pool) &&

svn_relpath_is_canonical(path_in_repos) && SVN_IS_VALID_REVNUM(peg_rev))

---

OK   

---

 

Ayden Young I Program Manager I Trimble Hosting Services

Office: +1-480-940-6583 I Mobile: +1-480-209-4370

 

Re: SVN v1.7.1 asserting / crashing - workqueue.c, line 672

[Stefan Sperling]

On Thu, Oct 27, 2011 at 06:00:15PM +0400, Andrey Ogorodnik wrote:
> Hello ,
> 
> WANdisco SVN v1.7.1 server. Updated to 1.7.1 from 1.7.0 because getting the
> same problem on 1.7.0. Update did not help to solve an issue.
> 
> When using svn cleanup, receiving this assert/crash.
> 
> ===
> C:\X\trunk\SRC>svn cleanup
> svn: E235000: In file '..\..\..\subversion\libsvn_wc\workqueue.c' line 672: 
> assertion failed (checksum != NULL)
> 
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> ===
> 
> Previous steps was to resolve tree conflict in some directory...
> (Using WANdisco SVN v1.7.0 and TortoiseSVN v1.7.0)
> 
> Any ideas what to do now?

I think 1.7.0 produced a bad working copy during upgrade,
and 1.7.1 cannot use it. Try a new checkout with 1.7.1. If the
problem persists in a new checkout, please let us know.

SVN bdb to fsfs - dump file problem

[Andrej Kičina]

Hello,

I try to convert SVN repository from bdb to fsfs format. But when I try to
generate dump file, I get an error with description to send you the .log
file. Could you please tell me what could be wrong? Thanks.

Best regards,
Andrej Kicina


svn-crash-log20111027183213.log
Description: Binary data

Re: SVN bdb to fsfs - dump file problem

[Daniel Shahaf]

You may be running with a Berkeley DB library different than the one
your binaries were compiled against.

For future reference, don't send only the .log file but also the
transcript of the svnadmin invocation (copy-paste it from your
terminal).

Andrej Kičina wrote on Thu, Oct 27, 2011 at 18:33:53 +0200:
> Hello,
> 
> I try to convert SVN repository from bdb to fsfs format. But when I try to
> generate dump file, I get an error with description to send you the .log
> file. Could you please tell me what could be wrong? Thanks.
> 
> Best regards,
> Andrej Kicina

Re: tortoise 1.7 - error on repository manipulation

[Daniel Shahaf]

Does it work with a 1.6 client?

The me resource is new in HTTPv2, which was added in 1.6.  

Erwane Breton wrote on Thu, Oct 27, 2011 at 16:19:54 +0200:
> Hi,
> 
> history :
> I haved a FreeBSD server (8.0-STABLE) with subversion-1.6.17_2 port.
> Acces to repository is configured thrue apache 2.2 + mod_dav + dav_svn.
> Of course, all works fine :)
> 
> I've got a new server on FreeBSD 8.2-STABLE with subversion-1.7.1,
> apache, mod_dav & dav_svn.
> All works fine ... in checkout and update.
> 
> For migration, i've make first a rsync only, when i saw the error
> (cf bottom) i've made that more cleanly with svnadmin dump and
> svnadmin load.
> In both cases, result is the same.
> 
> Now the error ^^
> 
> On my client (windows 7 x64 tortoise SVN), i CAN commit with
> Tortoise 1.6.15 on my laptop but i CAN'T commit (or rename or
> delete) on my other computer with tortoise 1.7.1.22161
> 
> The error is always the same
> 
> >Commit
> >Commit failed (details follow):
> >'/svn/site/*!svn/me*' path not found
> >
> My repository is https://xyz.coda-cola.net/svn/site/trunk
> 
> I've tried svnadmin upgrade, exactly the same.
> 
> apache debug error logs (without openSSL informations)
> 
> >[Thu Oct 27 14:58:57 2011] [info] Connection: Client IP:
> >82.226.xxx.xxx, Protocol: SSLv3, Cipher: DHE-RSA-AES256-SHA
> >(256/256 bits)
> >[Thu Oct 27 14:58:57 2011] [info] Initial (No.1) HTTPS request
> >received for child 0 (server xyz.coda-cola.net:443)
> >[Thu Oct 27 14:58:57 2011] [debug]
> >subversion/mod_authz_svn/mod_authz_svn.c(193): [client
> >82.226.xxx.xxx] Path to authz file is
> >/exports/svn/xyz/authorizations.conf
> >[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client
> >82.226.xxx.xxx] Zlib: Compressed 401 to 272 : URL /svn/site/trunk
> >[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.2) HTTPS request
> >received for child 0 (server xyz.coda-cola.net:443)
> >[Thu Oct 27 14:58:57 2011] [debug]
> >subversion/mod_authz_svn/mod_authz_svn.c(193): [client
> >82.226.xxx.xxx] Path to authz file is
> >/exports/svn/xyz/authorizations.conf
> >[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access
> >granted: 'erwane' OPTIONS site:/trunk
> >[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client
> >82.226.xxx.xxx] Zlib: Compressed 188 to 126 : URL /svn/site/trunk
> >[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.3) HTTPS request
> >received for child 0 (server xyz.coda-cola.net:443)
> >[Thu Oct 27 14:58:57 2011] [debug]
> >subversion/mod_authz_svn/mod_authz_svn.c(193): [client
> >82.226.xxx.xxx] Path to authz file is
> >/exports/svn/xyz/authorizations.conf
> >[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access
> >granted: 'erwane' POST site:
> >[Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client
> >82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL
> >/svn/site/*!svn/me*
> 
> After googled, i've found only "no space left on disk" but my ZFS
> volume is completely not full.
> 
> just tried without SSL, it's the same.
> 
> really dunno where to search now :(
> 
> Thanks for help
> 
> -- 
> Erwane Breton
>  Phea
> Tel: 09 51 20 23 23
> Mob: 06 76 46 54 61
> 

How to move a Repository and its associated folder to a new server

[Big George]

Hello,
I have two PCs:
- PC1, IP: 192.168.8.16, Windows XP
- PC2, IP: 192.168.8.40, Windows Server 2003

In PC1 I have installed:

- Subversion for Win32, version 1.6.0.

- TortoiseSVN 1.6.16 for Win32

- Folder with scripts to control versions:
D:\Scripts_DB
(This folder contains many sub-folders and text files. Those text
files are successfully controlled by Subversion. If I modify some text
file, immediately I update and commit with Tortoise)

- URL of Repository that contains D:\Scripts_DB:
svn://192.168.8.16/logs_scripts_bd/Scripts_DB

- Repository is in:
C:\Subversion\svn_Repos

In PC2 I have installed:
- VisualSVN Server 2.1.11 for Win32
- TortoiseSVN 1.6.16 for Win32
- I imported successfully Repository from PC1 to PC2
- I copied folder from \\PC1\D:\Scripts_DB to \\PC2\D:\other_path
\Scripts_DB

What I try to do is to move my Repository and folder D:\Scripts_DB
(with all its changes ) from PC1 to PC2.

Now in PC2, I have:
- Repository is in: C:\Repositories\Scripts_DB
- In VisualSVN I can see Repository: Scripts_DB
- I got folder: D:\other_path\Scripts_DB with all files and sub-folder
included

Question:
How do I configure Repository in PC2, so I can see all record changes
of my text files stored in D:\other_path\Scripts_DB, such as I do it
in PC1.

RE: Working Copy Upgrade Error

[Ayden Young]

I was able to work around this. I tried the upgrade several times and
noticed it was always failing in the same place. I deleted the
subdirectory tree one level above that from my local copy and the
upgrade was successful. The subsequent SVN Update had no problems.
Unfortunately, I couldn't isolate the problem to a single file or file
type, so can't help you with that. Luckily it was a subdirectory where I
didn't have any locked or non-committed files.

 

From: Ayden Young 
Sent: Thursday, October 27, 2011 8:03 AM
To: 'd...@subversion.apache.org'; 'users@subversion.apache.org'
Subject: Working Copy Upgrade Error

 

On Windows 7 Enterprise.

 

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

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.1\ext\subversion\subversion
\libsvn_wc\util.c'

line 300: assertion failed (svn_uri_is_canonical(repos_url, pool) &&

svn_relpath_is_canonical(path_in_repos) && SVN_IS_VALID_REVNUM(peg_rev))

---

OK   

---

 

Ayden Young I Program Manager I Trimble Hosting Services

Office: +1-480-940-6583 I Mobile: +1-480-209-4370

 

Re: How to move a Repository and its associated folder to a new server

[Ulrich Eckhardt]

Am 27.10.2011 23:56, schrieb Big George:

In PC1 I have installed:
- Subversion for Win32, version 1.6.0.
- TortoiseSVN 1.6.16 for Win32


Consider upgrading the Subversion installation to the latest 1.6, 
several bugfixes have been made there.




What I try to do is to move my Repository and folder D:\Scripts_DB
(with all its changes ) from PC1 to PC2.


There are two things involved for moving the repo:
1. Moving the repo itself
A simple file-system copy would do the job.
2. Tell your working copy
Your working copies know which repository (URL) they were checked out 
from. You need to "relocate" these to point at the new repository 
position ("svn switch --relocate ..").


The working copies themselves can be moved or copied as you like, no 
special precaution necessary, provided you stay on the same operating 
system family.


BTW: Do you have a backup strategy? Seriously, consider the case that 
PC1 was gone due to hardware failure. How do you recover from this case? 
The point is that moving the repository allows some shortcuts to make it 
quicker, but a backup allows you to restore it and the rest of your 
infrastructure from scratch.


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.
**