I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn:
E120104: ra_serf: An error occurred during decompression" error as
often at the moment. Have seen it a few times.
But I do intermittently get several different errors as show below.
- Note that I am running the command over and
On Tue, Sep 10, 2013 at 8:39 PM, Ben Reser wrote:
> On 9/10/13 2:31 PM, Curt Sellmer wrote:
>> After giving it more time I can now reproduce the problem with both
>> version 1.8.0 and 1.8.3 of the client. And I have now seen the
>> problem with both the older and newer versions of the repository.
On 9/10/13 2:31 PM, Curt Sellmer wrote:
> After giving it more time I can now reproduce the problem with both
> version 1.8.0 and 1.8.3 of the client. And I have now seen the
> problem with both the older and newer versions of the repository.
> Very hard to debug as it does not seem to follow any
On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn wrote:
> [ Please use reply all to keep the list in the loop -- I'm sending
> this to users@ rather than dev@, because other users might also be
> interested and/or can chime in if someone has similar issues.
> Also, this list prefers bottom-posting
On Tue, Sep 10, 2013 at 4:36 PM, Bob Archer wrote:
>
>> >>Also part of the reason to split up the repos is to make access
>> >>control easier, and it looks bad if Alice (who should have access to
>> >>project 1 but not project 2) can see Bob's old commit metadata to
>> >>project 2, even if she
> -Original Message-
> From: t...@elba.apache.org [mailto:t...@elba.apache.org] On Behalf Of Trent
> W. Buck
> Sent: Monday, September 09, 2013 11:38 PM
> To: users@subversion.apache.org
> Subject: Re: Breaking up a monolothic repository
>
> Les Mikesell writes:
>
> > On Mon, Sep 9, 2013
On Tue, Sep 10, 2013 at 09:59:27AM -0500, Benjamin Fritz wrote:
> I'm referring to files with an 'R' status in 'svn log'.
>
> I want to see the changes between the new file, and the file that it replaced.
'svn diff' does that by default. You have to use the --notice-ancestry
option to force svn no
On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer wrote:
> On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn wrote:
>> [ Please use reply all to keep the list in the loop -- I'm sending
>> this to users@ rather than dev@, because other users might also be
>> interested and/or can chime in if someone h
On 9/10/2013 7:22 AM, Nico Kadel-Garcia wrote:
But keeping thousands of empty commits in a project they're not relevant
to is confusing and wasteful. The repository and repository URL's for
the old project should be preserved, if possible, locked down and
read-only, precisely for this kind of ch
[ Please use reply all to keep the list in the loop -- I'm sending
this to users@ rather than dev@, because other users might also be
interested and/or can chime in if someone has similar issues.
Also, this list prefers bottom-posting or inline replying, so I've
rearranged to put your reply at the
On Tue, Sep 10, 2013 at 6:22 AM, Nico Kadel-Garcia wrote:
>>
> Even if the history is considered sacrosanct (and this is often a
> theological policy, not an engineering one!), an opportunity to reduce the
> size of each reaporitory by discarding deadwood at switchover time should be
> taken serio
I'm referring to files with an 'R' status in 'svn log'.
I want to see the changes between the new file, and the file that it replaced.
I can use 'svn cat' to get the old file and then compare it to the new
one, but I am hoping there is a way to have SVN run the diff for me in
one step like it can
Simon Wilson writes:
> Subversion 1.8 throws up errors when I specify HTTP/HTTPS URLs that
> contain usernames to svn, i.e.
>
> svn --username user ls https://server.com/repos/project/
>
> works fine but
>
> svn ls https://u...@server.com/repos/project/
>
> results in errors. The same URL wor
> Have you checked if the users have/need anything (emails, ticket
system, etc.) that refer to specific revisions or the history of
changes made there? It seems kind of drastic to throw that away
because you think the numbers aren't pretty enough.
But keeping thousands of empty commits in a pro
On 9/9/2013 8:49 PM, Trent W. Buck wrote:
I'm partway through provisioning the replacement Debian 7 server, which
will have
subversion 1.6.17dfsg-4+deb7u3
apache22.2.22-13
...hm, still 1.6. Is it worth me backporting a newer svn?
Yes, it's worth installing 1.8.3.
http://www.
15 matches
Mail list logo
