Re: Using a changelist with the revet command

[Daniel Shahaf]

I think it's intentional.

If we change the first command to have the semantics of the second
command, wouldn't it mean that the second command is equivalent to
'svn revert -R ./'?

If yes, we can't change it --- rather bad compatibility surprised for
everyone who's used to 'svn revert --cl foo -R ./'.

Giulio Troccoli wrote on Fri, Nov 19, 2010 at 11:33:54 +:
> Hi,
> 
> I have found an odd behaviour with the revert command. Maybe it's
> intended, but I don't find it very intuitive. I'm using SVN 1.6.9.
> 
> If I have a changelist and I want to revert all changes made in all
> files in the changelist I would use the following
> 
> svn revert --changelist 
> 
> That doesn't work. Not only I have to add the --depth option, but
> I also have to specify the PATH, so something like
> 
> svn revert --depth infinity --changelist  .
> 
> I don't think either are necessary though. The good thing about
> changelist is that with one easy command you can work on many files at
> ones, even if they are in different directories. With the above
> command, you still can, but from the deepest common directory of all
> the files in the changelist.
> 
> The changelist has the full path of every file, so I would have though
> that the first command I tried would be enough.
> 
> What do you think?
> 
> G
> 
> 
> Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V
> 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
> 
> 
> 
> 

Re: Prevent mod_dav_svn REPORT log failure if files under?$REPOS/db/revprops/ are not in UTF-8 encoding

[Daniel Shahaf]

DON'T DO IT THIS WAY.  Follow Stefan's advice upthread.

Re: svn:externals format

[Christoph Bartoschek]

Am Dienstag, 16. November 2010 schrieb Stefan Sperling:
> On Tue, Nov 16, 2010 at 01:43:35PM +0100, Christoph Bartoschek wrote:
> > Hi,
> > 
> > what is the advantage of using
> > 
> > ^/trunk/project/subproj...@40  subproject
> 
> This new format does support relative URLs.
> 
> > compared to
> > 
> > -r 40  ^/trunk/project/subproject  subproject
> 
> This old format doesn't support relative URLs.
> You can only use full URLs (http://svn.example.com/...) with this format.
> 
> See "svn help propset" for more information.

svn help propset states that relative URLs also work for the old format. We 
currently use the old format with relative URLs:


 "Relative URLs are supported in Subversion 1.5 and greater for
  all above formats and are indicated by starting the URL with one
  of the following strings"

Christoph

Re: Mail-Copies-To

[Nico Kadel-Garcia]

On Fri, Nov 19, 2010 at 8:51 AM, Gary  wrote:
> Cooke, Mark wrote:
>>> -Original Message-

>> The short answer is that if a "standard" email client (for me, m$
>> outlook)
>
> I'm sorry. According to every other poster you are only allowed to use
> things which are specified in an RFC. Dump outlook and find something
> that is. Good luck with that.

Oh, you can *use* them, much as you can use many complex features of
Subversion configurations. But don't expect features that rely on
non-standard components, such as a local Perl or bash for pre-commit
operatons, to operate with other people's environments.

For email, as for Subversion, keeping it as simple and using only the
documented components has a lot to be said for it. That's why my email
is text, 8-bit clean, rather than UTF or HTML based.

Re: Can't see the wood for the trees (or: what are my branches called?)

[Andrey Repin]

Greetings, Gary!

> Thanks (both of you). I'd have appreciated it even more if you had
> followed the "Mail-Copies-To: never" header.

That is not standard header. If you really do not wish to receive personal
reply, set the Reply-To address back to the mailing list, which is the right
way to do this.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 19.11.2010, <23:32>

Sorry for my terrible english...

Re: svn:externals format

[Stefan Sperling]

On Fri, Nov 19, 2010 at 02:55:30PM +0100, Ludwig, Michael wrote:
> Replying to myself now that I realize the issue:
> 
> > From: Ludwig, Michael [mailto:michael.lud...@delphi-mb.de] 
> > Sent: Tuesday, November 16, 2010 3:21 PM
> 
> > > > what is the advantage of using
> > > > 
> > > > ^/trunk/project/subproj...@40  subproject
> > > 
> > > This new format does support relative URLs.
> > 
> > Are there many files beginning with a caret?
> > 
> > If not, it would also be convenient for:
> > 
> > * svn list
> > * svn cat
> > * svn copy
> > * svn move
> > * svn diff
> > * ...
> > 
> > Basically everything working with URLs.
> 
> Okay, I was proposing to make this "svn ls ^/" syntax work - but it already 
> works, which, however, I failed to realize because on Windows, you have to 
> put the command in double quotes as the cmd.exe shell uses the caret 
> character for its own purposes (line continuation), which made me think that 
> the syntax is not yet supported.
> 
> Shells can be tricky.

On Windows, you can also use ^^/ instead of "^/".

Stefan

Re: URL-only renames adds svn:mergeinfo property

[Stefan Sperling]

On Fri, Nov 19, 2010 at 12:38:57PM +0100, Johan Corveleyn wrote:
> I don't see why it matters that it's a "sub-branch". It's still a
> (grand-)child of mybranch, so can perfectly inherit that mergeinfo.
> AFAIU it only needs explicit mergeinfo if it starts to deviate from
> the mybranch root (e.g. if something is (sync-)merged directly to the
> sub-branch). Or am I missing something?

Hmmm.. I don't see any reason either. Explicit mergeinfo could probably be
created later when the subtree actually becomes a merge target.
I guess the current logic in the code simply doesn't account for the case
where the copy destination is a child of the source? Not sure.

Stefan

RE: Problem with diff after merging

[Jahn Otto Andersen]

Nope, it just says it was merged.

Perhaps --show-copies-as-adds will do the trick, but it's not available in
1.6 :(



-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: 15. november 2010 16:55
To: Jahn Otto Andersen
Cc: users@subversion.apache.org
Subject: Re: Problem with diff after merging

Doesn't 'svn diff' say something to the effect of "A file with 
name was added"?


There is also:

% $svn h diff | grep add
  --show-copies-as-adds [--sca] : don't diff copied or moved files with
their source

... but I think it's only in 1.7.

Jahn Otto Andersen wrote on Mon, Nov 15, 2010 at 10:20:00 +0100:
> I am using a code review tool called ReviewBoard to do code reviews. This
> tool uses svn diff to report the changes between BASE and work area.
> 
>  
> 
> I'm having problems when working in a branch and then merging into trunk.
> This problem seems to be caused by the diff generated by svn diff.
> 
>  
> 
> What I do: 
> 
> 1. Create a new branch based on trunk using TortoiseSVN's "branch"
function
> 2. Commit several changes into the branch, including creating new files 
> 3. Reintegrate branch into trunk using TortoiseSVN's "reintegrate branch"
> function.
> 4. Generate the diff using svn diff and use this for the code review 
> 
> The problem is:
> 
> The diff that is created by svn diff does not contain the new file. The
diff
> file contains the following lines (given that the new file is named
> NewFile.cs): 
> 
>  
> 
>  
> Property changes on: NewFile.cs 
> ___ 
> Modified: svn:mergeinfo 
>Merged /blabla/branches/mybranch/NewFile.cs:r11226-11336 
> -
> 
>  
> 
> It seems like the diff contains information about the fact that the new
file
> is being merged into trunk from the branch, but it doesn't contain the
> actual lines in the new file. As a result, the review request in
ReviewBoard
> doesn't contain NewFile.cs at all. 
> 
> Is there any way I can make svn diff include the new lines in the new
file?
> 
>  
> 

RE: svn:externals format

[Ludwig, Michael]

Replying to myself now that I realize the issue:

> From: Ludwig, Michael [mailto:michael.lud...@delphi-mb.de] 
> Sent: Tuesday, November 16, 2010 3:21 PM

> > > what is the advantage of using
> > > 
> > > ^/trunk/project/subproj...@40  subproject
> > 
> > This new format does support relative URLs.
> 
> Are there many files beginning with a caret?
> 
> If not, it would also be convenient for:
> 
> * svn list
> * svn cat
> * svn copy
> * svn move
> * svn diff
> * ...
> 
> Basically everything working with URLs.

Okay, I was proposing to make this "svn ls ^/" syntax work - but it already 
works, which, however, I failed to realize because on Windows, you have to put 
the command in double quotes as the cmd.exe shell uses the caret character for 
its own purposes (line continuation), which made me think that the syntax is 
not yet supported.

Shells can be tricky.

Michael

Re: URL-only renames adds svn:mergeinfo property

[Johan Corveleyn]

On Fri, Nov 19, 2010 at 12:10 PM, Stefan Sperling  wrote:
> On Fri, Nov 19, 2010 at 01:40:42PM +1000, Daniel Becroft wrote:
>> On Tue, Nov 16, 2010 at 3:54 PM, Daniel Becroft wrote:
>>
>> > Hi,
>> >
>> > I've just found (another) issue with using URL-only renames. If one of the
>> > parent directories has svn:mergeinfo recorded on it, then renaming a file
>> > via a URL results in the new file containing a full copy of what was on the
>> > trunk (but cut down to the individual file).
>> >
>> > Please see the following output from my test script (using SVN 1.6.13):
>> >
>> > >svn merge file:///D:/temp/svn_sandpit/repository/trunk .
>> > --- Merging r4 through r5 into '.':
>> > U    A\alpha.txt
>> >
>> > >svn commit . --message "Merge r5 from trunk to branch."
>> > Sending        .
>> > Sending        A\alpha.txt
>> > Transmitting file data .
>> > Committed revision 6.
>> >
>> > >svn propget svn:mergeinfo
>> > file:///D:/temp/svn_sandpit/repository/branches/branchA
>> > /trunk:4-5
>> >
>> > >svn propget svn:mergeinfo
>> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
>> >
>> > >svn rename
>> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
>> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt 
>> > --message
>> > "Rename alpha.txt to beta.txt on branchA."
>> > Committed revision 7.
>> >
>> > >svn propget svn:mergeinfo
>> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt
>> > /trunk/A/alpha.txt:4-5
>> >
>> > Notice that the 'svn propget' on alpha.txt indicates that there is no
>> > svn:mergeinfo property available, but it gets added to beta.txt during the
>> > rename.
>> >
>> > Is this intended behavior?
>
> I think the rationale for creating this mergeinfo is that Subversion cannot
> tell whether you're creating a copy of something (which will not receive
> merges directly) within a branch, or creating a subtree-branch (which will
> directly receive merges).
>
> Consider a two-level branching scenario:
>
> A branch is created:
>
>  svn cp ^/trunk/ ^/branches/mybranch
>
> This branch is synced to trunk periodically.
> Then later someone decides to branch a subtree of this branch (this
> is very different from branching the entire branch again!):
>
>  svn cp ^/branches/mybranch/foo/bar ^/branches/mybranch/foo/bar-experimental
>
> The bar-experimental branch now inherits explicit mergeinfo from
> the ^/branches/mybranches directory, say /trunk:40-50.
> I suppose this is done to prevent further merges from trunk (or subtrees of
> trunk) into bar-experimental from merging changes which have already been
> merged into foo/bar (the ancestor branch of foo/bar-experimental).

I don't fully understand why this requires foo/bar-experimental to
have its own explicit mergeinfo. If it wouldn't have explicit
mergeinfo, wouldn't it just inherit mergeinfo from the branch root,
like all subtrees of mybranch, hence knowing that /trunk:40-50 was
already merged to it?

I don't see why it matters that it's a "sub-branch". It's still a
(grand-)child of mybranch, so can perfectly inherit that mergeinfo.
AFAIU it only needs explicit mergeinfo if it starts to deviate from
the mybranch root (e.g. if something is (sync-)merged directly to the
sub-branch). Or am I missing something?

If it would be copied outside of mybranch, then yes, it would need
explicit mergeinfo to remember what was already merged into it.

Cheers,
-- 
Johan

RE: Mail-Copies-To

[Tony Sweeney]

Which again is not part of any email standard, just Daniel J.
Bernstein's wish list from 1997, codified as an IETF draft in 2000, but
never actually elevated to an approved RFC.  Although a number of MUAs
honour it, some (like Mozilla Thunderbird) explicitly rejected honouring
these headers by default as they are not part of an approved standard.

Tony. 

> -Original Message-
> From: Gary [mailto:subversion-u...@garydjones.name] 
> Sent: 19 November 2010 11:19
> To: users@subversion.apache.org
> Subject: Re: Mail-Copies-To
> 
> Ryan Schmidt wrote:
> 
> > If you don't wish to receive copies of replies on the list, one 
> > possible solution is to set the Reply-To header of your 
> outgoing mail 
> > to the list's address.
> 
> Mail-Followup-To was also set.
> 
> 
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> __
> 

RE: Mail-Copies-To

[Cooke, Mark]

> -Original Message-
> From: Andy Levy [mailto:andy.l...@gmail.com] 
> Sent: 19 November 2010 11:28
> To: users@subversion.apache.org
> Subject: Re: Mail-Copies-To
> 
> On Fri, Nov 19, 2010 at 06:19, Gary 
>  wrote:
> > Ryan Schmidt wrote:
> >
> >> If you don't wish to receive copies of replies on the 
> list, one possible
> >> solution is to set the Reply-To header of your outgoing mail to the
> >> list's address.
> >
> > Mail-Followup-To was also set.
> >
> 
> I can't find where this is a valid (RFC-specified) header either.
> 
I'm sorry but this is way off topic for this list and seems pretty petty
to me.

The short answer is that if a "standard" email client (for me, m$
outlook) does not handle the headers for me then I ain't going to go
looking.  If you want to fiddle with unusual headers, feel free but
please keep this off list.

I want to spend my time (trying to) helping with real problems...

~ mark c

Using a changelist with the revet command

[Giulio Troccoli]

Hi,

I have found an odd behaviour with the revert command. Maybe it's intended, but 
I don't find it very intuitive. I'm using SVN 1.6.9.

If I have a changelist and I want to revert all changes made in all files in 
the changelist I would use the following

svn revert --changelist 

That doesn't work. Not only I have to add the --depth option, but I also have 
to specify the PATH, so something like

svn revert --depth infinity --changelist  .

I don't think either are necessary though. The good thing about changelist is 
that with one easy command you can work on many files at ones, even if they are 
in different directories. With the above command, you still can, but from the 
deepest common directory of all the files in the changelist.

The changelist has the full path of every file, so I would have though that the 
first command I tried would be enough.

What do you think?

G


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

Re: Mail-Copies-To

[Johan Corveleyn]

On Fri, Nov 19, 2010 at 12:19 PM, Gary  wrote:
> Ryan Schmidt wrote:
>
>> If you don't wish to receive copies of replies on the list, one possible
>> solution is to set the Reply-To header of your outgoing mail to the
>> list's address.
>
> Mail-Followup-To was also set.

So? Could you be a little bit more explicit about what you expect? Is
that supposed to mean anything (possibly picked up automatically by
all popular MUA's)?

BTW, I systematically always use "Reply all" on this mailinglist, because:
a) Most people don't set Reply-To to the list address (and it isn't
automatically set by the list software), so if you hit "Reply" it only
goes to the sender.
b) Some people are not on the list, so prefer to be a recipient of the
mail directly.

So for simplicity, "Reply all" is usually the right thing to do here
... (people can always ignore double mails, and anyway gmail shows it
only once :-))

Cheers,
-- 
Johan

Re: Mail-Copies-To

[Andy Levy]

On Fri, Nov 19, 2010 at 06:19, Gary  wrote:
> Ryan Schmidt wrote:
>
>> If you don't wish to receive copies of replies on the list, one possible
>> solution is to set the Reply-To header of your outgoing mail to the
>> list's address.
>
> Mail-Followup-To was also set.
>

I can't find where this is a valid (RFC-specified) header either.

Re: URL-only renames adds svn:mergeinfo property

[Stefan Sperling]

On Fri, Nov 19, 2010 at 01:40:42PM +1000, Daniel Becroft wrote:
> On Tue, Nov 16, 2010 at 3:54 PM, Daniel Becroft wrote:
> 
> > Hi,
> >
> > I've just found (another) issue with using URL-only renames. If one of the
> > parent directories has svn:mergeinfo recorded on it, then renaming a file
> > via a URL results in the new file containing a full copy of what was on the
> > trunk (but cut down to the individual file).
> >
> > Please see the following output from my test script (using SVN 1.6.13):
> >
> > >svn merge file:///D:/temp/svn_sandpit/repository/trunk .
> > --- Merging r4 through r5 into '.':
> > UA\alpha.txt
> >
> > >svn commit . --message "Merge r5 from trunk to branch."
> > Sending.
> > SendingA\alpha.txt
> > Transmitting file data .
> > Committed revision 6.
> >
> > >svn propget svn:mergeinfo
> > file:///D:/temp/svn_sandpit/repository/branches/branchA
> > /trunk:4-5
> >
> > >svn propget svn:mergeinfo
> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
> >
> > >svn rename
> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/alpha.txt
> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt --message
> > "Rename alpha.txt to beta.txt on branchA."
> > Committed revision 7.
> >
> > >svn propget svn:mergeinfo
> > file:///D:/temp/svn_sandpit/repository/branches/branchA/A/beta.txt
> > /trunk/A/alpha.txt:4-5
> >
> > Notice that the 'svn propget' on alpha.txt indicates that there is no
> > svn:mergeinfo property available, but it gets added to beta.txt during the
> > rename.
> >
> > Is this intended behavior?

I think the rationale for creating this mergeinfo is that Subversion cannot
tell whether you're creating a copy of something (which will not receive
merges directly) within a branch, or creating a subtree-branch (which will
directly receive merges).

Consider a two-level branching scenario:

A branch is created:

 svn cp ^/trunk/ ^/branches/mybranch

This branch is synced to trunk periodically.
Then later someone decides to branch a subtree of this branch (this
is very different from branching the entire branch again!):

 svn cp ^/branches/mybranch/foo/bar ^/branches/mybranch/foo/bar-experimental

The bar-experimental branch now inherits explicit mergeinfo from
the ^/branches/mybranches directory, say /trunk:40-50.
I suppose this is done to prevent further merges from trunk (or subtrees of
trunk) into bar-experimental from merging changes which have already been
merged into foo/bar (the ancestor branch of foo/bar-experimental).

Whether the subtree-branch is just one file or a directory seems to be
irrelevant.

Now, this scenario doesn't really make a lot of sense in terms of a
reasonable branching/merging strategy. Documenting and justifying all
necessary merge steps for a strategy gets complex with subtree-branches.
It raises a lot of questions.

Where do you sync the subtree-branch to -- just its ancestor, or does it also
do more merges from trunk? If so, how do developers decide where to merge from?

Merges done into the subtree-branch affect the top-level branch and vice versa.
When is it appropriate to merge into the subtree-branch and when should merges
into the top-level branch be preferred?

Should developers check out their working copies from the subtree-branch or
from the top-level, or both? Depending on what?

There are without doubt people out there who do things like this.
I'd say that in most cases where subtree branching is done as above,
it's not done according to some predefined branching/merging strategy,
but because of people not knowing what they're doing.

There are variants of this problem. The copy must not be a child of
its parent, i.e. something like this could be done, too:

 svn cp ^/branches/mybranch/foo/bar ^/branches/mybarbranch

Also, you could copy something "interesting" (maybe a new module someone
else is developing) from another branch. This subtree branch that will be
synced to its origin periodically so that both branches share a common set
of code that isn't available on any other branch:

 svn cp ^/branches/anotherbranch/foo/bar ^/branches/mybranch/foo/bar

I suppose that is one compelling reason for subtree-branching, in places
where the mainline is over-protected so reintegration of a branch that
has interesting things for other branches takes a lot of effort. Then
instead of merging interesting branches back into mainline for other branches
to pick up, people cherry-pick things from interesting branches into their
own branch as they see fit. I've seen this pattern a lot with former clear
case users (where this particular scenario works much better than it
does in Subversion).
This pattern likely gets hairy when one of the top-level branches gets
reintegrated into trunk and the other top-level branch syncs to trunk then.
I haven't tried but I think you'll get spurious conflicts (see
http://subversion.tigris.org/issues/show_bug.cgi?id=2897).

So there are some remotely reasonable use cases for 

Re: Mail-Copies-To (was: Re: Can't see the wood for the trees)

[Ryan Schmidt]

On Nov 19, 2010, at 03:06, Gary wrote:

> I'd have appreciated it even more if you had
> followed the "Mail-Copies-To: never" header.

I cannot find any RFC specifying that header. All I can find is the 
"Mail-Copies-To Draft" from 1999, and it seems to apply only to NNTP 
newsreaders. In fact it says "The presence or absence of this header MUST NOT 
have any effect when a reply is sent by e-mail instead of posted [to a 
newsgroup]."

http://www.newsreaders.com/misc/mail-copies-to.html

Certainly my email program (the one that is included with Mac OS X) provides me 
with no special indication that you have set this header, and I'm not about to 
view the raw headers of every email I read before replying to see if some 
obscure header has been set.


If you don't wish to receive copies of replies on the list, one possible 
solution is to set the Reply-To header of your outgoing mail to the list's 
address.

Re: Can't see the wood for the trees (or: what are my branches called?)

[Arpad Ilia]

> Is there any way of finding out what branches I have created? I did look
> at the "red book" but it seems like there isn't anything, at least not
> where I expected to find it.

Assuming you placed your branches in 'branches':

svn list [URL]/branches


Arpad Ilia

RE: Can't see the wood for the trees (or: what are my branches called?)

[Giulio Troccoli]

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Gary [mailto:subversion-u...@garydjones.name]
> Sent: 19 November 2010 08:32
> To: users@subversion.apache.org
> Subject: Can't see the wood for the trees (or: what are my
> branches called?)
>
> Is there any way of finding out what branches I have created?
> I did look at the "red book" but it seems like there isn't
> anything, at least not where I expected to find it.

You can use the ls command, probably with a depth of immediate, recursively 
until you find what you want:

svn ls --depth immediate http://url.to.repo

This will give you the list of directories at the root of your repository. Then 
you go deeper

svn ls --depth immediate http://url.to.repo/branches

Assuming branches is one of the folder in the root of the repository you want 
to investigate.

G

Re: svn checkout/update fails with svn: Decompression of svndiff data failed: size too large error

[Christian Unger]

try this:
http://www.szakmeister.net/fsfsverify/


On 19.11.2010, at 07:04, Rajesh Menakath wrote:

> Hi,
>  
>   Recently we upgraded our svn server/client from 1.6.2 to 1.6.13, and since 
> then, we are encountering the following error when a user tries to 
> checkout/update a svn resource, where he has the required access (both read 
> and write).
>  
> svn: REPORT of '/svnrepository/!svn/vcc/default': 200 OK 
> (http://10.1.121.199) -> this was with http protocol, and found the below 
> errors in apache error logs:
>  
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Provider encountered 
> an error while streaming a REPORT response.  [500, #0]
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] A failure occurred 
> while driving the update report editor  [500, #185005]
> [Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Decompression of 
> svndiff data failed: size too large  [500, #185005]
>  
> When I tried to do the same activity with svn protocol, I got the below error:
>  
> svn: Decompression of svndiff data failed: size too large
>  
> The weirdest part is that, it checks out the folder, but not the contents of 
> the folder, and then throws the error mentioned (for both svn and http 
> protocol).
>  
> When I tried to checkout all the files in the subjected folder, with the help 
> of svnlook (svnlook –r  cat repository_path 
> file_path > testfile), I got the same error for one of the file.
> svnlook: Decompression of svndiff data failed: size too large
>  
> I could re-produce the error with both command line svn client, and tortoise 
> svn and in both windows (xp service pack 3), and linux (RHEL5) environments. 
> As mentioned earlier, both of our client and server are 1.6.13.
>  
> Please confirm, if this is a bug or not, and suggest a way forward, and let 
> me know if you need any more info.
>  
>  
> Regards,
>  
> Rajesh
>  
>  
> 
> 
> This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy 
> Comptech Private Limited is a limited liability company.
> 
> This email and any attachments are confidential, and may be legally 
> privileged and protected by copyright. If you are not the intended recipient 
> dissemination or copying of this email is prohibited. If you have received 
> this in error, please notify the sender by replying by email and then delete 
> the email completely from your system. Any views or opinions are solely those 
> of the sender.  This communication is not intended to form a binding contract 
> on behalf of Ivy Comptech Private Limited unless expressly indicated to the 
> contrary and properly authorised. Any actions taken on the basis of this 
> email are at the recipient's own risk.
> 
> Registered Office:
> 
> Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, 
> Hyderabad 500 033, Andhra Pradesh, India.
> 
> Registered number: 37994. Registered in India. A list of members' names is 
> available for inspection at the registered office.
> 
> 
> 


--
christian unger • pferdeweide  47 • 22589 hamburg, germany
---
fon +49 16090987304
fon +49 4097073763 • fax +49 4097073765

aim christian_un...@mac.com
skype c_unger

svn checkout/update fails with svn: Decompression of svndiff data failed: size too large error

[Rajesh Menakath]

Hi,

 

  Recently we upgraded our svn server/client from 1.6.2 to 1.6.13, and
since then, we are encountering the following error when a user tries to
checkout/update a svn resource, where he has the required access (both
read and write). 

 

svn: REPORT of '/svnrepository/!svn/vcc/default': 200 OK
(http://10.1.121.199  ) -> this was with http
protocol, and found the below errors in apache error logs:

 

[Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Provider
encountered an error while streaming a REPORT response.  [500, #0]

[Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] A failure
occurred while driving the update report editor  [500, #185005]

[Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Decompression of
svndiff data failed: size too large  [500, #185005]

 

When I tried to do the same activity with svn protocol, I got the below
error:

 

svn: Decompression of svndiff data failed: size too large

 

The weirdest part is that, it checks out the folder, but not the
contents of the folder, and then throws the error mentioned (for both
svn and http protocol).

 

When I tried to checkout all the files in the subjected folder, with the
help of svnlook (svnlook -r  cat
repository_path file_path > testfile), I got the same error for one of
the file.

svnlook: Decompression of svndiff data failed: size too large

 

I could re-produce the error with both command line svn client, and
tortoise svn and in both windows (xp service pack 3), and linux (RHEL5)
environments. As mentioned earlier, both of our client and server are
1.6.13. 

 

Please confirm, if this is a bug or not, and suggest a way forward, and
let me know if you need any more info.

 

 

Regards,

 

Rajesh

 

 


This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy 
Comptech Private Limited is a limited liability company.  

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. 
Any views or opinions are solely those of the sender.  This communication is 
not intended to form a binding contract on behalf of Ivy Comptech Private 
Limited unless expressly indicated to the contrary and properly authorised. Any 
actions taken on the basis of this email are at the recipient's own risk.

Registered office:
Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, 
Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered 
in India. A list of members' names is available for inspection at the 
registered office.