The relative path '.' is passed to is_canonical causing an assertion
failure in is_canonical when trying to sort the conflicts.
The minimal path to reproduce requires a conflict of at least 2 items. One
of the conflicts should be '.'.
Steps to reproduce:
# create and checkout a repo
svnadmin cr
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
---
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 were trying to do.
But please first search the mailing list
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
---
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 were trying to do.
But please first search the mailing list
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.
Bug report: Now i installed Windows 10 x64 Pro a new virtualisation host
system which also has a role as reverse proxy with IIS to use "Windows
Authentication", before i used Windows 7 x64 Pro. The settings on the SVN
apache webserver virtual machine are still the same...
But now,
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
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
constrained to the start revision of when the branch was made.
When testing the ne
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
status_t for good measure).
Thanks,
Aaron
From: Bailey, Aaron
Sent: Friday, July 08, 2016 11:45 AM
To: 'users@subversion.apache.org'
Subject: Bug Report Againgst Subversion 1.9.3 libsvn_subr
To Whom It May Concern,
This email is in regards to a potential software bug I've encountered in
To Whom It May Concern,
This email is in regards to a potential software bug I've encountered in
Subversion 1.9.3. I wasn't really able to find anything on the existing issue
tracker, however that may be due to my inability to get any useful information
out of it. As directed on the issues page
---
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 were trying to do.
But please first search the mailin
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
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 causes OS X to create a crash log file, which I've attached,
> -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
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/tree/ ). A large
quantity of the files, almost 30,000 in number
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
Hi Stefan,
sorry this was an accident.
Of course this mail should go to users@subversion.apache.org as well.
BR,
Dirk
-Ursprüngliche Nachricht-
Von: Stefan Sperling [mailto:s...@elego.de]
Gesendet: Mittwoch, 16. September 2015 13:32
An: Wolfram, Dirk
Betreff: Re: Bug Report: The &quo
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 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 concerning this issue in the change log.
Summary:
--
The "svn swit
nt_is_absolute(local_abspath))
I'd like to submit an additional bug-report for Tortoise SVN 1.9 now...
Any Save Dialog (e.g. Save revision to...) when tortoise SVN runs on a
client windows version (e.g. Windows 7) would cause the save dialog to
open and on top a message box says "You can
lute(local_abspath))
I'd like to submit an additional bug-report for Tortoise SVN 1.9 now...
Any Save Dialog (e.g. Save revision to...) when tortoise SVN runs on a
client windows version (e.g. Windows 7) would cause the save dialog to
open and on top a message box says "You can't op
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 he
BUG REPORT:
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 output of
svndumpfilter
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
Hello,
I found a bug of svnsync on Windows. It crashes when the target repo cannot
be found and the current folder is a repo. This bug can be reproduced with
the following commands:
mkdir my-repo
svnadmin create my-repo
cd my-repo
svnsync sync file:///D:\non\existent\folder
svnsync sync file:///
Hello,
I notice that svnsync on Windows crashes when the target url is a local
repository with a lower-case drive letter, such as:
svnsync sync file:///d:\
svnsync sync file:///d:\non\existent\folder
svnsync sync file:///d:\folder\without\a\repo
svnsync sync file:///d:\folder\with\a\valid\repo
; > 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?
>
>
>
--
=
Olivier Teytaud, INRIA TAO Research Fello
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?
Hi;
please find enclosed the bug report automatically generated by SVN during
my best svn-crash ever.
Best regards,
Olivier
--
=
Olivier Teytaud, INRIA TAO Research Fellow ---
http://www.slideshare.net/teytaud
"Please stop quoting
I encounter this bug for specific folders - not all.
I place the cursor on the folder, right-click and select Repro-browser. The
browser form loads the data and issues the exception below. After that I can
continue browsing. Cleanup do not solve the problem.
Best regards
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
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 reportted this bug to Ubuntu Launchpad as
https://bugs.launchpad.net/ubuntu/+source/sub
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
Hi,
We had subversion 1.8.3 installed on our test server.
svn, version 1.8.3 (r1516576)
compiled Aug 30 2013, 17:19:00 on x86_64-unknown-linux-gnu
The OS on this server is OS Red Hat Enterprise Linux Server release 6.3
(Santiago) .
Initially, testing 1.8.3 on this test server looks good but then
Dear Sir
We got this error "Can't parse lock/entries hashfile /foldername/filename.
Serialized hash missing terminator" in one of our repositories when trying
to browse or update the repository.Running svnadmin lslock on the
repository folder on the server also produced the same error message
> -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 Su
Dear Subversion support team,
I want to file a bug report affecting Subversion 1.7.9.
In our software system, we currently use Subversion 1.6 and recognized a
possible performance reduction (~ 15x times) in 1.7 concerning the deletion of
files using JavaHL.
Let's start describing
al files)? I see no easy way of checking this. I'll try installing
> an
> old version of svn, but I don't find this a satisfactory solution, hence this
> bug report.
Installing the old client is indeed the recommended workaround.
It is not very satisfactory for everyone, of co
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
d version of svn, but I don't find this a satisfactory solution, hence this
bug report.
Ideally 'svn info' and 'svn st' should work on old checkouts without requiring
any changes (upgrades or other) to them.
Best regards,
Diggory
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:
>
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:
There is a situation where $Id$ substitution is inconsistent. If you svn
copy and the
Hi all,
compiling kdewallet.cpp in the Subversion 1.7.5 distribution generates the
following errors with g++-4.7.x:
[QUOTE]
subversion/libsvn_auth_kwallet/kwallet.cpp: In function 'svn_boolean_t
kwallet_password_get(const char**, apr_hash_t*, const char*, const char*,
apr_hash_t*, svn_boolean_
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
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 scenario:
1) I create 'file.txt' and commit it to repository 'A/tru
"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
1 - 100 of 140 matches
Mail list logo
