Re: "400 Bad Request" on commit with 1.7 client to 1.7 server

[Konstantin Kolinko]

2011/12/4 Gustavo Chaves :
> I straced the httpd daemon to try to get any hint. The last syscalls
> before the error are these:
>
> 17748 read(18, "POST /admin/!svn/me HTTP/1.1\r\nUs"..., 8000) = 441

There are known problems with handling of POST requests in 1.7.0 an 1.7.1.

In 1.7.2 changes list that is mentioned as
* make mod_dav_svn ignore non-Subversion POST requests (r1187695)

The POST request are from the new version of SVN HTTP protocol (aka
"version 2") added in 1.7.  It can be turned off in configuration,
SVNAdvertiseV2Protocol Off
http://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html

Best regards,
Konstantin Kolinko

Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Keith Williams]

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\entries.c'
line 1654: assertion failed (parent_node || entry->schedule ==
svn_wc_schedule_normal)


Keith Williams
Software Solution Services
Group Engineer| kwilli...@sauer-danfoss.com 
|ph: 763-509-2049|fax: 763-559-5769

Invalid copy source path

[Michael . Orozco]

I am working in a windows server 2003 environment. I would much rather be 
in a linux environment, but that is neither here nor there.

I have a very large repository that I am trying to seperate out into 
individual repositories. Some are small, and others large.

I have tried a lot of different options, but so far, I am having lots of 
trouble. Here is the error message I receive.

svndumpfilter: Invalid copy source path 
'/MAXIMO/releases/release-next/scripts/pre-configdb/SR04592-configdb.sql'

I created a dump file, and then I tried to seperate out the programs from 
dump file. Like so:

svndumpfilter.exe include MAXIMO --drop-empty-revs --renumber-revs 
--preserve-revprops < F:\repo_all.dmp > D:\repo_maximo.dmp

Problem I encountered is I keep getting the  Invalid copy source path 
error. I get about 6, or 7 errors.

I tried a few like:

svndumpfilter.exe exclude --drop-empty-revs --renumber-revs 
/MAXIMO/BizTalk/Final_BizTalk_Maximo_Matman "/MAXIMO/BizTalk/Splittin_in_3 
files" 
/MAXIMO/releases/archive/release-20100628/scripts/pre-configdb/SR04592-configdb.sql
 
/MAXIMO/releases/release-next/scripts/pre-configdb/SR04592-configdb.sql 
/MAXIMO/releases/release-next/scripts/revert/SR04592-revert-configdb.sql 
/MAXIMO/Aspose/License/Aspose.Total.lic < F:\repo_all.dmp > 
D:\repos\repo_exclude.dmp

It seemed to be working. But I get to 
/MAXIMO/releases/archive/release-20100628/scripts/pre-configdb/SR04592-configdb.sql
 
and I get the same error message.

I found the file, and committed it into that directory.  It was not there 
before, and gave me the same error. It doesn't give me any other infor 
except for that. Is there anything I can do for this? 

I would much rather delete that file, and just go on without it, but it 
seems subversion will not let me do that!


===
Michael Orozco
WebSphere Administrator
www.fluor.com
(864)281-6941 office
michael.oro...@fluor.com
===

The information transmitted is intended only for the person 
or entity to which it is addressed and may contain 
proprietary, business-confidential and/or privileged material.  
If you are not the intended recipient of this message you are 
hereby notified that any use, review, retransmission, dissemination, 
distribution, reproduction or any action taken in reliance upon 
this message is prohibited. If you received this in error, please 
contact the sender and delete the material from any computer.  

Any views expressed in this message are those of the individual 
sender and may not necessarily reflect the views of the company.  

invalid option character

[Tam]

Hi-

I have SVN Visual Server and have created a post-commit hook:

"C:\Program Files\VisualSVN Server\bin\svn.exe" update --C:\webcontent
\xx\xx -username xxx--password xxx

The hook never seemed to execute, so I tried running it on the command
line, but I get this error:

svn.exe: invalid option character: s

I've checked the svn help and am not sure where this option "s" is
coming from...

Running on WindowsSBS 2003

Any help is appreciated...

T.

Re: Issue with upgrade/server move to 1.7.1

[Justin Finkelstein]

Yeah; I'd posted this just before we spoke.

Thanks again!

On Sun, 2011-12-04 at 22:40 +0200, Daniel Shahaf wrote:

> Fixed on #svn, right?
> 
> Justin Finkelstein wrote on Sun, Dec 04, 2011 at 16:24:30 +:
> > Hi guys
> > 
> > Today I've moved my SVN repository from 1.5.1 to 1.7.1, located on a new
> > server. Having done this, I've upgraded the repositories served and am
> > getting an odd error when testing.
> > 
> > On the server, I'm running: 
> > 
> > svnserve -d -r /home/svn --foreground --listen-port 3690
> > 
> > When I try to check out or commit on one of my clients:
> > 
> > svn co svn://toejamfootball/redwire/templates
> > svn: Network connection closed unexpectedly
> > 
> > On the server, I'm seeing the following: 
> > 
> > svnserve: subversion/libsvn_subr/dirent_uri.c:956: svn_dirent_join:
> > Assertion `svn_dirent_is_canonical(component, pool)' failed.
> > 
> > I've had a look through previous mailing list posts, tried two different
> > versions of subversion for my target OS (CentOS 6) and have found no
> > solution or clues on how to address this.
> > 
> > Any thoughts? This is a bit of a 'blocking' issue and, in my mind, needs
> > to be posted to the bugs database.
> > 
> > Thanks,
> > 
> > Justin
> > 
> > -- 
> > Redwire Design Limited
> >  
> > 54 Maltings Place
> > 169 Tower Bridge Road
> > London SE1 3LJ
> > www.redwiredesign.com
> > 


-- 
Redwire Design Limited
 
54 Maltings Place
169 Tower Bridge Road
London SE1 3LJ
www.redwiredesign.com
 
[ 020 7403 1444 ] - voice
[ 020 7378 8711 ] - fax
[ 07968 180 720 ] - mobile

svn_client_revert2 skips files for no obvious reasons

[Roman Kellner]

Hi

We are implementing a wrapper around a SCC-SVN client in order to over come 
some flaws between the IDE and the SCC-SVN client.

Now we need to use the svn_client_revert2 function in order to revert 
scheduled actions (add, delete) when the commit fails due to the commit 
hock.

Order: 
WrapperSccRename() 
-> rtn = SccSvnClientSccRename() 
--> rtn != OK : svn_client_revert2() with the same files passed to 
SccRenameSccSvnClient() 
return from WrapperSccRename() 
 
When using the 

* svn_client_revert2  (    const 
apr_array_header_t * paths,
svn_depth_t depth, 
   const apr_array_header_t * changelists, 
   svn_client_ctx_t *  
   ctx,apr_pool_t 
* pool

function it skips the files given in paths. The function thinks the files 
are not under version control (notify says -> skip file).

The filenames from the IDE are somewhat unusual/weird: e.g. 
@p...@programunitname.zip
  
  On the command line we had to add the extra @ to prevent half of the 
filename be eaten as PEG revision. But with the extra @ reverting from the 
command line or with TortoiseSVN works well.
Also if instead of the files in paths the directory where the files are 
located is passed, then svn_client_revert2() does the job.
But reverting the whole directory is not what we need and want.

What can be the cause?
How comes the directory works with svn_client_revert2() and svn revert and 
TortoiseSVN too but not the files?

The behaviour hints to the filenames, which are odd but did not cause a 
problem so far. Or do we have to somehow refresh/reload the wc_admin area 
to recognize the changes done by the SCC-SVN client, since both run in the 
same program/thread?

Did anyone have the same or a similar issue and knows how to solve it?

Thanks

Roman

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Re: invalid option character

[Ulrich Eckhardt]

Am 01.12.2011 21:12, schrieb Tam:

I have SVN Visual Server and have created a post-commit hook:

"C:\Program Files\VisualSVN Server\bin\svn.exe" update --C:\webcontent
\xx\xx -username xxx--password xxx

The hook never seemed to execute, so I tried running it on the command
line, but I get this error:

svn.exe: invalid option character: s


Try removing stuff until it works in order to find out what exactly 
caused it to go wrong. I guess that the "s" option given to "-u" as 
parameter, and that is not understood. Of course you meant "--username" 
and not "-username". Also you will probably have SVN complain about an 
unknown "--C:", the path with the working copy isn't supposed to follow 
two dashes, similarly to "update".


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

Subversion update error

[Johan Kruger]

Hello,

I got this error message while doing an update using TortoiseSVN. The 
folder being updated was using the new WC format.
Here is the version information from the TortoiseSVN about dialog:
TortoiseSVN 1.7.1, Build 22161 - 64 Bit , 2011/10/21 22:51:59
Subversion 1.7.1, 
apr 1.4.5
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.0e 6 Sep 2011
zlib 1.2.5

The Subversion server version is: 1.6.12 (r955767)


The error message:

---
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\wc_db.c'
 line 2881: assertion failed (svn_dirent_is_ancestor(wcroot->abspath,
 local_abspath))
---
OK 
---

Regards
Johan

Re: Invalid copy source path

[Stefan Sperling]

On Thu, Dec 01, 2011 at 01:38:14PM -0500, michael.oro...@fluor.com wrote:
> I am working in a windows server 2003 environment. I would much rather be 
> in a linux environment, but that is neither here nor there.
> 
> I have a very large repository that I am trying to seperate out into 
> individual repositories. Some are small, and others large.
> 
> I have tried a lot of different options, but so far, I am having lots of 
> trouble. Here is the error message I receive.
> 
> svndumpfilter: Invalid copy source path 
> '/MAXIMO/releases/release-next/scripts/pre-configdb/SR04592-configdb.sql'
> 
> I created a dump file, and then I tried to seperate out the programs from 
> dump file. Like so:
> 
> svndumpfilter.exe include MAXIMO --drop-empty-revs --renumber-revs 
> --preserve-revprops < F:\repo_all.dmp > D:\repo_maximo.dmp
> 
> Problem I encountered is I keep getting the  Invalid copy source path 
> error. I get about 6, or 7 errors.
> 
> I tried a few like:
> 
> svndumpfilter.exe exclude --drop-empty-revs --renumber-revs 
> /MAXIMO/BizTalk/Final_BizTalk_Maximo_Matman "/MAXIMO/BizTalk/Splittin_in_3 
> files" 
> /MAXIMO/releases/archive/release-20100628/scripts/pre-configdb/SR04592-configdb.sql
>  
> /MAXIMO/releases/release-next/scripts/pre-configdb/SR04592-configdb.sql 
> /MAXIMO/releases/release-next/scripts/revert/SR04592-revert-configdb.sql 
> /MAXIMO/Aspose/License/Aspose.Total.lic < F:\repo_all.dmp > 
> D:\repos\repo_exclude.dmp
> 
> It seemed to be working. But I get to 
> /MAXIMO/releases/archive/release-20100628/scripts/pre-configdb/SR04592-configdb.sql
>  
> and I get the same error message.
> 
> I found the file, and committed it into that directory.  It was not there 
> before, and gave me the same error. It doesn't give me any other infor 
> except for that. Is there anything I can do for this? 
> 
> I would much rather delete that file, and just go on without it, but it 
> seems subversion will not let me do that!

You have to include copy sources of files you want to keep.
The reason is that it is often impossible to reconstruct the file
content without access to the copy sources. Deltified content stored in
the revision where the file was copied can refer to content of the file
in the older revision at its pre-copy location.

There is a script that can provide a list of all files you need:
https://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svnpredumpfilter.py

Re: svn_client_revert2 skips files for no obvious reasons

[Stefan Sperling]

On Mon, Dec 05, 2011 at 09:59:44AM +0100, Roman Kellner wrote:
> Hi
> 
> We are implementing a wrapper around a SCC-SVN client in order to over come 
> some flaws between the IDE and the SCC-SVN client.
> 
> Now we need to use the svn_client_revert2 function in order to revert 
> scheduled actions (add, delete) when the commit fails due to the commit 
> hock.
> 
> Order: 
> WrapperSccRename() 
> -> rtn = SccSvnClientSccRename() 
> --> rtn != OK : svn_client_revert2() with the same files passed to 
> SccRenameSccSvnClient() 
> return from WrapperSccRename() 
>  
> When using the 
> 
> * svn_client_revert2  (    const 
> apr_array_header_t * paths,
> svn_depth_t depth, 
>const apr_array_header_t * changelists, 
>svn_client_ctx_t *  
>ctx,apr_pool_t 
> * pool
> 
> function it skips the files given in paths. The function thinks the files 
> are not under version control (notify says -> skip file).
> 
> The filenames from the IDE are somewhat unusual/weird: e.g. 
> @p...@programunitname.zip
>   
>   On the command line we had to add the extra @ to prevent half of the 
> filename be eaten as PEG revision. But with the extra @ reverting from the 
> command line or with TortoiseSVN works well.
> Also if instead of the files in paths the directory where the files are 
> located is passed, then svn_client_revert2() does the job.
> But reverting the whole directory is not what we need and want.

What paths are you actually passing in the 'paths' array?
Are you passing absolute paths? Are you canonicalising the paths properly?

The @ syntax parsing is done by the 'svn' client before it calls into
the client library. So you should not append '@' to the filenames passed
to svn_client_revert2().

> What can be the cause?
> How comes the directory works with svn_client_revert2() and svn revert and 
> TortoiseSVN too but not the files?

Have you taken a look at how the command line client handles its arguments
and what it passes to svn_client_revert2()?
See 
https://svn.apache.org/repos/asf/subversion/trunk/subversion/svn/revert-cmd.c
and the functions it calls.

Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Philip Martin]

Keith Williams  writes:

> 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\entries.c'
> line 1654: assertion failed (parent_node || entry->schedule ==
> svn_wc_schedule_normal)

That looks like one we haven't seen before.  I think this occurred
during an upgrade, so the working copy should still be in the 1.6
format.  If we are to do anything with this report then we need to know
what is special/different about this working copy.

How old is the working copy?  What does 'svn status' show?  What local
changes do you have?  Any added/deleted nodes?  Switched nodes?  Mixed
revisions?  Is it a sparse working copy?  Any svn:externals, file or
directory?  Do you make commits from this working copy?  Is it nested
inside another working copy?

-- 
Philip

Re: "400 Bad Request" on commit with 1.7 client to 1.7 server

[Gustavo Chaves]

On 5 dez, 05:59, Konstantin Kolinko  wrote:
> 2011/12/4 Gustavo Chaves :
>
> There are known problems with handling of POST requests in 1.7.0 an 1.7.1.
>
> In 1.7.2 changes list that is mentioned as
> * make mod_dav_svn ignore non-Subversion POST requests (r1187695)
>
> The POST request are from the new version of SVN HTTP protocol (aka
> "version 2") added in 1.7.  It can be turned off in configuration,
> SVNAdvertiseV2Protocol 
> Offhttp://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html

That solved the problem. Thank you!

However, I understand that by turning that option Off I'm telling
apache to use the old HTTP protocol, giving up on the new one that is
much more performant, right? Without the new protocol I'll not be able
to move everyone from svnserve to HTTP as I'd like to do.

Regarding the 1.7.2 release, I understand that it should appear
shortly. However, what I get from the changelog working (make
mod_dav_svn ignore non-Subversion POST requests) is that the server
would ignore POST requests from non-Subversion clients. But I'm doing
commits with the CollabNet's svn command version 1.7.1, not from any
browser or other client. Shouldn't those POSTS be regarded as
Subversion ones and not be ignored?

Thanks again.

--
Gustavo.

Re: "400 Bad Request" on commit with 1.7 client to 1.7 server

[Philip Martin]

Gustavo Chaves  writes:

> However, I understand that by turning that option Off I'm telling
> apache to use the old HTTP protocol, giving up on the new one that is
> much more performant, right?

Yes.

> Regarding the 1.7.2 release, I understand that it should appear
> shortly. However, what I get from the changelog working (make
> mod_dav_svn ignore non-Subversion POST requests) is that the server
> would ignore POST requests from non-Subversion clients. But I'm doing
> commits with the CollabNet's svn command version 1.7.1, not from any
> browser or other client. Shouldn't those POSTS be regarded as
> Subversion ones and not be ignored?

Yes.  The strace you posted showed the POST reaching the mod_dav_svn
Apache module.

1.7.1 has a bug that Subversion attempts to handle *all* POST requests,
including those not targeted at Subversion repositories, and when it
receives a non-Subversion POST request it returns an error that prevents
non-Subversion processing.  This bug is fixed in 1.7.2.

Your problem with POST requests is not yet understood.  It's might be
some overlap between Subversion directives in your apache config, or
between Subversion directives and non-Subversion directives.   Only you
can really identify the problem at present, unless you post enough
information for somebody else to reproduce the problem.

One way to track down the problem is start with a small Apache config
file that works and gradually expand it until it stops working.  Or to
gradually strip down the non-working file until it works.

-- 
Philip

Subversion Exception!

[Srinivas Jagarapu]

Hi,
Here is the error message.

---
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\wc_db.c'
line 5830: assertion failed (*local_relpath != '\0')
---
OK
---

Thanks,
Srinivas Jagarapu

Re: Subversion update error

[Philip Martin]

Johan Kruger  writes:

> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\subversion\libsvn_wc\wc_db.c'
>  line 2881: assertion failed (svn_dirent_is_ancestor(wcroot->abspath,
>  local_abspath))

It appears to be an error adding an svn:externals dir but you have not
provided enough information for us to help.  What were you doing when
this error occurred?  What sort of svn:externals do you have?

-- 
Philip

Re: Subversion Exception!

[Ulrich Eckhardt]

Am 05.12.2011 12:14, schrieb Srinivas Jagarapu:

with as much information as possible about what you were trying to do.


Please provide this info, otherwise your report is impossible to 
reproduce and therefore useless.



But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.


You already did that and this particular error was not yet reported 
here, right?



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

RE: Subversion Exception!

[Srinivas Jagarapu]

Hi,

I checked but I didn't find.

This was coming while when I do check out from repository.

Thanks,
Srinivas J.

-Original Message-
From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] 
Sent: Monday, December 05, 2011 4:59 PM
To: users@subversion.apache.org
Subject: Re: Subversion Exception!

Am 05.12.2011 12:14, schrieb Srinivas Jagarapu:
> with as much information as possible about what you were trying to do.

Please provide this info, otherwise your report is impossible to reproduce and 
therefore useless.

> But please first search the mailing list archives for the error 
> message to avoid reporting the same problem repeatedly.

You already did that and this particular error was not yet reported here, right?


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



Click the following link to report this email as spam:  
https://www.mailcontrol.com/sr/BTNa7iGgAOvTndxI!oX7Uiu2ltSO29L0pqMpmtMmfSO5lPcsEXqjsSBxjAcRHBf7TTBbJCW1sDUakVWf!6zCig==
  

Re: "400 Bad Request" on commit with 1.7 client to 1.7 server

[Gustavo Chaves]

On 5 dez, 09:13, Philip Martin  wrote:
> Your problem with POST requests is not yet understood.  It's might be
> some overlap between Subversion directives in your apache config, or
> between Subversion directives and non-Subversion directives.   Only you
> can really identify the problem at present, unless you post enough
> information for somebody else to reproduce the problem.

Thank you, Philip, for confirming my suspicions.

I'll follow your advice and try to strip down my configuration until
it starts working. I'll post here my results as I get them.

--
Gustavo.

Re: Subversion Exception!

[Ulrich Eckhardt]

Am 05.12.2011 12:56, schrieb Srinivas Jagarapu:

This was coming while when I do check out from repository.


Okay. Since this is a fundamental operation, you can be pretty sure that 
this alone is not the cause of the problem, please reconsider the "with 
as much information as possible". In particular:


1. Does it always happen?
2. What is the local path you are checking out to?
3. What is the remote path you are checking out from?
4. What is the access method used?
5. Does it happen on all remote or local paths?
6. If only on some paths, what is special about them?
...

Also, please don't top-post on this mailinglist.

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

Re: Subversion Exception!

[Philip Martin]

Ulrich Eckhardt  writes:

> Am 05.12.2011 12:56, schrieb Srinivas Jagarapu:
>> This was coming while when I do check out from repository.
>
> Okay. Since this is a fundamental operation, you can be pretty sure
> that this alone is not the cause of the problem, please reconsider the
> "with as much information as possible". In particular:
>
> 1. Does it always happen?
> 2. What is the local path you are checking out to?
> 3. What is the remote path you are checking out from?
> 4. What is the access method used?
> 5. Does it happen on all remote or local paths?
> 6. If only on some paths, what is special about them?
> ...

The error occurs in remove_node_txn() which isn't called during a simple
checkout.  Perhaps this is a checkout on top of an existing working copy
at an earlier revision?  Perhaps the checkouts have different depths?
Perhaps the old working copy was an upgraded working copy?

-- 
Philip

Re: assert triggered in update_editor.c

[Ivo Schenk]

Erik Faye-Lund  gmail.com> writes:


> In file
> 
'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\...
>  line 1582: ...
> ---


Same with SVN 1.7.1 (Tortoise 1.7.1 or Subclipse 1.8.0)


Updating '.':
svn: E235000: In file 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\
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)


This assert can be triggered triggered, when in a directory 
one file is deleted,
one file is added 
and a SymLink changes:

before:

libXXX.so.1.2.3
libXXX.so -> Symlink to libXXX.so.1.2.3

after:

libXXX.so.5.6.7
libXXX.so -> Symlink to libXXX.so.5.6.7

That changeset was commited with a SVN 1.6.17 client and can also be 
updated with that version, but V1.7.x clients assert there.

Hope that helps,

Ivo

Re: invalid option character

[Andy Levy]

On Thu, Dec 1, 2011 at 15:12, Tam  wrote:
> Hi-
>
> I have SVN Visual Server and have created a post-commit hook:
>
> "C:\Program Files\VisualSVN Server\bin\svn.exe" update --C:\webcontent
> \xx\xx -username xxx--password xxx
>
> The hook never seemed to execute, so I tried running it on the command
> line, but I get this error:
>
> svn.exe: invalid option character: s
>
> I've checked the svn help and am not sure where this option "s" is
> coming from...

You've specified -username. It needs to be --username (note two
dashes, not one). Typically a single dash indicates a single-character
option, so it's reading "-u" and then not expecting the "s".

Re: assert triggered in update_editor.c

[Philip Martin]

Ivo Schenk  writes:

> Erik Faye-Lund  gmail.com> writes:
>
>
>> In file
>> 
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7-beta2\ext\...
>>  line 1582: ...
>> ---
>
>
> Same with SVN 1.7.1 (Tortoise 1.7.1 or Subclipse 1.8.0)
>
>
> Updating '.':
> svn: E235000: In file 
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.1\ext\subversion\
> 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)
>
>
> This assert can be triggered triggered, when in a directory 
> one file is deleted,
> one file is added 
> and a SymLink changes:

Fixed in 1.7.2:


r1203778 | hwright | 2011-11-18 18:12:30 + (Fri, 18 Nov 2011) | 14 lines

Merge r1186944, r1186981, r1186983, r1187676 from trunk:

 * r1186944, r1186981, r1186983, r1187676
   Fix an assertion failure when a symlink is updated.


-- 
Philip

Unexpected files in folder repository\db\...

[Martin Bischoff]

While backing up our repository and preparing to update to subversion 1.7.x
I found some files inside the folder
"c:\svn_repository\{repository_name}\db" which made me wonder whether we
have a problem with our repository:

- In "db\transactions" I see a folder named "9279-7lb.txn" containing
  various files (changes, next-ids, several node.x files, props).
- Also in folder db\txn-protorevs there are two files named
  "9279-7lb.rev" and "9279-7lb.rev-lock".
- After looking at the "changes" and "props" files, and searching in
  the repository, it seems that this change was successfully
  commited to the repository as revision number 9280.
- There was no other commit at or around the same time.

- Also in "db\locks" I found 639 directories, but currently there are
  only 17 locks in the repository.
- Some of these directories are very old, so are probably from locks
  which were released a long time ago.


-> is it expected that such transaction and locks files and folders remain
in the db folder or is this an indication that there is a problem?


I'm using subversion 1.6.16 (svnserve.exe) on a windows server.
Running "svnadmin verify" did not report any problems.
On the client we are using TortoiseSVN, based on SVN 1.6.16.

Thanks for your help.

-Martin

Re: svn_client_revert2 skips files for no obvious reasons

[Roman Kellner]

>  Original-Nachricht 
> Datum: Mon, 5 Dec 2011 11:38:12 +0100
> Von: Stefan Sperling 
> An: Roman Kellner 
> CC: users@subversion.apache.org
> Betreff: Re: svn_client_revert2 skips files for no obvious reasons
> 
> On Mon, Dec 05, 2011 at 09:59:44AM +0100, Roman Kellner 
> wrote:
> > Hi
> > 
> > We are implementing a wrapper around a SCC-SVN client in order to over 
> come 
> > some flaws between the IDE and the SCC-SVN client.
> > 
> > Now we need to use the svn_client_revert2 function in order to revert 
> > scheduled actions (add, delete) when the commit fails due to the commit 
> > hock.
> > 
> > Order: 
> > WrapperSccRename() 
> > -> rtn = SccSvnClientSccRename() 
> > --> rtn != OK : svn_client_revert2() with the same files passed to 
> > SccRenameSccSvnClient() 
> > return from WrapperSccRename() 
> >  
> > When using the 
> > 
> > * svn_client_revert2  (    const 
> > apr_array_header_t * paths,
> 
> > svn_depth_t depth, 
> 
> >const apr_array_header_t * 
> changelists, 
> >svn_client_ctx_t *  
> 
> >ctx,
> apr_pool_t 
> > * pool
> > 
> > function it skips the files given in paths. The function thinks the 
> files 
> > are not under version control (notify says -> skip file).
> > 
> > The filenames from the IDE are somewhat unusual/weird: e.g. 
> > @p...@programunitname.zip
> >   
> >   On the command line we had to add the extra @ to prevent half of the 
> > filename be eaten as PEG revision. But with the extra @ reverting from 
> the 
> > command line or with TortoiseSVN works well.
> > Also if instead of the files in paths the directory where the files are 
> > located is passed, then svn_client_revert2() does the job.
> > But reverting the whole directory is not what we need and want.
> 
> What paths are you actually passing in the 'paths' array?

D:\NewFolder\iec61131\ProjectName\SCC\@p...@originalfilename.zip
D:\NewFolder\iec61131\ProjectName\SCC\@p...@originalfilenamerenamed.zip

> 
> Are you passing absolute paths? 

Yes.

> Are you canonicalising the paths properly?

We are not doing extra things to the paths, but I would guess that the path 
as above already is canonicalized. Wrong?

> 
> 
> The @ syntax parsing is done by the 'svn' client before it calls into
> the client library. So you should not append '@' to the filenames passed
> to svn_client_revert2().
> 
> > What can be the cause?
> > How comes the directory works with svn_client_revert2() and svn revert 
> and 
> > TortoiseSVN too but not the files?
> 
> Have you taken a look at how the command line client handles its 
> arguments
> and what it passes to svn_client_revert2()?
> See 
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/svn/revert-cmd.c
> and the functions it calls.
We had a look and could not recognize anything spezial that we could have 
forgotten (v.1.6.17). Now with 1.7.1 the new check function 
 SVN_ERR(svn_cl__check_targets_are_local_paths(targets));

has been added. The function basically check that it is not a URL, what I 
can tell from the code.

Thanks for the hints.

Roman
> 
> 

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

RE: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Keith Williams]

In examining the Working Copy more closely, the Folder Structure is partially 
in 1.6 format and partially is 1.7 format. I am making this assumption by the 
presence of the .svn folder in some top level folders but not in others. A 
couple of files were deleted at the repository level prior to the attempt to 
convert the Working Copy to the 1.7 format. Since the Working Copy is on a 
network drive someone probably updated a subfolder to 1.7 before the full 
working folder was attempted to be converted which was when the failure and 
report below occurred. There are no externals associated with this Project 
Repository. I am not aware of any changes to nodes. We do make commits from 
this working copy but would not be able to do so following the upgrade of the 
SVN Server to 1.7 until after the upgrade of the working copy to the 1.7 
Format. 

Keith

-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com] 
Sent: Monday, December 05, 2011 4:58 AM
To: Keith Williams
Cc: users@subversion.apache.org
Subject: Re: Attmpting to Update Working Directory for a Project from V1.6.17 
to V1.7.1 using SVN Upgrade working copy

Keith Williams  writes:

> 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\entries.c'
> line 1654: assertion failed (parent_node || entry->schedule ==
> svn_wc_schedule_normal)

That looks like one we haven't seen before.  I think this occurred during an 
upgrade, so the working copy should still be in the 1.6 format.  If we are to 
do anything with this report then we need to know what is special/different 
about this working copy.


How old is the working copy?  What does 'svn status' show?  What local changes 
do you have?  Any added/deleted nodes?  Switched nodes?  Mixed revisions?  Is 
it a sparse working copy?  Any svn:externals, file or directory?  Do you make 
commits from this working copy?  Is it nested inside another working copy?

--
Philip

Re: svn_client_revert2 skips files for no obvious reasons

[Stefan Sperling]

On Mon, Dec 05, 2011 at 04:23:10PM +0100, Roman Kellner wrote:
> > What paths are you actually passing in the 'paths' array?
> 
> D:\NewFolder\iec61131\ProjectName\SCC\@p...@originalfilename.zip
> D:\NewFolder\iec61131\ProjectName\SCC\@p...@originalfilenamerenamed.zip
> 
> > 
> > Are you passing absolute paths? 
> 
> Yes.
> 
> > Are you canonicalising the paths properly?
> 
> We are not doing extra things to the paths, but I would guess that the path 
> as above already is canonicalized. Wrong?

The paths are not canonical. Subversion always uses forward slashes
internally. Run the paths through svn_dirent_internal_style() and it
should work. This function will replace backslashes with forward slashes
and also canonicalise the paths.

Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Philip Martin]

Keith Williams  writes:

> In examining the Working Copy more closely, the Folder Structure is
> partially in 1.6 format and partially is 1.7 format. I am making this
> assumption by the presence of the .svn folder in some top level
> folders but not in others. A couple of files were deleted at the
> repository level prior to the attempt to convert the Working Copy to
> the 1.7 format. Since the Working Copy is on a network drive someone
> probably updated a subfolder to 1.7 before the full working folder was
> attempted to be converted which was when the failure and report below
> occurred.

A 1.7 working copy will have a .svn/wc.db file in the root of the
working copy.  A 1.6 working copy will have a .svn/entries file in every
versioned folder.

It's not possible to upgrade a subfolder, only an entire working copy
can be upgraded.  The upgrade process writes all the 1.7 .svn data, for
all subfolders, into a temporary location before deleting any of the 1.6
data.  The final step of the upgrade is to move the new 1.7 .svn data
into place and to remove the old 1.6 .svn data.

The error message you showed happens while writing the 1.7 .svn data, so
it happens before any of the 1.6 .svn data has been deleted from the
subfolders.  If you have versioned subfolders that are missing .svn
folders it is likely that something other than the upgrade was
responsible.

> There are no externals associated with this Project
> Repository. I am not aware of any changes to nodes. We do make commits
> from this working copy but would not be able to do so following the
> upgrade of the SVN Server to 1.7 until after the upgrade of the
> working copy to the 1.7 Format.

A 1.7 server supports earlier clients and doesn't care about the working
copy format.  If you are unable to use the working copy it's because you
upgraded the client, not the server.

-- 
Philip

RE: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Cooke, Mark]

> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com] 
> Sent: 05 December 2011 16:25
> To: Keith Williams
> Cc: users@subversion.apache.org
> Subject: Re: Attmpting to Update Working Directory for a 
> Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy
> 
> Keith Williams  writes:
> 
> > In examining the Working Copy more closely, the Folder Structure is
> > partially in 1.6 format and partially is 1.7 format. I am 
> making this
> > assumption by the presence of the .svn folder in some top level
> > folders but not in others. A couple of files were deleted at the
> > repository level prior to the attempt to convert the Working Copy to
> > the 1.7 format. Since the Working Copy is on a network drive someone
> > probably updated a subfolder to 1.7 before the full working 
> folder was
> > attempted to be converted which was when the failure and 
> report below
> > occurred.
> 
> A 1.7 working copy will have a .svn/wc.db file in the root of the
> working copy.  A 1.6 working copy will have a .svn/entries 
> file in every versioned folder.
> 
> It's not possible to upgrade a subfolder, only an entire working copy
> can be upgraded.  The upgrade process writes all the 1.7 .svn 
> data, for all subfolders, into a temporary location before deleting
> any of the 1.6 data.  The final step of the upgrade is to move the
> new 1.7 .svn data into place and to remove the old 1.6 .svn data.

My reading of the OP was that someone had probably seleected a sub-folder for 
conversion and that may well have succeeded.  Seeing as you can take a 1.6 
sub-folder and effectively make it a top-level folder, this makes sense to me?  
Or does the upgrade code crawl upwards to see if folders above are versioned?

The error then happened when someone tried to convert the real root folder, 
where one of the subfolders was already converted...

~ mark c

> The error message you showed happens while writing the 1.7 
> .svn data, so
> it happens before any of the 1.6 .svn data has been deleted from the
> subfolders.  If you have versioned subfolders that are missing .svn
> folders it is likely that something other than the upgrade was
> responsible.
> 
> > There are no externals associated with this Project
> > Repository. I am not aware of any changes to nodes. We do 
> make commits
> > from this working copy but would not be able to do so following the
> > upgrade of the SVN Server to 1.7 until after the upgrade of the
> > working copy to the 1.7 Format.
> 
> A 1.7 server supports earlier clients and doesn't care about 
> the working
> copy format.  If you are unable to use the working copy it's 
> because you
> upgraded the client, not the server.
> 
> -- 
> Philip
> 

Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Philip Martin]

"Cooke, Mark"  writes:

> My reading of the OP was that someone had probably seleected a
> sub-folder for conversion and that may well have succeeded.  Seeing as
> you can take a 1.6 sub-folder and effectively make it a top-level
> folder, this makes sense to me?  Or does the upgrade code crawl
> upwards to see if folders above are versioned?

The upgrade code checks the parent folder.  If one were to bypass this
check, by moving the 1.6 subfolder out of the 1.6 working copy, then it
would be possible to upgrade the subfolder.  However such an upgraded
subfolder would be a complete 1.7 working copy.  Moving it back into the
1.6 working copy won't work as the upgraded subfolder is now an entirely
separate working copy.

-- 
Philip

Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[pjaytycy]

Maybe this can happen in this specific situation if somebody uses "map 
network path" to a drive letter on windows.
If the real root of the WC is \\someserver\\some\path\to\wc\root
I can probably still map a drive letter (ie V: to 
\\someserver\some\path\to\wc\root\sub\folder\for\my\project
If I then use SVN 1.7 upgrade on that, SVN will not be able to see that I 
only have part of the working copy.

Apache Subversion 1.7.2 Released

[Hyrum Wright]

I'm happy to announce the release of Apache Subversion 1.7.2.
Please choose the mirror closest to you by visiting:

    http://subversion.apache.org/download/#recommended-release

The SHA1 checksums are:

    8c0824aeb7f42da1ff4f7cd296877af7f59812bb subversion-1.7.2.tar.bz2
    c485b72b316c3bd08e29fe0e73c5cc537f871cf8 subversion-1.7.2.tar.gz
    c51b7db58adc68178e0702b7b3c5da817bfd91d3 subversion-1.7.2.zip

PGP Signatures are available at:

    http://www.apache.org/dist/subversion/subversion-1.7.2.tar.bz2.asc
    http://www.apache.org/dist/subversion/subversion-1.7.2.tar.gz.asc
    http://www.apache.org/dist/subversion/subversion-1.7.2.zip.asc

For this release, the following people have provided PGP signatures:

   Philip Martin [2048R/ED1A599C] with fingerprint:
    A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Paul T. Burba [1024D/53FCDC55] with fingerprint:
    E630 CF54 792C F913 B13C  32C5 D916 8930 53FC DC55
   Bert Huijben [1024D/9821F7B2] with fingerprint:
    2017 F51A 2572 0E78 8827  5329 FCFD 6305 9821 F7B2
   Hyrum K. Wright [1024D/4E24517C] with fingerprint:
    3324 80DA 0F8C A37D AEE6  D084 0B03 AE6E 4E24 517C
   C. Michael Pilato [1024D/1706FD6E] with fingerprint:
    20BF 14DC F02F 2730 7EA4  C7BB A241 06A9 1706 FD6E
   Stefan Sperling [1024D/F59D25F0] with fingerprint:
    B1CF 1060 A1E9 34D1 9E86  D6D6 E5D3 0273 F59D 25F0
   Mark Phippard [1024D/035A96A9] with fingerprint:
    D315 89DB E1C1 E9BA D218  39FD 265D F8A0 035A 96A9

Release notes for the 1.7.x release series may be found at:

    http://subversion.apache.org/docs/release-notes/1.7.html

You can find the list of changes between 1.7.2 and earlier versions at:

    http://svn.apache.org/repos/asf/subversion/tags/1.7.2/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team

Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy

[Johan Corveleyn]

On Mon, Dec 5, 2011 at 5:51 PM, Philip Martin
 wrote:
> "Cooke, Mark"  writes:
>
>> My reading of the OP was that someone had probably seleected a
>> sub-folder for conversion and that may well have succeeded.  Seeing as
>> you can take a 1.6 sub-folder and effectively make it a top-level
>> folder, this makes sense to me?  Or does the upgrade code crawl
>> upwards to see if folders above are versioned?
>
> The upgrade code checks the parent folder.  If one were to bypass this
> check, by moving the 1.6 subfolder out of the 1.6 working copy, then it
> would be possible to upgrade the subfolder.  However such an upgraded
> subfolder would be a complete 1.7 working copy.  Moving it back into the
> 1.6 working copy won't work as the upgraded subfolder is now an entirely
> separate working copy.

Does it only check the parent folder, or does it travel upward until
the drive root?

Just wondering what happens with an external dir which is inside an
unversioned directory. If you run upgrade from there, will it go
upwards beyond the unversioned dir, to find that it's part of a larger
working copy?

Anyway, that's a total edge case (and probably not the problem of the
OP), but I'm just wondering.

-- 
Johan

Re: Unexpected files in folder repository\db\...

[Ryan Schmidt]

On Dec 5, 2011, at 08:32, Martin Bischoff wrote:

> -> is it expected that such transaction and locks files and folders remain in 
> the db folder or is this an indication that there is a problem?


Dead transactions can occur:

http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deadtxns

Dead locks, not sure how that happened but you can probably use rmlocks to get 
rid of them.

Re: Unexpected files in folder repository\db\...

[Daniel Shahaf]

Ryan Schmidt wrote on Mon, Dec 05, 2011 at 14:33:18 -0600:
> On Dec 5, 2011, at 08:32, Martin Bischoff wrote:
> 
> > -> is it expected that such transaction and locks files and folders remain 
> > in the db folder or is this an indication that there is a problem?
> 
> 
> Dead transactions can occur:
> 
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deadtxns
> 
> Dead locks, not sure how that happened but you can probably use
> rmlocks to get rid of them.

Assuming FSFS.

db/locks/ contains a directory per *path component* in the locked file
(eg, three entries for /trunk/README).  Likely, once created, those dirs
are only emptied, not removed (see subversion/libsvn_fs_fs/lock.c).
Therefore, an 'svn lock; svn unlock;' cycle would leave a few dirs
behind.

It's safe to remove empty dirs whilst no 'svn lock' operating is
running, or while holding an appropriate write lock.

> 

TortoiseSVN Exception

[Michael_Abraham]

I get the assertion below when I do TortoiseSVN\Check for modifications on 
a WC that contains a folder with file externals.  I have no conclusive 
proof that the file externals are the cause of the problem, but the fact 
that  the assertion deals with mis-matched repo id's strongly suggests 
that the externals are the problem).  I have many other WC's that use 
externals (but not file externals) that are working w/no issues.

Right-clicking on the folder with the file externals kills Windows 
Explorer.

Here are the externals properties

http://cam-source01/svn/IR/SSRSShared/SSRSShared/Common.BusinessUnits.rsd 
Common.BusinessUnits.rsd
http://cam-source01/svn/IR/SSRSShared/SSRSShared/Common.Regions.rsd 
Common.Regions.rsd

I'm running Windows 7, SP1, 32-bit on the client, and VisualSVN 2.5.1 on 
Windows 2003, SP2 as the server.

I know this isn't a very good (or even a very mediocre) bug report, but 
I'm under a brutal deadline and don't have any cycles to spare.

Mike Abraham

---
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\wc_db.c'
 line 6837: assertion failed (repos_id == last_repos_id)
---
OK 
---




---

This message contains information that may be confidential and 
proprietary. Unless you are the intended recipient (or authorized to 
receive this message for the intended recipient), you may not use, copy, 
disseminate or disclose to anyone the message or any information contained 
in the message. If you have received the message in error, please advise 
the sender by reply e-mail, and delete the message immediately. Thank you 
very much.