Hello,
I keep a local svn checkout in sync with a svn repository on the
server (without making any local changes).
I probably created the repository with subversion 1.6 (and also did
the checkout with the same version) and later upgraded both the
original repository and the checkout to version
On Thu, Jan 16, 2014 at 3:03 PM, Stefan Sperling wrote:
On Thu, Jan 16, 2014 at 02:49:56PM +0100, Mojca Miklavec wrote:
Is there any painless way to shrink the size of the local .svn folder
(other than deleting everything and fetching the whole 6 GB again)?
'svn cleanup'
http
Hi,
I was wondering whether -r REV SRC and SRC@REV in svn copy are
supposed to behave differently or not.
I was trying to recover a file that has already been deleted from the
repository, but using -r syntax failed to work while @REV completed
successfully:
svn copy -r 10
On Wed, Jan 15, 2014 at 10:19 PM, Ben Reser wrote:
On 1/15/14, 1:05 PM, Mojca Miklavec wrote:
I was wondering whether -r REV SRC and SRC@REV in svn copy are
supposed to behave differently or not.
Yes they have different behavior. You probably want to read about Peg and
Operative Revisions
On Wed, Jan 8, 2014 at 4:53 PM, Philip Martin wrote:
I get a problem with the checkout from your server using a trunk client.
Very occasionally the checkout works but most of the time the client
simply hangs while receiving the first file.
It appears that the client is sending the REPORT
On Wed, Jan 8, 2014 at 1:11 PM, Branko Čibej wrote:
Hi Mojca,
On 07.01.2014 20:58, Mojca Miklavec wrote:
(The other problem with Error retrieving REPORT is still a mystery
though.) Mojca
I'm assuming your server is somewhere on the IJS network. Can you please
ask the admins there if your
On Tue, Jan 7, 2014 at 12:41 PM, Philip Martin wrote:
Mojca Miklavec writes:
We have a server running Fedora which has recently been upgraded to
version 20 and it's now running
svn, version 1.8.5 (r1542147)
I have a bunch of repositories served over http protocol with public
read
On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote:
Mojca Miklavec writes:
Yes, there is still a problem after restarting Apache. Even though it
works for me at the moment and I tried fetching from multiple
locations and servers, other users are still experiencing the same
problem. Logs
On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote:
Mojca Miklavec writes:
On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote:
Mojca Miklavec writes:
Yes, there is still a problem after restarting Apache. Even though it
works for me at the moment and I tried fetching from multiple
On Tue, Jan 7, 2014 at 7:34 PM, Philip Martin wrote:
So you used dump/load to create a new repository and then replaced the
old repository with the new repository? If you did that while Apache
was running, without restarting Apache, then that explains the 'Corrupt
node-revision' error as you
On Tue, Jan 7, 2014 at 8:44 PM, Ryan Schmidt wrote:
On Jan 7, 2014, at 12:01, Mojca Miklavec wrote:
On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote:
Which version of Apache are you using? Which Apache MPM are you using?
Server version: Apache/2.4.7 (Unix)
I'm not sure how to check MPM
Hello,
We have a server running Fedora which has recently been upgraded to
version 20 and it's now running
svn, version 1.8.5 (r1542147)
I have a bunch of repositories served over http protocol with public
read access and limited commit access.
Shortly after the upgrade a weird behaviour
On Wed, Dec 21, 2011 at 13:21, Stefan Sperling wrote:
On Wed, Dec 21, 2011 at 06:07:05AM -0600, Ryan Schmidt wrote:
On Dec 20, 2011, at 06:08, Mojca Miklavec wrote:
Is there any way to prevent
deleting existing contents within the scope of command line arguments?
A workaround is to use
On Tue, Dec 20, 2011 at 01:43, Daniel Shahaf wrote:
Mojca Miklavec wrote on Mon, Dec 19, 2011 at 16:56:05 +0100:
May I ask for any hints of what could go wrong and how I could debug
the problem? I have seen various threads after searching with google,
but none of those that I checked provided
On Tue, Dec 20, 2011 at 02:34, Philip Martin wrote:
Mojca Miklavec writes:
svn ci -m some comment
svn: E175002: Commit failed (details follow):
svn: E175002: The POST request returned invalid XML in the response:
XML parse error at line 3: not well-formed (invalid token)
(/suite/!svn/me
Dear list,
I'm experiencing some weird behaviour with SVN 1.7. The following
sequence of commands fails to respect --depth=empty:
svn co --depth=empty http://foundry.supelec.fr/svn/metapost
svn up --depth=empty metapost/tags
(you can use 'anonymous' as a username) The first command runs
Dear list,
I'm experiencing some weird behaviour of SVN 1.7. The following
sequence of commands fails to respect --depth=empty:
svn co --depth=empty http://foundry.supelec.fr/svn/metapost
svn up --depth=empty metapost/tags
(you can use 'anonymous' as a username if it asks) The first
17 matches
Mail list logo
