Guten Tag ºÚÉÁÖ,
am Dienstag, 10. September 2013 um 01:07 schrieben Sie:
(5)invoke maked resolved menu,checked Resolve conflicts in local file
with my changes option, Test.java file content change bottom:
[...]
(6)My question is, why don't you into the following this?
Look at 5, you said you
Guten Tag Trent W. Buck,
am Dienstag, 10. September 2013 um 02:49 schrieben Sie:
...hm, still 1.6. Is it worth me backporting a newer svn?
I would give it a try, get yourself a current build of 1.8, dump your
old repo and load it into a newly created from your 1.8 version and
see how much
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.
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
Simon Wilson sepwil...@gmail.com 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
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
On Tue, Sep 10, 2013 at 6:22 AM, Nico Kadel-Garcia nka...@gmail.com 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
[ 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 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
On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer sellmer...@gmail.com wrote:
On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn jcor...@gmail.com 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
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 not
-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 lesmikes...@gmail.com writes:
On Mon,
On Tue, Sep 10, 2013 at 4:36 PM, Bob Archer bob.arc...@amsi.com 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
On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn jcor...@gmail.com 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
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
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
16 matches
Mail list logo
