Re: svn command line client 1.8.8 - Error: file name or extension is too long

2014-09-16 Thread Branko Čibej
On 16.09.2014 08:53, milan_plan...@swissre.com wrote:
> Dear all,
>
> I am running Windows 7 Enterprise 64-bit  (6.1, build 7601), also I
> should note, that I used IDE Intellij Idea 13.1.3 to commit changes (
> Not sure, whether the IDE influences this issue in this case). I do
> not know how to get the generated command from Intellij, also I
> already commited the files and therefore can not reproduce the issue
> in exactly same way.

IDEA 13.x uses a custom wrapper around the svn command-line client to do
version control. Depending on how they do that, and how they manage
paths within the wrapper, I can easily imagine ways to break due to
Windows path size limits; but there are too many moving parts to be sure.

I suggest the best thing to do is to report the bug to IntelliJ, and let
them determine if the bug is in fact in the svn command-line client or
within IDEA or their version control plugin.

> Next time I will face the same issue, I will try to provide you with
> the svn command.

Next time that happens, I suggest you retry the commit with the
command-line client. If that succeeds, it will be pretty strong evidence
of a bug in IDEA rather than Subversion.

-- Brane



RE: svn command line client 1.8.8 - Error: file name or extension is too long

2014-09-16 Thread Bert Huijben


> -Original Message-
> From: Geoff Field [mailto:geoff_fi...@aapl.com.au]
> Sent: maandag 15 september 2014 01:38
> To: Stefan Sperling; milan_plan...@swissre.com
> Cc: users@subversion.apache.org
> Subject: RE: svn command line client 1.8.8 - Error: file name or extension
is
> too long
> 
> > On Fri, Sep 12, 2014 at 11:29:37AM +0200,
> > milan_plan...@swissre.com wrote:
> > > Dear team,
> > >
> > > I tried to commit my changes with following error message:
> > >
> > > Error:Cannot run program
> > "C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe" (in
> > > directory
> > >
> > "C:\Users\S3F96Q\work\sources\g10ct\SR_G10_CT\modules\sr-g10-c
> > t-batch-xd\src\main\resources"):
> > > CreateProcess error=206, The filename or extension is too long
Going back to the original error report:

Looking at the error(CreateProcess error=206), you get this error when
starting the process, not after the process started.

This implies that the length problem is either with the name of the process
(=svn.exe) or with the directory in which you are trying to start the
process.

If the path length error would have been in an argument, or a subpath you
would have received an error from svn, not from the process starting svn.

In general Subversion 1.7 and later shouldn't have problems with long paths,
as long as all the (long) passed paths are in the absolute form.

Long relative paths have different problems, as the Windows api to transform
those paths to their absolute form doesn't support long paths.



You can probably solve your issue by just starting 'svn' explicitly from
'C:\' or some other safe directory.


Bert



Re: svn command line client 1.8.8 - Error: file name or extension is too long

2014-09-16 Thread Branko Čibej
On 16.09.2014 11:12, Bert Huijben wrote:
>
>> -Original Message-
>> From: Geoff Field [mailto:geoff_fi...@aapl.com.au]
>> Sent: maandag 15 september 2014 01:38
>> To: Stefan Sperling; milan_plan...@swissre.com
>> Cc: users@subversion.apache.org
>> Subject: RE: svn command line client 1.8.8 - Error: file name or extension
> is
>> too long
>>
>>> On Fri, Sep 12, 2014 at 11:29:37AM +0200,
>>> milan_plan...@swissre.com wrote:
 Dear team,

 I tried to commit my changes with following error message:

 Error:Cannot run program
>>> "C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe" (in
 directory

>>> "C:\Users\S3F96Q\work\sources\g10ct\SR_G10_CT\modules\sr-g10-c
>>> t-batch-xd\src\main\resources"):
 CreateProcess error=206, The filename or extension is too long
> Going back to the original error report:
>
> Looking at the error(CreateProcess error=206), you get this error when
> starting the process, not after the process started.
>
> This implies that the length problem is either with the name of the process
> (=svn.exe) or with the directory in which you are trying to start the
> process.
>
> If the path length error would have been in an argument, or a subpath you
> would have received an error from svn, not from the process starting svn.
>
> In general Subversion 1.7 and later shouldn't have problems with long paths,
> as long as all the (long) passed paths are in the absolute form.
>
> Long relative paths have different problems, as the Windows api to transform
> those paths to their absolute form doesn't support long paths.
>
>
>
> You can probably solve your issue by just starting 'svn' explicitly from
> 'C:\' or some other safe directory.

See above; the OP used IntelliJ IDEA, which drives the command-line
client, not the command line directly. I suspect it's a limit of the
CreateProcess API, which limits the command-line paraneter to MAX_PATH;
so, if there are a lot of files to commit, and IDEA (correctly) passes
absolute paths to Subversion, it's fairly easy to exceed that limit.

This is just guesswork, of course, but I've seen similar things happen
in naïvely written apps on Windows. To make things worse, the IntelliJ
devs probably don't have much control over how Java launches external
processes on Windows.

-- Brane



Re: Node '....' has unexpectedly changed kind, after svn upgrade

2014-09-16 Thread Philip Martin
hankin  writes:

> It asked me to run "svn upgrade" so I did.
>
> But now when I try to commit a folder, it says...
> Node '' has unexpectedly changed kind
>
> I haven't changed this file for many months.
>
> When I run "svn  info ...", it says it's a file and it is a file so there
> is nothing wrong.
> Node Kind: file

This error can occur if you add/delete the svn:special property.  Are
you on Windows or Unix?  Do you have versioned symlinks in the
repository?  What do 'svn status' and 'svn diff' show for the file?

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*


RE: svn command line client 1.8.8 - Error: file name or extension is too long

2014-09-16 Thread Bert Huijben


> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 16 september 2014 12:07
> To: users@subversion.apache.org
> Subject: Re: svn command line client 1.8.8 - Error: file name or extension is
> too long
> 
> On 16.09.2014 11:12, Bert Huijben wrote:
> >
> >> -Original Message-
> >> From: Geoff Field [mailto:geoff_fi...@aapl.com.au]
> >> Sent: maandag 15 september 2014 01:38
> >> To: Stefan Sperling; milan_plan...@swissre.com
> >> Cc: users@subversion.apache.org
> >> Subject: RE: svn command line client 1.8.8 - Error: file name or extension
> > is
> >> too long
> >>
> >>> On Fri, Sep 12, 2014 at 11:29:37AM +0200,
> >>> milan_plan...@swissre.com wrote:
>  Dear team,
> 
>  I tried to commit my changes with following error message:
> 
>  Error:Cannot run program
> >>> "C:\srdev\tool\SVN_CLIENT_1.8.8\svn.exe" (in
>  directory
> 
> >>> "C:\Users\S3F96Q\work\sources\g10ct\SR_G10_CT\modules\sr-g10-c
> >>> t-batch-xd\src\main\resources"):
>  CreateProcess error=206, The filename or extension is too long
> > Going back to the original error report:
> >
> > Looking at the error(CreateProcess error=206), you get this error when
> > starting the process, not after the process started.
> >
> > This implies that the length problem is either with the name of the process
> > (=svn.exe) or with the directory in which you are trying to start the
> > process.
> >
> > If the path length error would have been in an argument, or a subpath you
> > would have received an error from svn, not from the process starting svn.
> >
> > In general Subversion 1.7 and later shouldn't have problems with long
> paths,
> > as long as all the (long) passed paths are in the absolute form.
> >
> > Long relative paths have different problems, as the Windows api to
> transform
> > those paths to their absolute form doesn't support long paths.
> >
> >
> >
> > You can probably solve your issue by just starting 'svn' explicitly from
> > 'C:\' or some other safe directory.
> 
> See above; the OP used IntelliJ IDEA, which drives the command-line
> client, not the command line directly. I suspect it's a limit of the
> CreateProcess API, which limits the command-line paraneter to MAX_PATH;
> so, if there are a lot of files to commit, and IDEA (correctly) passes
> absolute paths to Subversion, it's fairly easy to exceed that limit.

The commandline argument of CreateProcess has a limit of 32768 characters (See 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx) 
on Windows NT and later.  This argument contains all arguments passed by the 
calling program, in most cases including the program name itself. If you hit 
this limit you get a different kind of error, as there is nothing that requires 
this to be a path.

If you get a long path error in the calling process the problem is a path 
directly passed to the CreateProcess API... The parsing of the commandline to 
separate arguments is part of the called process on Windows, so that would have 
been reported as an error of the process... not an error starting the process. 

(The parsing in the application is also the reason why different processes have 
different argument escaping rules...)

Bert





Re: Node '....' has unexpectedly changed kind, after svn upgrade

2014-09-16 Thread hankin
The status was ~

Something was definitely broken.

When I remove the file and run "svn update", it is a normal file but with
only one line.  But the file has many lines and is a normal file.
The status is still ~ after removing and updating.

But if I change the file to a symlink, the status is M

Anyways, I changed it to a link, removed the file, copied back the data,
and added it again.  It's ok now.

Thanks.




On 16 September 2014 20:37, Philip Martin 
wrote:

> hankin  writes:
>
> > It asked me to run "svn upgrade" so I did.
> >
> > But now when I try to commit a folder, it says...
> > Node '' has unexpectedly changed kind
> >
> > I haven't changed this file for many months.
> >
> > When I run "svn  info ...", it says it's a file and it is a file so there
> > is nothing wrong.
> > Node Kind: file
>
> This error can occur if you add/delete the svn:special property.  Are
> you on Windows or Unix?  Do you have versioned symlinks in the
> repository?  What do 'svn status' and 'svn diff' show for the file?
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
>


Re: Cannot view branch contents

2014-09-16 Thread Nico Kadel-Garcia
On Mon, Sep 15, 2014 at 1:47 PM, Walker James H CONTR USSTRATCOM/J8641
 wrote:
> History,
>
> We have SVN repositories on an older server.  One of our root projects has a
> branch titled "tag" which all users can see and expand the contents of.
>
> I have copied this repository to a new server.  The contents of "tag" cannot
> be seen by any users except one.  Yet, all other branches can be
> viewed/expanded.
>
> Any thoughts?  I have researched through the pages and have not found
> anything like the situation that I described.
>
> v/r,
> Jim

Sounds like your new server has a misconfigured access setup. Can a
local user, looking at file based repo access, see the tags? And can
you review or post the relevant Apache or svnserve configuration that
is limiting repository access?


Re: Node '....' has unexpectedly changed kind, after svn upgrade

2014-09-16 Thread Branko Čibej
On 16.09.2014 13:21, hankin wrote:
> The status was ~
>
> Something was definitely broken.
>
> When I remove the file and run "svn update", it is a normal file but
> with only one line.  But the file has many lines and is a normal file.
> The status is still ~ after removing and updating.
>
> But if I change the file to a symlink, the status is M
>
> Anyways, I changed it to a link, removed the file, copied back the
> data, and added it again.  It's ok now.

The most likely explanation is that something (perhaps an editor?)
replaced the symlink with a file that contained the symlink target's
contents. Subversion wouldn't do that itself.

-- Brane



RE: SVN Book Site Down (UNCLASSIFIED)

2014-09-16 Thread John Maher
I was getting that page but I can get to the book now.  Try it tomorrow, maybe 
the DNS server that you are using needs to be updated?  I don't know how they 
block it and why some can get it while others can not.

JM

-Original Message-
From: Weeks, Shawn C CTR (US) [mailto:shawn.c.weeks2@mail.mil] 
Sent: Tuesday, September 16, 2014 3:02 PM
To: Ryan Schmidt
Cc: Subversion Users
Subject: RE: SVN Book Site Down (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

This is what I get when I access it. I'm on a military installation if it 
matters but I'm not sure how it would make that happen.

Thanks

Shawn Weeks
Brockwell Technologies
Supporting LOGSA LITeS
256-955-0779


-Original Message-
From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] 
Sent: Monday, September 15, 2014 6:02 PM
To: Weeks, Shawn C CTR (US)
Cc: Subversion Users
Subject: Re: SVN Book Site Down (UNCLASSIFIED)


On Sep 15, 2014, at 11:16 AM, Weeks, Shawn C CTR (US) wrote:
> 
> Not sure who to report this to but svnbook.com is down due to some registrar 
> issues.

It's working for me.

If it's still down for you, you can get to the site at:

http://svnbook.red-bean.com

Their contact information is there.


Classification: UNCLASSIFIED
Caveats: NONE




RE: SVN Book Site Down (UNCLASSIFIED)

2014-09-16 Thread Weeks, Shawn C CTR (US)
Classification: UNCLASSIFIED
Caveats: NONE

Thanks I've started asking around and it appears that the DOD is doing some 
sort of caching. Hopefully it rolls over soon so we can access the page again.

Shawn Weeks
Brockwell Technologies
Supporting LOGSA LITeS
256-955-0779


-Original Message-
From: John Maher [mailto:jo...@rotair.com] 
Sent: Tuesday, September 16, 2014 2:20 PM
To: Weeks, Shawn C CTR (US); Ryan Schmidt
Cc: Subversion Users
Subject: RE: SVN Book Site Down (UNCLASSIFIED)

I was getting that page but I can get to the book now.  Try it tomorrow, maybe 
the DNS server that you are using needs to be updated?  I don't know how they 
block it and why some can get it while others can not.

JM

-Original Message-
From: Weeks, Shawn C CTR (US) [mailto:shawn.c.weeks2@mail.mil] 
Sent: Tuesday, September 16, 2014 3:02 PM
To: Ryan Schmidt
Cc: Subversion Users
Subject: RE: SVN Book Site Down (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

This is what I get when I access it. I'm on a military installation if it 
matters but I'm not sure how it would make that happen.

Thanks

Shawn Weeks
Brockwell Technologies
Supporting LOGSA LITeS
256-955-0779


-Original Message-
From: Ryan Schmidt [mailto:subversion-2...@ryandesign.com] 
Sent: Monday, September 15, 2014 6:02 PM
To: Weeks, Shawn C CTR (US)
Cc: Subversion Users
Subject: Re: SVN Book Site Down (UNCLASSIFIED)


On Sep 15, 2014, at 11:16 AM, Weeks, Shawn C CTR (US) wrote:
> 
> Not sure who to report this to but svnbook.com is down due to some registrar 
> issues.

It's working for me.

If it's still down for you, you can get to the site at:

http://svnbook.red-bean.com

Their contact information is there.


Classification: UNCLASSIFIED
Caveats: NONE



Classification: UNCLASSIFIED
Caveats: NONE




smime.p7s
Description: S/MIME cryptographic signature


Error while checking out via externals

2014-09-16 Thread Christian Fürst

Hello,

I have tried to check out a project with external sources.
This error occurs every time I am checking out, it is reproducable.
Any ideas?

Greets
Christian

---
Subversion Exception!
---
Subversion hat ein ernstes Problem festgestellt.
Bitte nehmen Sie sich die Zeit, es mit einer möglichst
ausführlichen Beschreibung, was sie zu tun versuchten, an
die Subversion Mailingliste weiterzuleiten.
Bitte durchsuchen Sie zuerst das Listenarchiv nach der Fehlermeldung,
um doppelte Berichte zu vermeiden.Das Listenarchiv finden Sie unter
http://subversion.apache.org/mailing-lists.html

Subversion berichtet folgendes
(Sie können den Inhalt dieses Dialogs mit Hilfe von
Strg+C in die Zwischenablage kopieren):

In Datei
 
»D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\update_editor.c«,
 Zeile 1550: Assert-Anweisung schlug fehl (action ==
 svn_wc_conflict_action_delete)
---
OK
---