On Thu, 2011-11-10 at 06:59 +, Cooke, Mark wrote:
>
> > The second problem is that we run trac, and (as recommended
> > by the trac project) use post-commit hooks to log repository
> > changes into the trac timeline. This fails when svn+ssh://
> > is used, as the process owner does not have p
> The second problem is that we run trac, and (as recommended
> by the trac project) use post-commit hooks to log repository
> changes into the trac timeline. This fails when svn+ssh://
> is used, as the process owner does not have permission to
> use trac-admin in that way.
...as a trac user (b
Hello!
Can you delete directories in your subversion repository? Yes, really?
You lucky bas! Joke:)
Anyway, joke aside, the following is no laughing matter.
It seems that upgrade from 1.6.17 to 1.7.1 exhibits some "undocumented
features":) Apparently server version 1.7 parses permissions
dif
On Wed, 2011-11-09 at 10:00 +, Philip Martin wrote:
> "Tony Butt" writes:
>
> > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote:
> >> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100:
> >> > I tried to edit the log message of a commit made with svn+ssh://, using
> >> > http:// ac
Hi,
Think I found a problem with svn 1.7.1 on Windows, where after a merge
and a tree conflict (annoying, since both dirs have same name), I ended
up with a file with status deleted (for unknown reason), and it seems
impossible to revert (undelete) this file.
I made a batch script where I be
Issue created http://subversion.tigris.org/issues/show_bug.cgi?id=4052
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 09 November 2011 17:57
To: Asmussen, Christian
Cc: users@subversion.apache.org
Subject: Re: Bug (svn 1.7.1) with reintegrate merge and deleted symb
-Original Message-
From: Markus Schaber [mailto:m.scha...@3s-software.com]
Sent: Tuesday, November 08, 2011 1:40 AM
To: Floeder, Joe; users@subversion.apache.org
Subject: AW: 1.7.1 working copies - verification
Hi, Joe,
Von: joe.floe...@sungard.com [mailto:joe.floe...@sungard.com]
> How
On Wed, Nov 09, 2011 at 04:13:56PM +0100, christian.asmus...@ubs.com wrote:
> Dear "Users",
>
>
>
> It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
> tree conflict when a -reintegrate merge is done back to trunk.
>
> The same merge done with svn 1.6.17 smoothly passes as
Thanks, Philip.
Looking forward to it. Now it takes me quite some extra time to work with SVN.
-Wabe
> From: philip.mar...@wandisco.com
> To: wabekoelm...@hotmail.com
> CC: users@subversion.apache.org
> Subject: Re: Error when updating
> Date: Thu, 3 Nov 2011 16:09:58 +
>
> Wabe W writes:
Dear "Users",
It seems that on svn 1.7.1 deleted symbolic links on a branch cause a
tree conflict when a -reintegrate merge is done back to trunk.
The same merge done with svn 1.6.17 smoothly passes as a normal
deletion.
See below a simple "script" to replicate the bug:
Around about 09/11/11 14:27, Stefan Podskubka typed ...
Isn't this the expected behaviour regarding the current state of the
svn:externals implementation?
Gah, you are, indeed, correct, and I'd even *read* that before, but
forgotten!
Thanks (to you & Philip) for correcting my numptiness!
Neil Bird writes:
> Am I just doing something wrong?
You are trying to make a file external point to a file in a different
repository, that is not supported.
--
Philip
-Original Message-
From: KARR, DAVID [mailto:dk0...@att.com]
Sent: 08 November 2011 20:31
To: users@subversion.apache.org
Subject: Good strategies for incorporating an external code drop
Subversion works fine when developers have access to the SVN repo. I'm working
on a project where
On 09.11.2011 12:39, Neil Bird wrote:
I have a local file in a WC. I have svn-deleted the local file and
re-added it as a file external from elsewhere (to the same WC location
using the immediate parent's svn:externals).
However, on update I now get an error along the lines of:
Updating 't
Around about 09/11/11 11:39, Neil Bird typed ...
Annoyingly I tried to re-create this with a dummy/example pair of repos, and
it all worked swimmingly.
Actually a typo. meant it wasn't reproducing the situation.
The attached script mostly reproduces the problem. I've got my repo.
into a
I have a local file in a WC. I have svn-deleted the local file and
re-added it as a file external from elsewhere (to the same WC location using
the immediate parent's svn:externals).
However, on update I now get an error along the lines of:
Updating 'tools':
Fetching external item into
Hi Uli,
Thanks for your reply.
Here I am explain my clarification in details.
Our Clients are using Latest SVN in our domain. They are using Red hat
Linux & They are accessing svn repository using Tortoise Client.
They have multiple branches in SVN repository. Each branches They have
arou
"Tony Butt" writes:
> On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote:
>> Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100:
>> > I tried to edit the log message of a commit made with svn+ssh://, using
>> > http:// access, and failed. Now the strange thing, after changing a
>> > diffe
> -Original Message-
> From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com]
> Sent: 09 November 2011 08:43
> To: users@subversion.apache.org
> Subject: Re: svn version in other format
>
> Am 09.11.2011 07:59, schrieb sureshkumar nandakumar:
> > I need SVN branch all the files al
Am 09.11.2011 07:59, schrieb sureshkumar nandakumar:
I need SVN branch all the files along with all the versions in zip or tar
format.
I Know using svn dump, we can take svn branch all the files along with
versions.
But it can be read only if we load any SVN repository.
Instead of loading the
Am 08.11.2011 21:30, schrieb KARR, DAVID:
Subversion works fine when developers have access to the SVN repo.
I'm working on a project where one of the developers for one of the
projects doesn't have access to our network. When he makes changes
he sends me a zip file with the new contents of the
21 matches
Mail list logo
