Hi,
Thank you for your help.
br,
Pal
On Sun, 2 Apr 2023, 22:26 Daniel Sahlberg,
wrote:
> Den sön 2 apr. 2023 kl 20:08 skrev Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com>:
>
>> I've spent some time today looking at the issue. I've been able to
>> reproduce it, but my reproduction is not in a
Den sön 2 apr. 2023 kl 20:08 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:
> I've spent some time today looking at the issue. I've been able to
> reproduce it, but my reproduction is not in a shape where I can share it.
>
> Basically I've setup a server where the repository was hosted at
>
I've spent some time today looking at the issue. I've been able to
reproduce it, but my reproduction is not in a shape where I can share it.
Basically I've setup a server where the repository was hosted at
http://localhost/repo, configured an external. Then reconfigured the server
so the repositor
On Sat, Mar 11, 2023 at 4:29 PM Daniel Sahlberg
wrote:
> Den lör 11 mars 2023 kl 13:06 skrev Pál Kovács <81.kovacs...@gmail.com>:
>
>>
>>
>> Dear All,
>>
>> I'd like to setup http traffic to be redirected to https on our svn
>> server.
>> Redirection works all right in most of the cases, except w
Den lör 11 mars 2023 kl 13:06 skrev Pál Kovács <81.kovacs...@gmail.com>:
>
>
> Dear All,
>
> I'd like to setup http traffic to be redirected to https on our svn server.
> Redirection works all right in most of the cases, except when we have a
> file-external with http in the url.
> For file-extern
Dear All,
I'd like to setup http traffic to be redirected to https on our svn server.
Redirection works all right in most of the cases, except when we have a
file-external with http in the url.
For file-externals, svn export works as expected (in the export log it is
visible that there was a redir
Thanks Stefan. --accept=postpone sounds like just what I need.
I ended up discovering that if I committed an empty directory in the location
of the conflict, it would skip the deep history search, and show a different
tree conflict right away. So that got me out of waiting. But I'll try
--accep
On Tue, Aug 04, 2020 at 06:37:07PM +, Jacob Weber wrote:
> Hi there. I'm doing a merge which seems to be doing a very long-running
> operation (over an hour so far) when it gets to the "Searching tree conflict
> details" step. I'm wondering if there's any way to avoid this.
>
> I'm merging f
Hi there. I'm doing a merge which seems to be doing a very long-running
operation (over an hour so far) when it gets to the "Searching tree conflict
details" step. I'm wondering if there's any way to avoid this.
I'm merging from a branch X where a directory was removed, into a branch Y
where th
pts HTML, so I chose plain-text,
> but this does not allow adding screenshots, so for convenience you may simply
> look at the conversation at the TortoiseSVN google group, where I first
> posted about the possible bug in your svn library:
> https://groups.google.com/forum/#!topic/tor
ience you may simply look
at the conversation at the TortoiseSVN google group, where I first posted about
the possible bug in your svn library:
https://groups.google.com/forum/#!topic/tortoisesvn/qUoGtI8hxJ8
I have added the first and last message
Martin Wam writes:
> I'm having some issues with dbx, but was able to extract the following
> stacktrace:
>
> Segmentation fault in apr_palloc at line 681 in file
> "memory/unix/apr_pools.c" ($t1)
> 681 active = pool->active;
> (dbx) where
> apr_palloc(pool = 0xfffeee88, in_size = 20),
Philip Martin wandisco.com> writes:
>
> Martin Wam esito.no> writes:
>
> >> That looks as if it could be a problem with APR's mmap support on
AIX.
> >> Which version of APR are you using? Did you build the APR binaries
> >> yourself? Did whoever built the binaries run the APR regression
>
Martin Wam writes:
>> That looks as if it could be a problem with APR's mmap support on AIX.
>> Which version of APR are you using? Did you build the APR binaries
>> yourself? Did whoever built the binaries run the APR regression
>> tests?
>
> We are using apr version 1.5.1-1 downloaded from p
Philip Martin wandisco.com> writes:
>
> Martin Wam esito.no> writes:
>
> > We are also experiencing the same issues on AIX 7.1 (having tried
all
> > versions from 1.8.5 to 1.8.10). A backtrace from the coredump shows:
> >
> > Core was generated by `svn'.
> > Program terminated with signal SI
Martin Wam writes:
> We are also experiencing the same issues on AIX 7.1 (having tried all
> versions from 1.8.5 to 1.8.10). A backtrace from the coredump shows:
>
> Core was generated by `svn'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0xd82f169c in apr_palloc () from
> To: Ryan Schmidt
> > Subject: SV: Possible bug in subversion
> > Date: January 16, 2015 at 3:27:03 AM CST
> >
> > Hi,
> >
> > svn server version:
> >
> > svnserve --version
> > svnserve, version 1.8.5 (r1542147)
> > compiled N
I'm forwarding your response back to the list so that hopefully someone can
help you. Remember to use Reply All so that the discussion stays on the list.
Begin forwarded message:
> From: Jon-Erik TYVAND
> To: Ryan Schmidt
> Subject: SV: Possible bug in subversion
> Date: Janu
On Jan 15, 2015, at 4:10 AM, Jon-Erik TYVAND wrote:
> We use subversion on AIX 6.1 and it works perfectly! But on AIX 7.1 we get a
> Segmention fault(coredump) using svn co. We have tried several of the aix 7.1
> rpm supplied from perlz. Is this a known bug?
What versions of Subversion are yo
Hello,
We use subversion on AIX 6.1 and it works perfectly! But on AIX 7.1 we get a
Segmention fault(coredump) using svn co. We have tried several of the aix 7.1
rpm supplied from perlz. Is this a known bug?
test30:/home/rumo/tmp> svn co http://tvinnsvn:8080/svn/tvinn/trunk/dev/felles
Authenti
Benoit de Biolley writes:
> Do you will create an "improvement" in the issue tracker ?
It is now fixed on trunk.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
> From: philip.mar...@wandisco.com
> To: lepirlo...@hotmail.com
> CC: users@subversion.apache.org
> Subject: Re: Possible bug in error message E160020
> Date: Mon, 15 Dec 2014 11:10:59 +
>
> Benoit de Biolley writes:
>
> > this bugs is on the eror message tha
Benoit de Biolley writes:
> this bugs is on the eror message that outputs the source directory in place
> of the destination directory.
>
> when i'm executing this :
>
> "svn --non-interactive copy --file
> C:\Users\xxx\AppData\Local\Temp\maven-scm-1138477127.commit --revision 6237
> http://sv
this bugs is on the eror message that outputs the source directory in place of
the destination directory.
when i'm executing this :
"svn --non-interactive copy --file
C:\Users\xxx\AppData\Local\Temp\maven-scm-1138477127.commit --revision 6237
http://svn.xxx.be/xxx-svn/pow/trunk/
http://svn.xx
Overview of problem:
Using svn client 1.8.10 on Mac OSX 10.9.4, downloaded from wandisco.
When trying to sync trunk to a branch with the command: svn merge ^/trunk
I get the following error:
svn merge ^/trunk
svn: E195016: Reintegrate can only be used if revisions 3 through 6 were
previously merge
is< a
> problem when the binaries used aren't built using the same version of
> compiler (this is all theory at the moment of course)
>
> -Original Message-
> From: Steve Davis
> Sent: 03 February 2014 15:35
> To: 'Philip Martin'
> Cc: users@subve
of
compiler (this is all theory at the moment of course)
-Original Message-
From: Steve Davis
Sent: 03 February 2014 15:35
To: 'Philip Martin'
Cc: users@subversion.apache.org <mailto:users@subversion.apache.org>
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file lo
4 15:35
To: 'Philip Martin'
Cc: users@subversion.apache.org
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
All of the Apache and Subversion binaries came from the Bitnami download. I
could ask their support people exactly what compiler was used if you think that
would he
-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: 03 February 2014 15:34
To: Steve Davis
Cc: users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Steve Davis writes:
> Response:
>
> svn: E200035: sqlite[S19]: LOCK.lock_token may no
Steve Davis writes:
> Response:
>
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
> svn: E200035: Additional errors:
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
I can generate this error with the 1.8 client by patching mod_dav_svn to
return 400:
Index: sw/subversio
Any further feedback very much appreciated.
Thanks - Steve
-Original Message-
From: Ben Reser [mailto:b...@reser.org]
Sent: 01 February 2014 01:39
To: Steve Davis; users@subversion.apache.org
Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
On 1/31/14, 1:54 PM, Steve Davis wrot
[mailto:b...@qqmail.nl]
Sent: 02 February 2014 15:26
To: 'Ben Reser'; Steve Davis; users@subversion.apache.org
Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
> -Original Message-
> From: Ben Reser [mailto:b...@reser.org]
> Sent: zaterdag 1 februari 2014 0
> -Original Message-
> From: Ben Reser [mailto:b...@reser.org]
> Sent: zaterdag 1 februari 2014 02:39
> To: Steve Davis; users@subversion.apache.org
> Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
>
> On 1/31/14, 1:54 PM, Steve Davis wrote:
> &g
On 1/31/14, 1:54 PM, Steve Davis wrote:
> :: Attempted to lock the working file
> svn lock c:\dev\Testrepo\NewDoc.txt
>
> Response:
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
> svn: E200035: Additional errors:
> svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL
What if
Hi -
I have been trying to pin down the cause of an issue my users are seeing when
using SVN. It's actually a Windows Server 2008 R2 (64 bit) Bitnami-Redmine
stack of SVN, but I've tried to scrape it back to the most basic levels during
debugging, to hopefully omit any Bitnami-related issues.
On Thu, Jul 11, 2013 at 8:54 PM, Pavel Borzenkov
wrote:
> On Thu, Jul 11, 2013 at 8:35 PM, Stefan Sperling wrote:
>> On Thu, Jul 11, 2013 at 07:47:19PM +0400, Pavel Borzenkov wrote:
>>> Hi,
>>>
>>> after update to svn 1.8.0 I have 100% reproducible perl crash during
>>> 'git svn fetch' with the f
On Thu, Jul 11, 2013 at 8:35 PM, Stefan Sperling wrote:
> On Thu, Jul 11, 2013 at 07:47:19PM +0400, Pavel Borzenkov wrote:
>> Hi,
>>
>> after update to svn 1.8.0 I have 100% reproducible perl crash during
>> 'git svn fetch' with the following error (full backtrace + link to
>> core at the end of t
On Thu, Jul 11, 2013 at 07:47:19PM +0400, Pavel Borzenkov wrote:
> Hi,
>
> after update to svn 1.8.0 I have 100% reproducible perl crash during
> 'git svn fetch' with the following error (full backtrace + link to
> core at the end of the message):
>
> *** Error in `/usr/bin/perl': double free or
Hi,
after update to svn 1.8.0 I have 100% reproducible perl crash during
'git svn fetch' with the following error (full backtrace + link to
core at the end of the message):
*** Error in `/usr/bin/perl': double free or corruption (!prev):
0x0332fc90 ***
Downgrading to 1.7.10 helps.
Any ad
So I tried it today and it turns out that everything works perfectly. The
mistake I did was that the first time I did 'svn up --ignore-externals
user' and I forgot about the --ignore-externals parameter so the next time
('svn up' in 'software') naturally the externals (for 'user') were fetched
as w
On Mon, Jul 8, 2013 at 7:08 PM, Johan Corveleyn wrote:
> Also, check the version of the server. I think if you use a very old
> server, that server might not fully understand the "depth" nuances. So
> it's possible that this is just a back compat thing: the server will
> send everything, and the
On Mon, Jul 8, 2013 at 11:08 AM, Johan Corveleyn wrote:
> On Mon, Jul 8, 2013 at 10:43 AM, Miro Kropáček
> wrote:
>>
>> On Mon, Jul 8, 2013 at 6:35 PM, Tobias Bading wrote:
>>>
>>> You said you did an update yesterday, have you tried it with the latest
>>> 1.7 Tortoise release and a fresh worki
On Mon, Jul 8, 2013 at 10:43 AM, Miro Kropáček wrote:
>
> On Mon, Jul 8, 2013 at 6:35 PM, Tobias Bading wrote:
>>
>> You said you did an update yesterday, have you tried it with the latest
>> 1.7 Tortoise release and a fresh working copy?
>
>
> What I meant is that I'm not sure in which version I
On Mon, Jul 8, 2013 at 6:35 PM, Tobias Bading wrote:
> You said you did an update yesterday, have you tried it with the latest
> 1.7 Tortoise release and a fresh working copy?
What I meant is that I'm not sure in which version I had tried this, I
can't remember order of these two actions :) But
On 08.07.2013 10:24, Miro Kropáček wrote:
Hi Tobias,
You're right, a simple 'svn update' in 'trunk' or 'software'
should not pull in any directories of files outside of 'user'.
That should only happen if you run e.g. 'svn update --set-depth
infinity'. What Subversion version are
Hi Tobias,
You're right, a simple 'svn update' in 'trunk' or 'software' should not
> pull in any directories of files outside of 'user'. That should only happen
> if you run e.g. 'svn update --set-depth infinity'. What Subversion version
> are you using and on what platform?
>
It's Windows, the on
On 08.07.2013 01:06, Miro Kropáček wrote:
Hello,
I'm not subscribed to the list. I'd like to ask about one issue I'm
having. Let's say I've got a tree like this:
server/svn/trunk/software
server/svn/trunk/software/user
server/svn/trunk/software/wicked_filenames
server/svn/trunk/documentation
Hello,
I'm not subscribed to the list. I'd like to ask about one issue I'm having.
Let's say I've got a tree like this:
server/svn/trunk/software
server/svn/trunk/software/user
server/svn/trunk/software/wicked_filenames
server/svn/trunk/documentation
server/svn/trunk/huuuge_subtree_i_really_dont_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 05/03/2013 23:12, Philip Martin ha scritto:
>> Il 05/03/2013 14:09, Philip Martin ha scritto:
>>
>>> You don't say which client/OS you are using or which http
>>> library the Subversion client is using.
>>
>> subversion 1.6.17dfsg-4 openssl 1.0.1e
Philip Martin wrote on Tue, Mar 05, 2013 at 22:12:17 +:
> Paolo Cavallini writes:
> > Network has bben checked cables and switch have been changed, firewall
> > and proxy have not changed.
> > So it could be a communication problem between openssl and subversion.
> >
> > Any hint on how to deb
Paolo Cavallini writes:
> Hi Philip,
> thanks for your reply.
>
> Il 05/03/2013 14:09, Philip Martin ha scritto:
>
>> You don't say which client/OS you are using or which http library
>> the Subversion client is using.
>
> subversion 1.6.17dfsg-4
> openssl 1.0.1e-1
> on debian testing, up to date
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Philip,
thanks for your reply.
Il 05/03/2013 14:09, Philip Martin ha scritto:
> You don't say which client/OS you are using or which http library
> the Subversion client is using.
subversion 1.6.17dfsg-4
openssl 1.0.1e-1
on debian testing, up to
Paolo Cavallini writes:
> I'm consistently getting this error when svn up or ci:
>
> Could not read status line: SSL alert received: Bad record MAC
>
> Unsure whether it's an svn problem, or a network one. I've checked
> with my server hosting, and thay say it's software, but I cannot find
> a r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all.
I'm consistently getting this error when svn up or ci:
Could not read status line: SSL alert received: Bad record MAC
Unsure whether it's an svn problem, or a network one. I've checked with my
server
hosting, and thay say it's software, but
Excellent, I was hoping I might be doing something wrong. Looks like I have
some mass updates to do in several projects.
Perhaps as a suggestion the documentation for svn:externals should
specifically recommend using peg revisions over the other way of specifying
a specific revision since I can't
On Thu, Feb 28, 2013 at 03:36:45PM -0500, Jeffrey Pierson wrote:
> I've noticed that I can work around this issue by specifying my
> svn:external using a peg revision but I can't find anywhere in the
> documentation that suggests that using a peg revision is the correct
> way to reference a specifi
On 02/28/2013 03:36 PM, Jeffrey Pierson wrote:
> I'm seeing the following error when I attempt to update a working copy
> that has an svn external.
>
> svn: warning: W20: Error handling externals definition for
> 'MySharedProjectBeforeRename':
> svn: warning: W160013: File not found: revision
I'm seeing the following error when I attempt to update a working copy
that has an svn external.
svn: warning: W20: Error handling externals definition for
'MySharedProjectBeforeRename':
svn: warning: W160013: File not found: revision 100, path
'/trunk/MySharedProjectBeforeRename'
svn: E205011
Le 15/01/2012 09:16, Daniel Shahaf a écrit :
Forwarding back to list.
dcz wrote on Sun, Jan 15, 2012 at 09:02:06 +0100:
Le dimanche 15 janvier 2012 00:48:01, Daniel Shahaf a écrit :
dcz wrote on Tue, Jan 10, 2012 at 13:55:52 +0100:
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\su
Forwarding back to list.
dcz wrote on Sun, Jan 15, 2012 at 09:02:06 +0100:
> Le dimanche 15 janvier 2012 00:48:01, Daniel Shahaf a écrit :
> >
> >dcz wrote on Tue, Jan 10, 2012 at 13:55:52 +0100:
> >>
> >>In file
> >>'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_c
dcz wrote on Tue, Jan 10, 2012 at 13:55:52 +0100:
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_client\diff.c'
> line 1651: assertion failed (*target1&& *target2)
Those errors virtually always represent a bug in Subversion.
I do not find a rec
Le mercredi 11 janvier 2012 15:32:11, dcz a écrit :
Le mardi 10 janvier 2012 13:55:52, dcz a écrit :
Hello,
I already posted this on the tortoise ML
(http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2906737)
and the only answer I got was that this should be reported
-dev@ list
Johan, thanks for your help. See my comments below.
> Can you try if the following helps? $ svn update -r0 offendingdir
> Do the '--set-depth empty' trick (or '--set-depth exclude' ?)
My bad, I should have mentioned that we had tried that after googling
the issue, and before sending
Le mardi 10 janvier 2012 13:55:52, dcz a écrit :
Hello,
I already posted this on the tortoise ML
(http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2906737)
and the only answer I got was that this should be reported here.
I've been reading you all since a while now, an
On Tue, Jan 10, 2012 at 2:32 PM, Sebastian Esponda wrote:
> (Note: I'm "almost" sure this is something to be fixed for 1.7, being
> the reason why I'm also addressing this to the Dev list... feel free
> to correct me if I'm wrong.. Thanks)
Please don't crosspost to both lists, try to pick the cor
(Note: I'm "almost" sure this is something to be fixed for 1.7, being
the reason why I'm also addressing this to the Dev list... feel free
to correct me if I'm wrong.. Thanks)
Hello there,
We are facing the following issue with svn 1.7:
Exec summary:
- We need to incrementally checkout a multi-G
Hello,
I already posted this on the tortoise ML
(http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2906737)
and the only answer I got was that this should be reported here.
I've been reading you all since a while now, and actually registered on the
tortoise ML to post
Les Mikesell wrote on Wed, Oct 19, 2011 at 18:06:37 -0500:
> On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
> wrote:
> >
> > svn copy a b
> > echo -n yyy >b
> > svn commit -m 'c2' .
> >
> > Of cause I expect 'b' to contain 'yyy'. However sometimes it
> > contains 'xxx'. After this the r
On Wed, Oct 19, 2011 at 3:58 PM, Harald Wilhelmi
wrote:
>
> svn copy a b
> echo -n yyy >b
> svn commit -m 'c2' .
>
> Of cause I expect 'b' to contain 'yyy'. However sometimes it
> contains 'xxx'. After this the repository is all consistent and fine
> in my opinion (expect that 'a' has the
Hi,
in the last weeks I developed a little Subversion tool. When I
heard about Subversion 1.7.0 I downloaded the source at the next
opportunity to run the functional tests against the new version.
With the new version two of the tests fail *sometimes*. The
tests use the command line and do about
On Wednesday 22 June 2011, Nuno Cruces wrote:
> I believe I have found a bug the subversion server.
>
> It seems that, after committing a MIME formatted file (such as the one
> attached), I can't do anything to the file.
>
> Committing changes, returns the following:
>
> Commit failed (details f
ijben [mailto:b...@qqmail.nl]
Sent: Thursday, June 23, 2011 10:32 AM
To: Patrick Quirk; 'Johan Corveleyn'; 'Mark Phippard'
Cc: users@subversion.apache.org
Subject: RE: Possible bug moving file and then deleting directory
Patrick,
I can't reproduce the tree con
he.org/repos/asf/subversion/trunk/subversion/tests/cmdline/tr
ee_conflict_tests.py now)
Bert
From: Patrick Quirk [mailto:p.qu...@smt.com]
Sent: donderdag 23 juni 2011 15:08
To: Johan Corveleyn; Mark Phippard
Cc: users@subversion.apache.org
Subject: RE: Possible bug moving
make sure I’m matching what the issue is describing, and
> confirm that it does/doesn’t work for them either? It’s a windows batch
> file (zipped and renamed).
>
> ** **
> --
>
> *From:* Johan Corveleyn [mailto:jcor...@gmail.com]
> *Sent
Can't reproduce with either neon or serf.
9,% $svn add recover.eml
A recover.eml
9,% $svn ci -madd
Adding recover.eml
Transmitting file data .
Committed revision 2.
9,% $svn up
Updating '.':
At revision 2.
9,% echo>>iota
9,% $svn ci -mappend
Sendingiota
Transmitting file d
It seems this behavior has changed in 1.7 (to be released soon). It will no
longer flag this as a tree conflict. See
http://subversion.tigris.org/issues/show_bug.cgi?id=3526.
AFAICS, the case described here is similar to the one described in issue
#3526.
Patrick, if you have some time, maybe you
See http://subversion.apache.org/faq.html#self-tree-conflict
On Wed, Jun 22, 2011 at 4:04 PM, Patrick Quirk wrote:
> **
>
> I’ve run into this issue the past few days and I don’t feel like this is
> expected behavior. I’m using client version 1.6.17 (Collabnet binaries).*
> ***
>
>
Am Dienstag, 24. Mai 2011, 16:36:11 schrieb Varnau, Steve (Neoview):
> > Hmm, if it stops on any copy, then maybe "svn log --stop-on-copy" is
> > the wrong command for finding the base rev of a branch. Is there a
> > better alternative?
>
> I find it is better for this use case to log from past f
> -Original Message-
> From: Dirk Heinrichs [mailto:dirk.heinri...@capgemini.com]
> Sent: Tuesday, May 24, 2011 3:31 AM
> To: users@subversion.apache.org
> Subject: Re: Possible bug: --stop-on-copy stops too early
>
> Am Dienstag, 24. Mai 2011, 12:22:44 schrieb Steph
Am Dienstag, 24. Mai 2011, 12:22:44 schrieb Stephen Butler:
> The "A", along with the "from :", means that /software was
> copied from /PALISNC in this revision, so 'svn log --stop-on-copy' stops
> at this revision.
>
> I searched for "--stop-on-copy" in the bug tracker, and turned up
>
> htt
Dirk Heinrichs wrote on Tue, May 24, 2011 at 09:14:11 +0200:
> Hi,
>
> I'm trying to get the base revision of a branch using "svn log --stop-on-
> copy". However, the output of this command stops a couple of revisions too
> early:
>
> svn log -v
> https://sdmpudpagport.sdm.de/pu/dpagpalis/svn/r
On May 24, 2011, at 9:14 , Dirk Heinrichs wrote:
> Hi,
>
> I'm trying to get the base revision of a branch using "svn log --stop-on-
> copy". However, the output of this command stops a couple of revisions too
> early:
>
> svn log -v
> https://sdmpudpagport.sdm.de/pu/dpagpalis/svn/repository/
Hi,
I'm trying to get the base revision of a branch using "svn log --stop-on-
copy". However, the output of this command stops a couple of revisions too
early:
svn log -v
https://sdmpudpagport.sdm.de/pu/dpagpalis/svn/repository/software/branches/dhe_oracle_tablespaces_fuer_appcom
--
On May 13, 2011, at 13:38, Aliasgar Ganiji wrote:
> This is our setup svn 1.6.6 on Linux x86_64. What if the hooks are broken in
> this version? Can someone with this version of svn verify?
The hooks seem to be working correctly for me on Mac OS X 10.6.7 x86_64 with
Subversion 1.6.16 installe
@subversion.apache.org
Subject: Re: Possible bug in pre-revprop-change and post-revprop-change hooks
On Fri, May 13, 2011 at 4:40 PM, Aliasgar Ganiji wrote:
> I was in the process of implementing pre-revprop-change and
> post-revprop-change hooks in my company to handle changes to the sv
On Fri, May 13, 2011 at 4:40 PM, Aliasgar Ganiji wrote:
> I was in the process of implementing pre-revprop-change and
> post-revprop-change hooks in my company to handle changes to the svnn:log
> property. As per the SubVersion Redbook;
>
> 1. pre-revprop-change should be able to access the
I was in the process of implementing pre-revprop-change and post-revprop-change
hooks in my company to handle changes to the svnn:log property. As per the
SubVersion Redbook;
1. pre-revprop-change should be able to access the intended new value of
the property via standard input. Howeve
Hello!
We've encountered a strange behaviour with our quite loaded (avg 1500 http
requests per sec) SVN server. The server (RHEL5) is serving SVN repositories
via https by Apache.
apache 2.2.9
subversion 1.6.5
neon-0.28.4-1
neon-devel-0.28.4-1
The problem is that occasionally couple of httpd pro
Thanks guys - I was just reporting a bug, and didn't expect help. It
is much appreciated, and I now have things working.
Ryan - that's why I qualified "up to date" with "per the Synaptic
package manager" I am sorry I didn't specify further, which brings me
to Andy - you were right. 1.6.6 is what'
On Feb 10, 2011, at 15:19, Andy Levy wrote:
> Please be sure to specify the actual version of Subversion you're
> using. "Up to date" could have two meanings here - up to date with
> regard to what's in the Ubuntu 10.04 repository, or up to date with
> regard to Subversion releases. From what I c
On Thu, Feb 10, 2011 at 16:00, Shannon Dillman
wrote:
> Hello there,
>
> I am writing because my Subversion is reporting a situation that it
> feels is a bug. Unfortunately, I am not really a programmer (yet), so
> please accept my apologies in advance for any shortcomings in this
> report. I am
See this FAQ:
http://subclipse.tigris.org/wiki/PluginFAQ#head-73584410a8d4fbad6781c7b16be39f6518410a61
The error usually means that some tool you are using deleted a folder
and then recreated it. The problem is that this deletes the .svn
metadata folder inside it.
SVN 1.7 will solve this proble
Hello there,
I am writing because my Subversion is reporting a situation that it
feels is a bug. Unfortunately, I am not really a programmer (yet), so
please accept my apologies in advance for any shortcomings in this
report. I am also not dead certain that when it says "please report,"
it means
On Thu, Oct 21, 2010 at 05:12:15PM +0200, Martin Nowack wrote:
> Hello,
>
> I tried to merge form a foreign repository path in a local repository path
> using current svn version 1.6.13 but it fails.
>
> Assuming you have a local empty svn directory:
> svn merge http://llvm.org/svn/llvm-project/
Hello,
I tried to merge form a foreign repository path in a local repository path
using current svn version 1.6.13 but it fails.
Assuming you have a local empty svn directory:
svn merge http://llvm.org/svn/llvm-project/dragonegg/trunk
I get the following output:
--- Merging (from foreign repos
: Re: Possible bug in svn's gnome-keyring support?
If the option is not set, the default behavior is to use what is
available. If you have gnome-keyring support it tries to use it.
On Tue, Jul 13, 2010 at 12:22 PM, Jeremy Wall wrote:
> There was no password-stores line in my config file.
t;>
>>
>>
>> password-stores = gnome-keyring
>>
>>
>>
>> -Steve
>>
>>
>>
>> From: Jeremy Wall [mailto:jw...@google.com]
>> Sent: Tuesday, July 13, 2010 9:11 AM
>> To: Varnau, Steve (Neoview)
>> Cc: users@subversion.
Varnau, Steve (Neoview)
> *Cc:* users@subversion.apache.org
> *Subject:* Re: Possible bug in svn's gnome-keyring support?
>
>
>
> The strangeness is it's insistence on using the Gnome Keyring despite me
> not using Gnome. Is this the expected default behaviour?
&g
It should only use gnome if it is specified in your config file
(~/.subversion/config):
password-stores = gnome-keyring
-Steve
From: Jeremy Wall [mailto:jw...@google.com]
Sent: Tuesday, July 13, 2010 9:11 AM
To: Varnau, Steve (Neoview)
Cc: users@subversion.apache.org
Subject: Re: Possible bug
remy Wall [mailto:jw...@google.com]
> *Sent:* Tuesday, July 13, 2010 8:09 AM
> *To:* users@subversion.apache.org
> *Subject:* Possible bug in svn's gnome-keyring support?
>
>
>
> Hi,
>
>
>
> I noticed after updating svn to version 1.6.6 that svn now has
&g
1 - 100 of 111 matches
Mail list logo
