Dear Pawel,
Could you try to install the command line tools in TortoiseSVN and then try
to cleanup in the command line?
Something like this:
cd /d [drive and path to your repository]
svn cleanup
If this works then you should report the error on the mailinglist of
TortoiseSVN, https://tortoisesvn
On Feb 14, 2019, at 11:04, Celso F wrote:
> ---
> Subversion Exception!
> ---
> Subversion encountered a serious problem.
> Please take the time to report this on the Subversion mailing list
> with as much information as possible about what
> you wer
Jan Marti wrote on Sun, 06 Jan 2019 00:32 +0100:
> But now, with Win10 instead of Win7 as reverse proxy, i get that error
> message:
>
>
>
> "An error occurred during authentication"
Check the error logs of both the proxy server and the backend httpd
server for more detailed error messages.
On Fri, Aug 11, 2017 at 08:58:46PM +, Blaine Whittle wrote:
> I'm a big fan of the auto tree conflict resolution feature.
>
> One optimization I'd like to suggest is after a tree conflict is found, and
> if the two branches share ancestry then branch move history search should be
> constrain
On Thu, Jul 14, 2016 at 04:56:21PM +, Bailey, Aaron wrote:
> Hey Stefan,
>
> I think I know what is going on, this is due to my lack of knowledge
> about the inner workings of Apache. I'm building subversion for an
> several older versions of Linux. I couldn't update the packages on
> several
x27;s worth the time to submit
something to their group?
Thank you for taking the time to respond,
Aaron
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Thursday, July 14, 2016 1:07 AM
To: Bailey, Aaron
Cc: users@subversion.apache.org
Subject: --EXTERNAL--Re: Bug Re
On Wed, Jul 13, 2016 at 05:37:36PM +, Bailey, Aaron wrote:
> This is an update to the reported issue below.
>
> It appears that calling the pre-processor macro svn_pool_create with an
> argument of NULL is done a lot in the Subversion code base. The comments in
> the APR function apr_pool_cr
This is an update to the reported issue below.
It appears that calling the pre-processor macro svn_pool_create with an
argument of NULL is done a lot in the Subversion code base. The comments in the
APR function apr_pool_create_ex in module memory/unix/apr_pools.c seems to
imply you shouldn't
Hi Vikram,
Hi Stefan,
Thank you for the response and clarification.
Yes, I'm using 1.7.19 and I'm with that issue.
And, I have tried installing CollabNet Subverion client 1.8.15 and I
get a different issue (svn: E175013:) as below. I don't think its a
credentials issue because it still fails
Hi Stefan,
Thank you for the response and clarification.
Yes, I'm using 1.7.19 and I'm with that issue.
And, I have tried installing CollabNet Subverion client 1.8.15 and I get a
different issue (svn: E175013:) as below. I don't think its a credentials
issue because it still fails with the same e
Hi Vikram,
Hi,
I'm also stuck with this same issue,
"svn up" makes svn segfaults and coring.
This started happening when I give
my new password set in my svn server.
Can some one please help on this?
Any help is highly appreciated.
Thanks
Vikram
Unfortunately the 1.7 branch is no longer suppor
Hi,
I'm also stuck with this same issue,
"svn up" makes svn segfaults and coring.
This started happening when I give
my new password set in my svn server.
Can some one please help on this?
Any help is highly appreciated.
Thanks
Vikram
Hi,
On Fri, Jan 08, 2016 at 11:44:49AM -0800, David Lowe wrote:
> On 2016Jan 7,, at 17:32, Ryan Schmidt wrote:
> >
> > During the build of Subversion 1.9.3, it calls the just-built svnversion
> > program. On OS X at least, this crashes because the just-built Subversion
> > libraries have not b
On 2016Jan 7,, at 17:32, Ryan Schmidt wrote:
>
> During the build of Subversion 1.9.3, it calls the just-built svnversion
> program. On OS X at least, this crashes because the just-built Subversion
> libraries have not been installed yet so they are not in their expected
> place. The crash cau
> -Original Message-
> From: edward.dauver...@gmail.com
> [mailto:edward.dauver...@gmail.com] On Behalf Of Edward d'Auvergne
> Sent: dinsdag 6 oktober 2015 12:21
> To: Edward d'Auvergne ; Greg Stein
> ; users@subversion.apache.org
> Subject: Re: Bug re
On Tue, Oct 06, 2015 at 12:20:47PM +0200, Edward d'Auvergne wrote:
> So setting MAGIC is having an effect, but Subversion is falling back,
> probably via a non-magic internal code path, to the default
> svn:mime-type of "application/octet-stream" for PNG and some other
> files.
If you don't allow
On 4 October 2015 at 13:32, Stefan Sperling wrote:
> On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote:
>> I would maybe suggest introducing an option for disabling the entire
>> automatic property subsystem, i.e. it combines both of these, and
>> overrides them. This is an intere
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
>
> > This whole discussion -in its many iterations- is one of the reasons why
I
> > never looked
On Mon, Oct 05, 2015 at 12:06:59AM +0200, Bert Huijben wrote:
> I'm not sure if I would call it a security problem when a user adds a file of
> their choosing to Subversion though :-)
Yes, typical SVN use cases are of no concern.
One case I could imagine where this might matter is some automated
On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote:
> is it really not a bug when:
>
> enable-auto-props = yes
>
> and:
>
> enable-auto-props = no
>
> both enable auto-props?
>
> Cheers,
>
> Edward
I think your best way forward is what Ryan suggested: Ensure svn:mime-t
On Oct 4, 2015, at 5:52 AM, Edward d'Auvergne wrote:
> So the following setting disables [auto-props]:
>
>enable-auto-props = no
>
> If a svn:mime-type was defined in the config file, this is now
> disabled. However in this case, [magic-auto-props] then decides to
> tag everything with svn
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zondag 4 oktober 2015 22:01
> To: Branko Čibej
> Cc: users@subversion.apache.org
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to avoid.
>
> On Sun,
On Sun, Oct 04, 2015 at 09:16:04PM +0200, Branko Čibej wrote:
> On the other hand, I am surprised that the logic that uses libmagic
> isn't turned off with 'enable-auto-props=no'. After all, using libmagic
> is just a convenient extension to the definitions in the [auto-props]
> section.
Recall th
On 04.10.2015 11:35, Ivan Zhakov wrote:
> On 2 October 2015 at 11:06, Edward d'Auvergne wrote:
>> Hi all,
>>
>> I was wondering if this should be considered a bug. At the FlightGear
>> project we have a 6 GB data svn repository for aircraft (
>> https://sourceforge.net/projects/flightgear/ ,
>> h
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zondag 4 oktober 2015 13:32
> To: Edward d'Auvergne
> Cc: Greg Stein ; users@subversion.apache.org
> Subject: Re: Bug report: The auto-props setting of svn:mime-type is
> impossible to
On Sun, Oct 04, 2015 at 12:52:33PM +0200, Edward d'Auvergne wrote:
> I would maybe suggest introducing an option for disabling the entire
> automatic property subsystem, i.e. it combines both of these, and
> overrides them. This is an interesting thought experiment - devise
> any name for such a t
]On 3 October 2015 at 13:19, Stefan Sperling wrote:
> On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote:
>> is it really not a bug when:
>>
>> enable-auto-props = yes
>>
>> and:
>>
>> enable-auto-props = no
>>
>> both enable auto-props?
>>
>> Cheers,
>>
>> Edward
>
> I thin
by the xml inventers was a safe decision.
Your files are just not 'generic xml', and should have a more specific type.
Bert
From: Ivan Zhakov
Sent: zondag 4 oktober 2015 11:35
To: Edward d'Auvergne
Cc: users@subversion.apache.org
Subject: Re: Bug report: The auto-props se
On 2 October 2015 at 11:06, Edward d'Auvergne wrote:
> Hi all,
>
> I was wondering if this should be considered a bug. At the FlightGear
> project we have a 6 GB data svn repository for aircraft (
> https://sourceforge.net/projects/flightgear/ ,
> https://sourceforge.net/p/flightgear/fgaddon/HEAD
On Sat, Oct 3, 2015 at 6:53 AM, Ryan Schmidt
wrote:
>
> On Oct 3, 2015, at 4:13 AM, Edward d'Auvergne wrote:
>
>> is it really not a bug when:
>>
>>enable-auto-props = yes
>>
>> and:
>>
>>enable-auto-props = no
>>
>> both enable auto-props?
>
> Obviously, "enable-auto-props = yes" should e
On Oct 3, 2015, at 4:13 AM, Edward d'Auvergne wrote:
> is it really not a bug when:
>
>enable-auto-props = yes
>
> and:
>
>enable-auto-props = no
>
> both enable auto-props?
Obviously, "enable-auto-props = yes" should enable auto-props and
"enable-auto-props = no" should disable the
On Oct 3, 2015, at 3:25 AM, Edward d'Auvergne wrote:
> On 2 October 2015 at 11:33, Stefan Sperling wrote:
>
>> - configure autoprops for *.xml in ~/.subversion/config to set
>> the svn:mime-type property to 'text/plain'.
>> Autoprops always override automatic detection with libmagic.
>
> Fr
On 3 October 2015 at 11:01, Greg Stein wrote:
> I do understand this, but this is not a "bug". It is how Subversion is
> designed to work. For strange edge cases, the xml people want content to be
> labeled application/xml rather than a text subtype. ... I *do* understand
> that this negatively im
I do understand this, but this is not a "bug". It is how Subversion is
designed to work. For strange edge cases, the xml people want content to be
labeled application/xml rather than a text subtype. ... I *do* understand
that this negatively impacts your development workflow.
Note that you can alw
On 3 October 2015 at 01:05, Greg Stein wrote:
> On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
>>...
>> As this bad behaviour can be so incredibly damaging for this
>> repository,
>
> Note: the files themselves are not "damaged" -- Subversion will never
> alter the contents of
On 2 October 2015 at 12:30, Philip Martin wrote:
> "Edward d'Auvergne" writes:
>
>> I was wondering if there was anything that has been missed here? Is
>> this a real bug? The svn:mime-type property is not needed and is not
>> desired for any file in this repository. Any help would be
>> appre
On 2 October 2015 at 11:33, Stefan Sperling wrote:
> On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
>> Hi all,
>>
>> I was wondering if this should be considered a bug. At the FlightGear
>> project we have a 6 GB data svn repository for aircraft (
>> https://sourceforge.net/pr
On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
>...
> As this bad behaviour can be so incredibly damaging for this
> repository,
Note: the files themselves are not "damaged" -- Subversion will never
alter the contents of a file when it is first imported/added. It may
make a fil
"Edward d'Auvergne" writes:
> I was wondering if there was anything that has been missed here? Is
> this a real bug? The svn:mime-type property is not needed and is not
> desired for any file in this repository. Any help would be
> appreciated.
You can disable libmagic by setting the environm
On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
> Hi all,
>
> I was wondering if this should be considered a bug. At the FlightGear
> project we have a 6 GB data svn repository for aircraft (
> https://sourceforge.net/projects/flightgear/ ,
> https://sourceforge.net/p/flightgea
On 16.09.2015 14:31, Stefan Sperling wrote:
> On Wed, Sep 16, 2015 at 12:08:33PM +, Wolfram, Dirk wrote:
>>> I agree that the use of the svn:keywords "URL" has to effect a file's
>>> contents if $URL$ is used and therefore the timestamp has to be changed as
>>> well.
>>>
>>> But even if the $
On Wed, Sep 16, 2015 at 12:08:33PM +, Wolfram, Dirk wrote:
> > I agree that the use of the svn:keywords "URL" has to effect a file's
> > contents if $URL$ is used and therefore the timestamp has to be changed as
> > well.
> >
> > But even if the $URL$ keyword is not set and the file contents
On Tue, Sep 15, 2015 at 06:57:43PM +, Wolfram, Dirk wrote:
> Hi all,
>
> I'd like to file a bug in Subversion 1.9.1 and 1.9.0, but I'm not sure if
> it's a deliberate behavior.
> The problem was not encountered in Subversion 1.7.6, which we used for a long
> time.
> I didn't find anything co
Hi Milen,
Hi all,
I'm getting an Assert exception in all recent versions. Tried with 1.9
too and the same...
Steps to reproduce:
1. On the root checkout folder do a "Show Log"
2. Select a previous revision.
3. Select a modified file, right click and select "Revert Changes From
This Revision"
Markus Kuhn writes:
> SUMMARY:
>
> svndumpfilter (version 1.8.8) rearranges the order of Node records
> in Revision records in its output, and as a result, the Node-path:,
> which the specification says MUST come first, often appears not
> as the first record. This can corrupt data when the outpu
Hi,
On 02/02/15 17:14, Markus Kuhn wrote:
> BUG REPORT:
>
> SUMMARY:
>
> svndumpfilter (version 1.8.8) rearranges the order of Node records
Fixed since May 2014,
See https://svn.apache.org/repos/asf/subversion/tags/1.8.9/CHANGES :
* svndumpfilter: fix order of node record headers (r1578670
I'm guessing you see a combination of a few bugs. The internal canonical format
of URLs requires that you use the file://D:/none/existing form and no
backslashes. The argument parser should probably convert this for you or
produce a proper error.
After that all the internal code requires the i
Hi;
I had an extremely unstable connection.
I had troubles both with updates and commit; sorry, I do not
remember if this crash was for one or the other.
Best regards,
Olivier
2014-08-20 5:07 GMT+08:00 Ryan Schmidt :
>
> On Aug 18, 2014, at 12:33 AM, Olivier Teytaud wrote:
> >
> > please find en
On Aug 18, 2014, at 12:33 AM, Olivier Teytaud wrote:
>
> please find enclosed the bug report automatically generated by SVN during
> my best svn-crash ever.
What were you doing with svn when this crash occurred?
2014-03-15 11:24 GMT+01:00 Bert Huijben :
> This merge will cause the segfault with --force, while the merge succeeds
> without problems without the --force.
>
> The problem is fixed on trunk in r1577812, but that doesn't remove my
> recommendation of stopping to use --force with 1.8.
Thanks for f
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: zaterdag 15 maart 2014 10:31
> To: 'Stefan Sperling'; 'Danilo Piazzalunga'
> Cc: users@subversion.apache.org
> Subject: RE: Bug report: svn assert failure: svn:
&
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: zaterdag 15 maart 2014 10:03
> To: 'Stefan Sperling'; 'Danilo Piazzalunga'
> Cc: users@subversion.apache.org
> Subject: RE: Bug report: svn assert failure: svn:
&
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: zaterdag 15 maart 2014 09:45
> To: Danilo Piazzalunga
> Cc: users@subversion.apache.org
> Subject: Re: Bug report: svn assert failure: svn:
> subversion/libsvn_client/merge.c:3128: merge_d
On Fri, Mar 14, 2014 at 10:53:05PM +0100, Danilo Piazzalunga wrote:
> Hi all,
> I am asking for confirmation before reporting a bug
>
> Using Subversion 1.8.8 installed from Ubuntu 14.04 packages, svn
> crashed while performing a merge operation involving a replaced
> directory.
>
> I already rep
Did you read the documentation about adding issues?
Adding an issue isn't part of the process of getting an issue resolved.
So, do you want to be able to find it in a few years?
Or do you want to see it fixed?
If you only want to see it remembered, you can add an issue. But if you want to
h
onal information.
-Original Message-
From: Ben Reser [mailto:b...@reser.org]
Sent: Thursday, December 12, 2013 3:37 PM
To: Nguyen, Quyen; users@subversion.apache.org
Cc: Vornbrock, Beth
Subject: Re: Bug report on SVN 1.8.3 Cannot allocate Memory
On 12/12/13 2:12 PM, Nguyen, Quyen wrote:
>
> We will get with our System Admin and see what is going there.
The command "dmesg" might also give a clue on Linux systems.
regards Henrik
Guten Tag Nguyen, Quyen,
am Donnerstag, 12. Dezember 2013 um 23:12 schrieben Sie:
> svn: E165002: Failed to start '/../../../hooks/start-commit' hook
It may help to provide your hook's source to the list, just in case
there's an error in it like a wrong shebang, wrong line endings or
stuff like t
: Bug report on SVN 1.8.3 Cannot allocate Memory
On 12/12/13 2:12 PM, Nguyen, Quyen wrote:
> Looking into the subversion error_log and it appears it point to the
> memory
>
> [Mon Nov 18 17:28:53 2013] [error] [client 10.20.36.51] Can't start
> process
> '/data00st
On 12/12/13 2:12 PM, Nguyen, Quyen wrote:
> Looking into the subversion error_log and it appears it point to the memory
>
> [Mon Nov 18 17:28:53 2013] [error] [client 10.20.36.51] Can't start process
> '/data00start-commit': Cannot allocate memory [500, #12]
That is an OS error. Subversion
> -Original Message-
> From: Alexander Lüders [mailto:a...@entimo.de]
> Sent: vrijdag 24 mei 2013 14:48
> To: users@subversion.apache.org
> Subject: Bug report for Subversion 1.7.9
>
> Dear Subversion support team,
>
> I want to file a bug report affecting Subversion 1.7.9.
>
> In our
On Fri, Feb 15, 2013 at 12:21:16PM +0100, Diggory Hardy wrote:
> Dear list,
>
> I have an old checkout of an svn repo. This results in:
>
> L10036 mmBackend$ svn info
> svn: E155036: Please see the 'svn upgrade' command
> svn: E155036: Working copy '/home/dhardy/code/all/mmBackend' is too old
>
Diggory Hardy wrote on Fri, Feb 15, 2013 at 12:21:16 +0100:
> Ideally 'svn info' and 'svn st' should work on old checkouts without
> requiring
> any changes (upgrades or other) to them.
Yes we know, and we would have liked that too. It just wasn't possible
to implement in a timely or maintainab
On Fri, Aug 24, 2012 at 10:40 AM, Stefan Sperling wrote:
> This bug has already been fixed in Subversion 1.7.
>
Glad to hear that! Thanks and sorry for the duplicate.
-Archie
--
Archie L. Cobbs
On Fri, Aug 24, 2012 at 09:34:09AM -0500, Archie Cobbs wrote:
> Hi,
>
> I'm following instructions by reporting a bug here first. I'm not
> subscribed to this list and unfortunately don't have time to participate in
> a discussion.
>
> Version:
>
> svn, version 1.6.18 (r1303927)
>
> Problem:
>
On 5/24/2012 2:49 PM, Johan Corveleyn wrote:
On Thu, May 24, 2012 at 1:27 PM, Alex Siyanko wrote:
In a meantime I've tried to import '/A/tags/1.0' folder in place of
'/A/tags/1.0/file.txt':
i.e. used:
svn propset svn:externals " -r1 ^/A/tags/1.0 import" .
instead of:
svn propset svn:external
On Thu, May 24, 2012 at 1:27 PM, Alex Siyanko wrote:
> In a meantime I've tried to import '/A/tags/1.0' folder in place of
> '/A/tags/1.0/file.txt':
>
> i.e. used:
> svn propset svn:externals " -r1 ^/A/tags/1.0 import" .
>
> instead of:
> svn propset svn:externals " -r1 ^/A/tags/1.0/file.txt file
On 5/24/2012 10:52 AM, Johan Corveleyn wrote:
On Thu, May 24, 2012 at 1:57 AM, Alex Siyanko wrote:
On 5/23/2012 5:15 PM, Johan Corveleyn wrote:
On Mon, May 21, 2012 at 2:41 PM, Alex Siyankowrote:
On 5/21/2012 1:45 PM, Johan Corveleyn wrote:
On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko
On 5/24/2012 10:52 AM, Johan Corveleyn wrote:
On Thu, May 24, 2012 at 1:57 AM, Alex Siyanko wrote:
On 5/23/2012 5:15 PM, Johan Corveleyn wrote:
On Mon, May 21, 2012 at 2:41 PM, Alex Siyankowrote:
On 5/21/2012 1:45 PM, Johan Corveleyn wrote:
On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko
On Thu, May 24, 2012 at 1:57 AM, Alex Siyanko wrote:
> On 5/23/2012 5:15 PM, Johan Corveleyn wrote:
>>
>> On Mon, May 21, 2012 at 2:41 PM, Alex Siyanko wrote:
>>>
>>> On 5/21/2012 1:45 PM, Johan Corveleyn wrote:
>>>
>>> On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko wrote:
>>>
>>> Hello,
>>>
>>>
On 5/23/2012 5:15 PM, Johan Corveleyn wrote:
On Mon, May 21, 2012 at 2:41 PM, Alex Siyanko wrote:
On 5/21/2012 1:45 PM, Johan Corveleyn wrote:
On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko wrote:
Hello,
I've stumbled upon the following Subversion client 1.7.x bug:
Under certain conditions
On Mon, May 21, 2012 at 2:41 PM, Alex Siyanko wrote:
> On 5/21/2012 1:45 PM, Johan Corveleyn wrote:
>
> On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko wrote:
>
> Hello,
>
> I've stumbled upon the following Subversion client 1.7.x bug:
>
> Under certain conditions SVN silently fails to fetch extern
On 5/21/2012 1:45 PM, Johan Corveleyn wrote:
On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko wrote:
Hello,
I've stumbled upon the following Subversion client 1.7.x bug:
Under certain conditions SVN silently fails to fetch external file at
specified operative revision from repository into a work
On Sat, May 19, 2012 at 5:59 PM, Alex Siyanko wrote:
> Hello,
>
> I've stumbled upon the following Subversion client 1.7.x bug:
>
> Under certain conditions SVN silently fails to fetch external file at
> specified operative revision from repository into a working copy.
> Here is the simplest scena
"Kayhadrin!" writes:
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.5\ext\subversion\subversion\libsvn_wc\wc_db.c'
> line 4501: assertion failed (affected_rows == 1)
> ---
> OK
> ---
>
> When I click on the OK button of this dialog windo
On Mon, Oct 24, 2011 at 04:20:33PM +0200, Andreas Tscharner wrote:
>
> [snip]
>
> > Anyway, the same error happens with TortoiseSVN and
> > Subversion 1.7.1, so
> > is my assumption correct, that this was an error during the
> > working copy
> > upgrade process from 1.6 to 1.7 and is not fixed by
To clarify, these were my steps:
1. upgrade a 1.6 working copy to version 1.7 using Subversion 1.7.0
2. update the working copy using Subversion 1.7.0, error occured
(workqueue.c line 672: assertion failed (checksum != NULL) )
3. perform a cleanup on the working copy using Subversion 1.7.0, same
[snip]
> Anyway, the same error happens with TortoiseSVN and
> Subversion 1.7.1, so
> is my assumption correct, that this was an error during the
> working copy
> upgrade process from 1.6 to 1.7 and is not fixed by updating
> Subversion
> but only by checking out a fresh working copy (or performi
Sorry, it was too early in the morning for me to search the mailing list
archive and see that the problem was already posted a hundred times
(and, for that matter, fixed too...). Shame on me...
Anyway, the same error happens with TortoiseSVN and Subversion 1.7.1, so
is my assumption correct, t
On Thu, Oct 13, 2011 at 00:12, A. Kudryashov wrote:
>
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
> found_md5_checksum))
>
>
If you'd read the whole error message
Guten Tag A. Kudryashov,
am Donnerstag, 13. Oktober 2011 um 06:12 schrieben Sie:
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1935: assertion failed (svn_checksum_match(entry_md5_checksum,
> found_md5_checksum))
Bad thing.
Mit freundl
On Tue, December 7, 2010 09:58, Daniel Shahaf wrote:
> David Dyer-Bennet wrote on Tue, Dec 07, 2010 at 09:30:45 -0600:
>> On Tue, December 7, 2010 09:03, Daniel Shahaf wrote:
>> > David Dyer-Bennet wrote on Tue, Dec 07, 2010 at 08:44:28 -0600:
>> >> And, in any case, VISUAL is a public interface,
[David Dyer-Bennet]
> as I said in my initial post, I first discovered this on Windows
> under Cygwin. Avoiding "c:/Program Files" and "c:/Documents and
> Settings/david.dyer-bennet/My Documents" involves contortions and
> leaves you putting things in unusual places.
Well, or calling them C:/PRO
David Dyer-Bennet wrote on Tue, Dec 07, 2010 at 09:30:45 -0600:
> On Tue, December 7, 2010 09:03, Daniel Shahaf wrote:
> > David Dyer-Bennet wrote on Tue, Dec 07, 2010 at 08:44:28 -0600:
> >> And, in any case, VISUAL is a public interface, and I wonder how many
> >> other applications would break i
On Tue, December 7, 2010 09:03, Daniel Shahaf wrote:
> David Dyer-Bennet wrote on Tue, Dec 07, 2010 at 08:44:28 -0600:
>> On Tue, December 7, 2010 04:18, Julian Foad wrote:
>> > On Tue, 2010-12-07, Daniel Shahaf wrote:
>> >> I suppose setting VISUAL="\"/path with spaces/to/editor/binary\"" is
>> t
[David Dyer-Bennet]
> >> I suppose setting VISUAL="\"/path with spaces/to/editor/binary\"" is the
> >> easiest solution --- it requires no code changes so it will work with
> >> any svn binary out there.
> >
> > Yes, I think that's the best solution.
>
> And, in any case, VISUAL is a public inter
David Dyer-Bennet wrote on Tue, Dec 07, 2010 at 08:44:28 -0600:
> On Tue, December 7, 2010 04:18, Julian Foad wrote:
> > On Tue, 2010-12-07, Daniel Shahaf wrote:
> >> I suppose setting VISUAL="\"/path with spaces/to/editor/binary\"" is the
> >> easiest solution --- it requires no code changes so it
On Tue, December 7, 2010 04:18, Julian Foad wrote:
> On Tue, 2010-12-07, Daniel Shahaf wrote:
> I confirmed that there was a bug in that report, but that was on Windows
> and the evidence there was that the arguments were not being parsed
> correctly even when the space was escaped with the "^" c
On Tue, 2010-12-07, Daniel Shahaf wrote:
> CC += dev@
>
> Daniel Näslund wrote on Mon, Dec 06, 2010 at 21:32:39 +0100:
> > On Mon, Dec 06, 2010 at 01:44:23PM -0600, David Dyer-Bennet wrote:
> > > Subversion 1.6.12 running on Centos 5.5
> > >
> > > If the value of the environment variable VISUAL c
CC += dev@
Daniel Näslund wrote on Mon, Dec 06, 2010 at 21:32:39 +0100:
> On Mon, Dec 06, 2010 at 01:44:23PM -0600, David Dyer-Bennet wrote:
> > Subversion 1.6.12 running on Centos 5.5
> >
> > If the value of the environment variable VISUAL contains a space,
> > subversion fails when attempting t
On Mon, Dec 06, 2010 at 01:44:23PM -0600, David Dyer-Bennet wrote:
> Subversion 1.6.12 running on Centos 5.5
>
> If the value of the environment variable VISUAL contains a space,
> subversion fails when attempting to invoke the editor to get the
> comment.
>
> sh-3.2$ export VISUAL="/home/spaces
Paul Maier wrote on Wed, Oct 20, 2010 at 01:55:30 +0200:
> [Sorry, in my previous posting I forgot to mention the svn lock command.
> Here the corrected version of my posting.]
>
> Hi Daniel,
>
> I just ran into something, that might already be fixed with your r1023571,
> but I think it is worth
'Daniel Shahaf' wrote on Mon, Oct 18, 2010 at 00:24:13 +0200:
> Paul Maier wrote on Sun, Oct 17, 2010 at 22:30:23 +0200:
> > svn cp svn://./a b
> > should also leave file b as read-write, doesn't it?
> >
>
> Should, but doesn't.
>
Fixed in r1023647, using the very same approach I originally
Paul Maier wrote on Sun, Oct 17, 2010 at 22:30:23 +0200:
> Hi Daniel,
>
> thanks for having taken over this idea.
>
No problem.
> One question:
> Does your solution code and testing code also cover the case when the copy
> source is a URL?
>
> svn cp svn://./a b
> should also leave file
Stefan Sperling wrote on Sun, Oct 17, 2010 at 20:54:41 +0200:
> On Sun, Oct 17, 2010 at 04:30:41PM +0200, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Sun, Oct 17, 2010 at 14:43:57 +0200:
> > > Your patch seems to handle copies only. What about locally added files?
> >
> > Does this part of t
On Sun, Oct 17, 2010 at 04:30:41PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Sun, Oct 17, 2010 at 14:43:57 +0200:
> > Your patch seems to handle copies only. What about locally added files?
>
> Does this part of the regression patch cover the scenario you have in mind?
Yup. It does c
Stefan Sperling wrote on Sun, Oct 17, 2010 at 14:43:57 +0200:
> Your patch seems to handle copies only. What about locally added files?
Does this part of the regression patch cover the scenario you have in mind?
Index: subversion/tests/cmdline/lock_tests.py
===
On Sun, Oct 17, 2010 at 05:24:49AM +0200, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Sun, Oct 17, 2010 at 05:09:37 +0200:
> > Index: subversion/libsvn_wc/copy.c
> > ===
> > --- subversion/libsvn_wc/copy.c (revision 1023400)
> >
Daniel Shahaf wrote on Sun, Oct 17, 2010 at 05:09:37 +0200:
> Index: subversion/libsvn_wc/copy.c
> ===
> --- subversion/libsvn_wc/copy.c (revision 1023400)
> +++ subversion/libsvn_wc/copy.c (working copy)
> @@ -238,6 +238,1
Stefan Sperling wrote on Sat, Oct 16, 2010 at 15:40:46 +0200:
> On Fri, Oct 15, 2010 at 10:13:48PM +0200, Paul Maier wrote:
> > svn cp should always make the target file read-write in the
> > working copy.
>
> No. A plain copy should carry file permissions of its source along,
> just like a normal
1 - 100 of 102 matches
Mail list logo
