Re: svn up issue

2012-07-11 Thread vishwajeet singh
On Wed, Jul 11, 2012 at 12:28 PM, dhanushka ranasinghe <
parakrama1...@gmail.com> wrote:

> Hi guys...
>
> most of  times we are getting , following error,  when taking "svn up"
>
>
>  error : *svn: REPORT of '/repos/home/!svn/vcc/default': Could not read
> response body: Secure connection truncated 
> (https://svn.ihx.com
> )*
>
> is there any reason for this, how can i sort this issue..
>

Can you provide some details about your environment ?
Server configuration and some details which you might feel relevant and
specific to your setup.


>
>
> Thank You
> Dhanushka
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet


Re: svn up issue

2012-07-11 Thread vishwajeet singh
On Wed, Jul 11, 2012 at 12:46 PM, vishwajeet singh wrote:

>
>
> On Wed, Jul 11, 2012 at 12:28 PM, dhanushka ranasinghe <
> parakrama1...@gmail.com> wrote:
>
>> Hi guys...
>>
>> most of  times we are getting , following error,  when taking "svn up"
>>
>>
>>  error : *svn: REPORT of '/repos/home/!svn/vcc/default': Could not read
>> response body: Secure connection truncated 
>> (https://svn.ihx.com
>> )*
>>
>> is there any reason for this, how can i sort this issue..
>>
>
> Can you provide some details about your environment ?
> Server configuration and some details which you might feel relevant and
> specific to your setup.
>

Looks like the issue mentioned here
http://subversion.apache.org/faq.html#secure-connection-truncated


>
>
>>
>>
>> Thank You
>> Dhanushka
>>
>
>
>
> --
> Vishwajeet Singh
> +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn:
> http://www.linkedin.com/in/singhvishwajeet
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet


Re: svn up issue

2012-07-11 Thread dhanushka ranasinghe
Hi...

apart form default apache configuration we use , following configuration
options ..


MaxKeepAliveRequests 100
KeepAliveTimeout5



  SVNInMemoryCacheSize 100
  SVNCacheTextDeltas On
  SVNCacheFullTexts On


LimitXMLRequestBody 0


Thank You


On 11 July 2012 12:46, vishwajeet singh  wrote:

>
>
> On Wed, Jul 11, 2012 at 12:28 PM, dhanushka ranasinghe <
> parakrama1...@gmail.com> wrote:
>
>> Hi guys...
>>
>> most of  times we are getting , following error,  when taking "svn up"
>>
>>
>>  error : *svn: REPORT of '/repos/home/!svn/vcc/default': Could not read
>> response body: Secure connection truncated 
>> (https://svn.ihx.com
>> )*
>>
>> is there any reason for this, how can i sort this issue..
>>
>
> Can you provide some details about your environment ?
> Server configuration and some details which you might feel relevant and
> specific to your setup.
>
>
>>
>>
>> Thank You
>> Dhanushka
>>
>
>
>
> --
> Vishwajeet Singh
> +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn:
> http://www.linkedin.com/in/singhvishwajeet
>


Re: svn up issue

2012-07-11 Thread vishwajeet singh
On Wed, Jul 11, 2012 at 1:44 PM, dhanushka ranasinghe <
parakrama1...@gmail.com> wrote:

> Hi...
>
> apart form default apache configuration we use , following configuration
> options ..
>
>
> MaxKeepAliveRequests 100
> KeepAliveTimeout5
>
> 
>
>   SVNInMemoryCacheSize 100
>   SVNCacheTextDeltas On
>   SVNCacheFullTexts On
> 
>
> LimitXMLRequestBody 0
>

Probably you would need to increase KeepAliveTimeout as per the faq in link
shared earlier.


>
> Thank You
>
>
>
> On 11 July 2012 12:46, vishwajeet singh  wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 12:28 PM, dhanushka ranasinghe <
>> parakrama1...@gmail.com> wrote:
>>
>>> Hi guys...
>>>
>>> most of  times we are getting , following error,  when taking "svn up"
>>>
>>>
>>>  error : *svn: REPORT of '/repos/home/!svn/vcc/default': Could not read
>>> response body: Secure connection truncated 
>>> (https://svn.ihx.com
>>> )*
>>>
>>> is there any reason for this, how can i sort this issue..
>>>
>>
>> Can you provide some details about your environment ?
>> Server configuration and some details which you might feel relevant and
>> specific to your setup.
>>
>>
>>>
>>>
>>> Thank You
>>> Dhanushka
>>>
>>
>>
>>
>> --
>> Vishwajeet Singh
>> +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
>> Twitter: http://twitter.com/vishwajeets | LinkedIn:
>> http://www.linkedin.com/in/singhvishwajeet
>>
>
>


-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet


Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

2012-07-11 Thread Matthew Pounsett

On 2012/07/11, at 01:13, Jason Heeris wrote:

> The problem is this: it doesn't seem to work on files with the '[' or ']' 
> characters in their name. Ignoring VisualSVN's GUI for now, I've tried going 
> one step further and editing the "authz-windows" file by hand and I just 
> can't seem to get it to work. I've tried variations like:

I note by your examples that you're using a unix filesystem (as opposed to 
Windows).  I would be a little surprised if this worked there, since the square 
brackets are normally used by unix shells as glob metacharacters, similarly to 
* and ?. 

For example, 'tmp[123].txt' is a glob pattern to match tmp1.txt, tmp2.txt and 
tmp3.txt.

Sorry, I'm not sure how to help you make this work.  If you can avoid using 
those characters in file names, please do so at all costs.  A good rule of 
thumb is that if you can't create the file from a command line in a shell 
without escaping characters, then don't use those characters.  


> It's also worth pointing out that some paths have the "#" character in them. 
> What do I do when I get to those?

This is commonly comment character.  It's possible to create a file with this 
character in it, but personally I'd avoid it.  It's possible you could escape 
it like so: "tmp\#1.txt", but I'm not confident that will work.  If svn can't 
deal with this one you might have a case for it being a bug, since it is 
technically a legal file name.




Cleaning out an old subscriber

2012-07-11 Thread Matthew Pounsett
Hi List Admins.  Sorry, but I couldn't find a list admin address on the web 
site for this, so I'm sending it to the list itself.

I'm sure others have seen this too, but any time I post to the list I'm getting 
a bounce from world.deshaw.com.  Could an admin track down this subscriber and 
remove them from the list?

Thanks,
   Matt Pounsett


Begin forwarded message:

> From: Postmaster 
> Subject: Important: message being returned.
> Date: July 11, 2012 11:02:20 EDT
> To: m...@conundrum.com
> Reply-To: nob...@world.deshaw.com
> 
> Thank you for your inquiry.  Justin Vallon is no longer with the firm.  For 
> immediate assistance, please contact Reception at +1-212-478-.
> 
> Sincerely,
> The D. E. Shaw Group
> 
> 
> -- 8< --- CUT HERE -- CUT HERE --- >8 --
> 
>  From:Matthew Pounsett 
>  To:  Jason Heeris 
>  cc:  users@subversion.apache.org
>  Subject: Re: Square brackets in file names and authz (in VisualSVN 2.5.5)
> 
> 
>  On 2012/07/11, at 01:13, Jason Heeris wrote:
> 
>> The problem is this: it doesn't seem to work on files with the '[' or ']' 
>> characters in their name. Ignoring VisualSVN's GUI for now, I've tried going 
>> one step further and editing the "authz-windows" file by hand and I just 
>> can't seem to get it to work. I've tried variations like:
> 
>  I note by your examples that you're using a unix filesystem (as opposed to 
> Windows).  I would be a little surprised if this worked there, since the 
> square brackets are normally used by unix shells as glob metacharacters, 
> similarly to * and ?. 
> 
>  For example, 'tmp[123].txt' is a glob pattern to match tmp1.txt, tmp2.txt 
> and tmp3.txt.
> 
>  Sorry, I'm not sure how to help you make this work.  If you can avoid using 
> those characters in file names, please do so at all costs.  A good rule of 
> thumb is that if you can't create the file from a command line in a shell 
> without escaping characters, then don't use those characters.  
> 
> 
>> It's also worth pointing out that some paths have the "#" character in them. 
>> What do I do when I get to those?
> 
>  This is commonly comment character.  It's possible to create a file with 
> this character in it, but personally I'd avoid it.  It's possible you could 
> escape it like so: "tmp\#1.txt", but I'm not confident that will work.  If 
> svn can't deal with this one you might have a case for it being a bug, since 
> it is technically a legal file name.
> 
> 
> 
> 



Re: Cleaning out an old subscriber

2012-07-11 Thread Thorsten Schöning
Guten Tag Matthew Pounsett,
am Mittwoch, 11. Juli 2012 um 17:30 schrieben Sie:

> I'm sure others have seen this too, but any time I post to the list
> I'm getting a bounce from world.deshaw.com.  Could an admin track
> down this subscriber and remove them from the list?

I already wrote to the postmaster and some other addresses, but no
response of course.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow



RE: Cleaning out an old subscriber

2012-07-11 Thread Bob Archer
If you send me the full email that is causing the bounce I can unsubscribe it. 
I haven't seen the bounces.

BOb


> -Original Message-
> From: Matthew Pounsett [mailto:m...@conundrum.com]
> Sent: Wednesday, July 11, 2012 11:31 AM
> To: users@subversion.apache.org
> Subject: Cleaning out an old subscriber
> 
> Hi List Admins.  Sorry, but I couldn't find a list admin address on the web 
> site
> for this, so I'm sending it to the list itself.
> 
> I'm sure others have seen this too, but any time I post to the list I'm 
> getting a
> bounce from world.deshaw.com.  Could an admin track down this subscriber
> and remove them from the list?
> 
> Thanks,
>Matt Pounsett
> 
> 
> Begin forwarded message:
> 
> > From: Postmaster 
> > Subject: Important: message being returned.
> > Date: July 11, 2012 11:02:20 EDT
> > To: m...@conundrum.com
> > Reply-To: nob...@world.deshaw.com
> >
> > Thank you for your inquiry.  Justin Vallon is no longer with the firm.  For
> immediate assistance, please contact Reception at +1-212-478-.
> >
> > Sincerely,
> > The D. E. Shaw Group
> >
> >
> > -- 8< --- CUT HERE -- CUT HERE --- >8 --
> >
> >  From:Matthew Pounsett 
> >  To:  Jason Heeris 
> >  cc:  users@subversion.apache.org
> >  Subject: Re: Square brackets in file names and authz (in VisualSVN 2.5.5)
> >
> >
> >  On 2012/07/11, at 01:13, Jason Heeris wrote:
> >
> >> The problem is this: it doesn't seem to work on files with the '[' or ']'
> characters in their name. Ignoring VisualSVN's GUI for now, I've tried going
> one step further and editing the "authz-windows" file by hand and I just can't
> seem to get it to work. I've tried variations like:
> >
> >  I note by your examples that you're using a unix filesystem (as opposed to
> Windows).  I would be a little surprised if this worked there, since the 
> square
> brackets are normally used by unix shells as glob metacharacters, similarly to
> * and ?.
> >
> >  For example, 'tmp[123].txt' is a glob pattern to match tmp1.txt, tmp2.txt
> and tmp3.txt.
> >
> >  Sorry, I'm not sure how to help you make this work.  If you can avoid using
> those characters in file names, please do so at all costs.  A good rule of 
> thumb
> is that if you can't create the file from a command line in a shell without
> escaping characters, then don't use those characters.
> >
> >
> >> It's also worth pointing out that some paths have the "#" character in
> them. What do I do when I get to those?
> >
> >  This is commonly comment character.  It's possible to create a file with 
> > this
> character in it, but personally I'd avoid it.  It's possible you could escape 
> it like
> so: "tmp\#1.txt", but I'm not confident that will work.  If svn can't deal 
> with
> this one you might have a case for it being a bug, since it is technically a 
> legal
> file name.
> >
> >
> >
> >



Re: Cleaning out an old subscriber

2012-07-11 Thread Matthew Pounsett

On 2012/07/11, at 12:13, Bob Archer wrote:

> If you send me the full email that is causing the bounce I can unsubscribe 
> it. I haven't seen the bounces.

Sorry, a regular subscriber can't help you there.  I have no idea what 
subscribed email address leads to that destination, and can't know without 
access to the full subscriber list.

As far as I can tell, all it takes is an email to the 
users@subversion.apache.org list to generate a bounce.




Re: Cleaning out an old subscriber

2012-07-11 Thread Thorsten Schöning
Guten Tag Bob Archer,
am Mittwoch, 11. Juli 2012 um 18:13 schrieben Sie:

> If you send me the full email that is causing the bounce I can
> unsubscribe it. I haven't seen the bounces.

"Vallon, Justin" 

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow



If our SVN server is 1.6.12, why don't I see older merge history on elements merged from branch to trunk?

2012-07-11 Thread KARR, DAVID
It appears that our SVN on our server was recently upgraded from a version 
before merge history tracking was implemented, to version 1.6.x, where merge 
history should be available.

However, I checked the SVN history for an element that I made changes to on a 
branch, and I looked at that same element after it was merged (by someone else) 
to the trunk.  My changes are in that file, but the SVN history doesn't include 
the checkin that I did.  Is this simply happening because of how the merge to 
trunk was done?  Is there a particular way that merges have to be done to 
preserve merge history?


Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

2012-07-11 Thread Jason Heeris
On 11 July 2012 23:01, Matthew Pounsett  wrote:

> I note by your examples that you're using a unix filesystem (as opposed to
> Windows).  I would be a little surprised if this worked there, since the
> square brackets are normally used by unix shells as glob metacharacters,
> similarly to * and ?.
>

The app runs on a Windows Server 2003 system, and creates and commits the
files on NTFS.


> Sorry, I'm not sure how to help you make this work.  If you can avoid
> using those characters in file names, please do so at all costs.


Well... not without a rewrite of the application, and the ability to
somehow replay the entire repository with different filenames while
maintaining revision numbers. Simply renaming them in the repository won't
work, since then (a) the app will break, and (b) the files could still be
accessed at previous revisions. Maybe possible with "svnadmin dump" or a
PySVN script, but not easy.


>  A good rule of thumb is that if you can't create the file from a command
> line in a shell without escaping characters, then don't use those
> characters.
>

Only the app is able to create and delete the files — any other user can
only modify them through SVN. Hence, I've always used tab completion or a
GUI (on both Linux and Windows) to work with them.

In my defense, I did what I thought was due diligence when this was set up.
I looked for characters that were deemed illegal in SVN paths, and I made
sure these characters would work on all the filesystems we use here. I
didn't expect any of this to be an issue, any more than spaces or non-ASCII
characters.


> If svn can't deal with this one you might have a case for it being a bug,
> since it is technically a legal file name.
>

So are the square brackets...

Look, I realise this is an edge case, but if SVN can handle non-ASCII,
shouldn't it handle punctuation? IMO there is at least one bug here: either
the authz file spec should include escape sequences "[", "]", "#" and maybe
others, or it should be documented that they are disallowed characters for
SVN (or maybe more specifically, authz). I'll file it later today and see
what response I get.

Cheers,
Jason


Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

2012-07-11 Thread David Brodbeck
On Wed, Jul 11, 2012 at 8:01 AM, Matthew Pounsett  wrote:
> I note by your examples that you're using a unix filesystem (as opposed to 
> Windows).  I would be a little surprised if this worked there, since the 
> square brackets are normally used by unix shells as glob metacharacters, 
> similarly to * and ?.

Just because they're used as shell metacharacters doesn't mean they
aren't legal in filenames:

brodbd@patas:~/foo$ touch \*foo\*
brodbd@patas:~/foo$ touch \?bar\?
brodbd@patas:~/foo$ touch \[biz\]
brodbd@patas:~/foo$ ls -l
total 2
-rw-r--r-- 1 brodbd brodbd 0 Jul 11 17:17 ?bar?
-rw-r--r-- 1 brodbd brodbd 0 Jul 11 17:17 [biz]
-rw-r--r-- 1 brodbd brodbd 0 Jul 11 17:17 *foo*

That's not to say they're a good *idea*, as they tend to make
scripting tricky, but the filesystem won't complain.

>> It's also worth pointing out that some paths have the "#" character in them. 
>> What do I do when I get to those?
>
> This is commonly comment character.  It's possible to create a file with this 
> character in it, but personally I'd avoid it.  It's possible you could escape 
> it like so: "tmp\#1.txt", but I'm not confident that will work.  If svn can't 
> deal with this one you might have a case for it being a bug, since it is 
> technically a legal file name.

emacs uses files starting and ending in "#" extensively for autosave
recovery data, FWIW.


-- 
David Brodbeck
System Administrator, Linguistics
University of Washington


Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

2012-07-11 Thread Matthew Pounsett

On 2012/07/11, at 20:20, David Brodbeck wrote:

> On Wed, Jul 11, 2012 at 8:01 AM, Matthew Pounsett  wrote:
>> I note by your examples that you're using a unix filesystem (as opposed to 
>> Windows).  I would be a little surprised if this worked there, since the 
>> square brackets are normally used by unix shells as glob metacharacters, 
>> similarly to * and ?.
> 
> Just because they're used as shell metacharacters doesn't mean they
> aren't legal in filenames:

Right, but anything using simple methods of globbing may not react well to 
their use, as the OP seems to have discovered.  I didn't say you couldn't force 
the files to be created, just that I'd be a little surprised if those 
characters worked in authz configs.

That said.. it turns out the OP is on Windows after all, and I was just fooled 
by the non-windows notation for the file names.  I'm no authority on what is or 
isn't possible on NTFS since I haven't touched it in a good 10+ years so it's 
likely none of what I had to say applies to his problem.

> 
>>> It's also worth pointing out that some paths have the "#" character in 
>>> them. What do I do when I get to those?
>> 
>> This is commonly comment character.  It's possible to create a file with 
>> this character in it, but personally I'd avoid it.  It's possible you could 
>> escape it like so: "tmp\#1.txt", but I'm not confident that will work.  If 
>> svn can't deal with this one you might have a case for it being a bug, since 
>> it is technically a legal file name.
> 
> emacs uses files starting and ending in "#" extensively for autosave
> recovery data, FWIW.

Again, didn't say it wasn't possible.. just that it might not be well advised.




Re: Square brackets in file names and authz (in VisualSVN 2.5.5)

2012-07-11 Thread Jason Heeris
On 12 July 2012 08:03, Jason Heeris  wrote:

> I'll file it later today and see what response I get.
>

Apparently I need a buddy with whom to file the bug. If anyone would be
willing, I'd appreciate it.

I've attached a bash script that reproduces the problem under SVN 1.7.4.
Please read the script before running it, I make no assurances that it's
not accidentally going to do something awful...

— Jason


svntest
Description: Binary data


RE: If our SVN server is 1.6.12, why don't I see older merge history on elements merged from branch to trunk?

2012-07-11 Thread Cooke, Mark
> -Original Message-
> From: KARR, DAVID [mailto:dk0...@att.com] 
> Sent: 12 July 2012 00:39
> To: users@subversion.apache.org
> Subject: If our SVN server is 1.6.12, why don't I see older 
> merge history on elements merged from branch to trunk?
> 
> It appears that our SVN on our server was recently upgraded 
> from a version before merge history tracking was implemented, 
> to version 1.6.x, where merge history should be available.

I wonder why a "recent" upgrade used 1.6.x instead of 1.7.x...

> However, I checked the SVN history for an element that I made 
> changes to on a branch, and I looked at that same element 
> after it was merged (by someone else) to the trunk.  My 
> changes are in that file, but the SVN history doesn't include 
> the checkin that I did.  Is this simply happening because of 
> how the merge to trunk was done?  Is there a particular way 
> that merges have to be done to preserve merge history?

It sounds like you are expecting merge history to magically appear for merges 
done _before_ the server was upgraded?  In that case, no, svn does not go back 
and try to re-create history (I suspect that would be at best an error-prone 
exercise) but you should start to see info being added going forward.

Or did I misunderstand your question?

~ mark c