AW: rc1 is DOA. What now?

Hi, Von: Markus Schaber [mailto:m.scha...@3s-software.com] > Von: Branko Čibej [mailto:br...@xbc.nu] > > I wonder if it even makes sense to fix this case for upgrade. After > > all, we could just tell users to unlock files before upgrading their > > working copies. > > This would be rather unfort

AW: rc1 is DOA. What now?

Hi, Brane, Von: Branko Čibej [mailto:br...@xbc.nu] > I wonder if it even makes sense to fix this case for upgrade. After all, > we could just tell users to unlock files before upgrading their working > copies. This would be rather unfortunate for our users - it would convert working copy upgrade

Seeking talented developers to work on Subversion clients and merge

We are seeking developers to work on Subversion clients, Subversion merge, and related innovations in open source subversion. We are looking for experts and hackers to work on our distributed team, writing open source code, full time or part time. * Subversion merge fix * EasySVN -- a backrgoun

Re: diff --summarize

Hi Julian, I've examined your patch and did add something to wc_wc_diff_summarize, though it's not as plain as I first thought. I'll give you the elephant in the room first: Currently, 'svn diff --summarize ' does *nothing else* than what a plain 'svn status' does. There is no way to get other w

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

On Wed, Aug 24, 2011 at 12:03 AM, Hyrum K Wright wrote: > On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato > wrote: >> On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote: >>> On 08/23/2011 10:32 AM, Julian Foad wrote: Mark (or anyone), do you recognize the use case described by Clemens An

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

On Tue, Aug 23, 2011 at 3:07 PM, C. Michael Pilato wrote: > On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote: >> On 08/23/2011 10:32 AM, Julian Foad wrote: >>> Mark (or anyone), do you recognize the use case described by Clemens >>> Anhuth in

Re: rc1 is DOA. What now?

On 08/23/2011 05:57 PM, Hyrum K Wright wrote: > On Tue, Aug 23, 2011 at 3:17 PM, Branko Čibej wrote: >> On 23.08.2011 21:21, Stefan Sperling wrote: >>> On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote: I wonder if it even makes sense to fix this case for upgrade. After all, w

Re: rc1 is DOA. What now?

On Tue, Aug 23, 2011 at 3:17 PM, Branko Čibej wrote: > On 23.08.2011 21:21, Stefan Sperling wrote: >> On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote: >>> I wonder if it even makes sense to fix this case for upgrade. After all, >>> we could just tell users to unlock files before upgra

Re: rc1 is DOA. What now?

On 23.08.2011 21:21, Stefan Sperling wrote: > On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote: >> I wonder if it even makes sense to fix this case for upgrade. After all, >> we could just tell users to unlock files before upgrading their working >> copies. > Do you mean that it doesn't

Re: dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

On 08/23/2011 11:59 AM, Neels J Hofmeyr wrote: > On 08/23/2011 10:32 AM, Julian Foad wrote: >> Mark (or anyone), do you recognize the use case described by Clemens >> Anhuth in ? >> >> Use case (2) - Eclipse folder, from issue #3028 >> >>

Re: rc1 is DOA. What now?

On Tue, Aug 23, 2011 at 09:03:15PM +0200, Branko Čibej wrote: > I wonder if it even makes sense to fix this case for upgrade. After all, > we could just tell users to unlock files before upgrading their working > copies. Do you mean that it doesn't need to be fixed, ever? Or that this isn't a crit

Re: diff copyfrom, and other inconsistencies [was: Re: diff --summarize]

On Tue, Aug 23, 2011 at 09:10:44PM +0200, Bert Huijben wrote: > The problem is: You never know if the copy was done within that range. > Assuming N < M > > You can get the information that the file was copied *from* N-1000, while > that copy was performed in N-500. > For diff you want to know whe

RE: diff copyfrom, and other inconsistencies [was: Re: diff --summarize]

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: dinsdag 23 augustus 2011 20:51 > To: Bert Huijben > Cc: 'Julian Foad'; 'Neels J Hofmeyr'; 'Subversion Development' > Subject: Re: diff copyfrom, and other inconsistencies [was: Re: diff -- > summarize] > > On Tue

Re: rc1 is DOA. What now?

On 23.08.2011 20:07, Mark Phippard wrote: > On Tue, Aug 23, 2011 at 1:52 PM, Hyrum K Wright > mailto:hyrum.wri...@wandisco.com>> wrote: > > In theory, we could end up shooting ourselves and our users in the > feet by scuttling every RC between tag and release as issues become > known.

Re: diff copyfrom, and other inconsistencies [was: Re: diff --summarize]

On Tue, Aug 23, 2011 at 07:01:18PM +0200, Bert Huijben wrote: > Note that one of the reasons we abandoned this approach here and in the > update editor was that there was no way to know when the revision was > copied. What do you mean, abandoned it "here"? AFAIK diff never used this. > E.g. ther

Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

On Tue, Aug 23, 2011 at 7:27 PM, Neels J Hofmeyr wrote: > On 08/23/2011 09:07 AM, Johan Corveleyn wrote: >> On Tue, Aug 23, 2011 at 5:13 AM, Neels J Hofmeyr wrote: >>> I can reproduce the corrupted WC reported by David Wallace with 1.6.17. >>> 1.7.x does not show this bug. >>> >>> I have attached

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On Tue, Aug 23, 2011 at 1:52 PM, Hyrum K Wright wrote: > In theory, we could end up shooting ourselves and our users in the > feet by scuttling every RC between tag and release as issues become > known. That's obviously a bit absurd, but it's worth asking where we > draw that line? > This is my

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On Tue, Aug 23, 2011 at 9:10 AM, C. Michael Pilato wrote: > On 08/23/2011 08:17 AM, Bert Huijben wrote: >>> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as >>> Subversion 1.7.0 >> >> Ok, make that a -1 to release as Subversion 1.7.0 >> >> Subversion working copies that contai

Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

On 08/23/2011 09:07 AM, Johan Corveleyn wrote: > On Tue, Aug 23, 2011 at 5:13 AM, Neels J Hofmeyr wrote: >> I can reproduce the corrupted WC reported by David Wallace with 1.6.17. >> 1.7.x does not show this bug. >> >> I have attached a reproduction script that is roughly based on David's >> types

RE: diff copyfrom, and other inconsistencies [was: Re: diff --summarize]

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: dinsdag 23 augustus 2011 18:51 > To: Julian Foad > Cc: Neels J Hofmeyr; Subversion Development > Subject: diff copyfrom, and other inconsistencies [was: Re: diff --summarize] > > On Mon, Aug 22, 2011 at 12:42:55P

diff copyfrom, and other inconsistencies [was: Re: diff --summarize]

On Mon, Aug 22, 2011 at 12:42:55PM +0100, Julian Foad wrote: > I'm noticing all sorts of nasty inconsistencies in diffs. For instance, > manual testing reveals that in svn_client_diff5(), show_copies_as_adds > is ignored for a repos-repos diff. Instead, a file is diffed against its > copyfrom sour

Re: [Possible Bug] Can't checkout without file/directory ownership

On Tue, Aug 23, 2011 at 10:00:05AM -0600, Kevin Locke wrote: > Very true. I wonder if it might make sense to do a test at startup to > see if permissions are supported in the working directory and ignore > all permissions errors in the working directory iff the filesystem > would not preserve them

Re: rc1 is DOA. What now?

Daniel Shahaf writes: > C. Michael Pilato wrote on Tue, Aug 23, 2011 at 10:10:28 -0400: >> Option #1 -- releasing a release candidate that's not a candidate for >> release -- just doesn't make any sense to me. > > There are still items on > http://subversion.apache.org/roadmap#release-status that

Re: [Possible Bug] Can't checkout without file/directory ownership

Hi Stefan, Thanks for looking into this, I appreciate it. On Tue, 2011-08-23 at 11:02 +0200, Stefan Sperling wrote: > On Mon, Aug 22, 2011 at 04:57:37PM -0600, Kevin Locke wrote: >> [...] >> >> = The Problem = >> I am unable to work with (checkout/update) a working copy on an NTFS >> filesystem

dump svn:hold, long live file externals?? (and discussing recursive hold) -- was: bring on your concerns about svn:hold, please

On 08/23/2011 10:32 AM, Julian Foad wrote: > Mark (or anyone), do you recognize the use case described by Clemens > Anhuth in ? > > Use case (2) - Eclipse folder, from issue #3028 > > "For example we have a complete Eclipse instance in

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

C. Michael Pilato wrote on Tue, Aug 23, 2011 at 10:10:28 -0400: > Option #1 -- releasing a release candidate that's not a candidate for > release -- just doesn't make any sense to me. There are still items on http://subversion.apache.org/roadmap#release-status that don't have a green light next to

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On Tue, Aug 23, 2011 at 9:53 AM, Bob Archer wrote: >> On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer >> wrote: >> >> On 08/23/2011 08:17 AM, Bert Huijben wrote: >> >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release >> >> >> +as >> >> >> Subversion 1.7.0 >> >> > >> >> > Ok, make

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On Tue, Aug 23, 2011 at 10:53 AM, Bob Archer wrote: > > On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer > > wrote: > > >> On 08/23/2011 08:17 AM, Bert Huijben wrote: > > >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release > > >> >> +as > > >> >> Subversion 1.7.0 > > >> > > > >>

RE: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

> On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer > wrote: > >> On 08/23/2011 08:17 AM, Bert Huijben wrote: > >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release > >> >> +as > >> >> Subversion 1.7.0 > >> > > >> > Ok, make that a -1 to release as Subversion 1.7.0 > >> > > >> > Subv

Re: svn commit: r1160330 - /subversion/branches/1.7.x/CHANGES

On Mon, Aug 22, 2011 at 12:56 PM, Hyrum K Wright wrote: > On Mon, Aug 22, 2011 at 12:00 PM, Stefan Sperling wrote: >> On Mon, Aug 22, 2011 at 11:52:06AM -0500, Hyrum K Wright wrote: >>> Thank you for introducing subtree mergeinfo onto CHANGES.  :( >> >> I didn't do it! svn did! >> >> Jokes aside,

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer wrote: >> On 08/23/2011 08:17 AM, Bert Huijben wrote: >> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as >> >> Subversion 1.7.0 >> > >> > Ok, make that a -1 to release as Subversion 1.7.0 >> > >> > Subversion working copies that

RE: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

> On 08/23/2011 08:17 AM, Bert Huijben wrote: > >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as > >> Subversion 1.7.0 > > > > Ok, make that a -1 to release as Subversion 1.7.0 > > > > Subversion working copies that contain 'svn lock'-style locks can't be > > upgraded by our

Re: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On Tue, Aug 23, 2011 at 10:10 AM, C. Michael Pilato wrote: > On 08/23/2011 08:17 AM, Bert Huijben wrote: > >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as > >> Subversion 1.7.0 > > > > Ok, make that a -1 to release as Subversion 1.7.0 > > > > Subversion working copies that

Re: Bug: JavaHL does not transmie post-commit error messages to caller (was: Fwd: Re: JavaHL bindings - post-commit error messages)

Martin, After discussion with some other devs on IRC (#svn-dev on Freenode, come and join us!), I committed r1160705 which should expose the post commit error as part of the CommitInfo class in JavaHL. I've nominated r1160705 for 1.7.x. Could you test it if you get the chance? -Hyrum On Tue, Au

rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

On 08/23/2011 08:17 AM, Bert Huijben wrote: >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as >> Subversion 1.7.0 > > Ok, make that a -1 to release as Subversion 1.7.0 > > Subversion working copies that contain 'svn lock'-style locks can't be > upgraded by our current upgra

Re: bring on your concerns about svn:hold, please

On 08/23/2011 03:56 PM, Hyrum K Wright wrote: btw, regarding 'svn diff' showing changes to held files: I think it should. >>> +1 'svn diff' should still show mods to held files. >> >> humph, ok, if you say so. I'd add a --do-hold option to diff then. > > Are you saying diff would hide

Re: bring on your concerns about svn:hold, please

On Tue, Aug 23, 2011 at 8:49 AM, Neels J Hofmeyr wrote: > On 08/23/2011 03:04 AM, Hyrum K Wright wrote: >> On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein wrote: >>> I'd give that a +1 if two things are implemented: >>> >>> 1) adjust the log message to note the hold-back 2) status shows 'H' >>> for h

Re: 1.7.0-rc1 on svn.apache.org

On Tue, Aug 23, 2011 at 8:49 AM, Daniel Shahaf wrote: > Hyrum K Wright wrote on Tue, Aug 23, 2011 at 07:52:06 -0500: >> On Tue, Aug 23, 2011 at 7:06 AM, C. Michael Pilato >> wrote: >> > On 08/23/2011 06:29 AM, Daniel Shahaf wrote: >> >> - Bert points out that the HTTPv2 code may not interact wel

Re: bring on your concerns about svn:hold, please

On 08/23/2011 03:04 AM, Hyrum K Wright wrote: > On Mon, Aug 22, 2011 at 7:18 PM, Greg Stein wrote: >> I'd give that a +1 if two things are implemented: >> >> 1) adjust the log message to note the hold-back 2) status shows 'H' >> for held files that also have local mods Ok, cool. >> btw, regardi

Re: 1.7.0-rc1 on svn.apache.org

Hyrum K Wright wrote on Tue, Aug 23, 2011 at 07:52:06 -0500: > On Tue, Aug 23, 2011 at 7:06 AM, C. Michael Pilato > wrote: > > On 08/23/2011 06:29 AM, Daniel Shahaf wrote: > >> - Bert points out that the HTTPv2 code may not interact well with > >>   clients committing via the svn.eu mirror to an

Re: bring on your concerns about svn:hold, please

On Tue, Aug 23, 2011 at 4:32 AM, Julian Foad wrote: > Mark Phippard wrote: > > [...] You like to talk about the IDE use case, so let's talk about > > it. That is where I am coming from on this too. In Subclipse, [...] > > Mark (or anyone), do you recognize the use case described by Clemens > Anh

Re: bring on your concerns about svn:hold, please

Neels, I hadn't read through your 'notes/hold' doc, which I should have done first. Now I have, and added a bunch of comments - see attached patch. It would be really helpful if, in the light of your current knowledge and what's been discussed in this thread, you could update that doc and convert

Re: 1.7.0-rc1 on svn.apache.org

When infra does move svn to the 1.7 candidates, we're committed to only moving forward with that, not back to a previous 1.6.  So as long as we're all confident that serious problems can be addressed in a reasonable period of time, I'm +1 as well. > >From: Hyrum

Re: svn upgrade fails with database table is locked

On Tue, Aug 23, 2011 at 16:40, Ivan Zhakov wrote: > On Tue, Aug 23, 2011 at 16:18, Bert Huijben wrote: >> >> >>> -Original Message- >>> From: Markus Schaber [mailto:m.scha...@3s-software.com] >>> Sent: dinsdag 23 augustus 2011 8:31 >>> To: Ivan Zhakov; Bert Huijben >>> Cc: dev@subversion.

Re: 1.7.0-rc1 on svn.apache.org

On Tue, Aug 23, 2011 at 7:06 AM, C. Michael Pilato wrote: > On 08/23/2011 06:29 AM, Daniel Shahaf wrote: >> - Bert points out that the HTTPv2 code may not interact well with >>   clients committing via the svn.eu mirror to an HTTPv2-enabled svn.us. > > Hrm, I can't think of any scenarios in which

Re: 1.7.0-rc1 up for testing / signing

On Tue, Aug 23, 2011 at 4:07 AM, Bert Huijben wrote: > > >> -Original Message- >> From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] >> Sent: vrijdag 19 augustus 2011 20:24 >> To: Subversion Development >> Subject: 1.7.0-rc1 up for testing / signing >> >> Here it is: the first Release

Re: svn upgrade fails with database table is locked

On Tue, Aug 23, 2011 at 16:18, Bert Huijben wrote: > > >> -Original Message- >> From: Markus Schaber [mailto:m.scha...@3s-software.com] >> Sent: dinsdag 23 augustus 2011 8:31 >> To: Ivan Zhakov; Bert Huijben >> Cc: dev@subversion.apache.org >> Subject: AW: svn upgrade fails with database t

Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

For what its worth, this sounds very much like some tree-conflicts badness that I ran into on occasion with 1.6. I was never able to reproduce it, since by the time I un-hosed my working copy, I'd forgotten what I had done to get myself into the mess in the first place. It's good to hear that it'

Re: svn commit: r1160601 - /subversion/trunk/subversion/libsvn_subr/magic.c

Stefan Sperling wrote on Tue, Aug 23, 2011 at 14:26:43 +0200: > On Tue, Aug 23, 2011 at 01:32:38PM +0300, Daniel Shahaf wrote: > > Backport? > > This shaves one byte off a struct. I don't think it's very important. > *shaves*. Sorry, I misread the diff. > > s...@apache.org wrote on Tue, Aug 2

Re: svn commit: r1160601 - /subversion/trunk/subversion/libsvn_subr/magic.c

On Tue, Aug 23, 2011 at 01:32:38PM +0300, Daniel Shahaf wrote: > Backport? This shaves one byte off a struct. I don't think it's very important. > s...@apache.org wrote on Tue, Aug 23, 2011 at 09:59:42 -: > > Author: stsp > > Date: Tue Aug 23 09:59:42 2011 > > New Revision: 1160601 > > > >

RE: svn upgrade fails with database table is locked

> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: dinsdag 23 augustus 2011 13:58 > To: Bert Huijben > Cc: Markus Schaber; dev@subversion.apache.org > Subject: Re: svn upgrade fails with database table is locked > > On Tue, Aug 23, 2011 at 13:01, Bert Huijben w

RE: svn upgrade fails with database table is locked

> -Original Message- > From: Markus Schaber [mailto:m.scha...@3s-software.com] > Sent: dinsdag 23 augustus 2011 8:31 > To: Ivan Zhakov; Bert Huijben > Cc: dev@subversion.apache.org > Subject: AW: svn upgrade fails with database table is locked > > Hi, > > Von: Ivan Zhakov [mailto:i...@v

RE: 1.7.0-rc1 up for testing / signing

> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 23 augustus 2011 11:08 > To: 'Hyrum K Wright'; 'Subversion Development' > Subject: RE: 1.7.0-rc1 up for testing / signing > > > > > -Original Message- > > From: Hyrum K Wright [mailto:hyrum.wri...

Re: 1.7.0-rc1 on svn.apache.org

Daniel Shahaf wrote: > Do we recommend infra to install 1.7.0-rc1 on svn.apache.org? +1. - Julian > --- > > Per [1], svn.us would have to be upgraded before svn.eu. > > With my infra hat, I remind everyone that infra may decide not to > upgrade for a variety of reasons. (For example, whether

Re: 1.7.0-rc1 on svn.apache.org

On 08/23/2011 06:29 AM, Daniel Shahaf wrote: > - Bert points out that the HTTPv2 code may not interact well with > clients committing via the svn.eu mirror to an HTTPv2-enabled svn.us. Hrm, I can't think of any scenarios in which having a newer master version than slave version will cause issues

Re: svn upgrade fails with database table is locked

On Tue, Aug 23, 2011 at 13:01, Bert Huijben wrote: > > > > It's very interesting. It seems that disabling SQLite shared cache fixes > > > one problem and discovers another. I'm not WCNG expert, may be other > > > Subversion developers have more knowledge of possible reason of "The > > node > > > .

Re: 1.7.0-rc1 on svn.apache.org

Yes. On Aug 23, 2011 6:22 AM, "Daniel Shahaf" wrote: > Do we recommend infra to install 1.7.0-rc1 on svn.apache.org? > > --- > > Per [1], svn.us would have to be upgraded before svn.eu. > > With my infra hat, I remind everyone that infra may decide not to > upgrade for a variety of reasons. (For e

svn_client_info_3 inconsistencies

Hi, I'm using latest build of SharpSVN against SVN 1.7. I'm using Client.Info which maps to svn_client_info_3. It seems that the svn_client_info_receiver2_T parameter abspath_or_url shows inconsistent behavior when applied to a working copy. When I pass no peg_revision, and revision to svn_opt

Re: svn commit: r1160601 - /subversion/trunk/subversion/libsvn_subr/magic.c

Backport? s...@apache.org wrote on Tue, Aug 23, 2011 at 09:59:42 -: > Author: stsp > Date: Tue Aug 23 09:59:42 2011 > New Revision: 1160601 > > URL: http://svn.apache.org/viewvc?rev=1160601&view=rev > Log: > * subversion/libsvn_subr/magic.c > (svn_magic__cookie_t): Put a dummy byte into thi

Re: 1.7.0-rc1 on svn.apache.org

Daniel Shahaf wrote on Tue, Aug 23, 2011 at 13:21:52 +0300: > Do we recommend infra to install 1.7.0-rc1 on svn.apache.org? > > --- > > Per [1], svn.us would have to be upgraded before svn.eu. Will there be an issue with having 1.6 on svn.eu and 1.7 on svn.us? + It would mean the svn.eu copies

1.7.0-rc1 on svn.apache.org

Do we recommend infra to install 1.7.0-rc1 on svn.apache.org? --- Per [1], svn.us would have to be upgraded before svn.eu. With my infra hat, I remind everyone that infra may decide not to upgrade for a variety of reasons. (For example, whether svn.eu and svn.us are generally healthy or undergo

Re: bring on your concerns about svn:hold, please

2011/8/22 Stefan Küng : > On 22.08.2011 18:51, Neels J Hofmeyr wrote: > >>> Since TortoiseSVN has had this feature for a long time, it would >>> be interesting to know what kind of edge cases people have raised with >>> the >>> feature.  Has anyone asked that these files not be updated or merged? >

Re: [Possible Bug] Can't checkout without file/directory ownership

On Tue, Aug 23, 2011 at 10:40:28AM +0100, Philip Martin wrote: > Stefan Sperling writes: > > > On Mon, Aug 22, 2011 at 04:57:37PM -0600, Kevin Locke wrote: > > >> $ svn co http://svn.apache.org/repos/asf/subversion/trunk testdir > >> svn: E01: Can't set permissions on > >> '/testdir/.svn/tm

Re: [Possible Bug] Can't checkout without file/directory ownership

Stefan Sperling writes: > On Mon, Aug 22, 2011 at 04:57:37PM -0600, Kevin Locke wrote: >> $ svn co http://svn.apache.org/repos/asf/subversion/trunk testdir >> svn: E01: Can't set permissions on '/testdir/.svn/tmp/svn-HZAmRw': >> Operation not permitted > + err = file_perms_set2(tempfi

RE: 1.7.0-rc1 up for testing / signing

> -Original Message- > From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] > Sent: vrijdag 19 augustus 2011 20:24 > To: Subversion Development > Subject: 1.7.0-rc1 up for testing / signing > > Here it is: the first Release Candidate for Subversion 1.7.0. You can > fetch the proposed

Re: [Possible Bug] Can't checkout without file/directory ownership

On Mon, Aug 22, 2011 at 04:57:37PM -0600, Kevin Locke wrote: > Hi all, > > As per the bug/issue guidelines, I'm posting something that I consider > to be a bug (but which may be contentious) to this list for > consideration before filing a bug report. > > = The Problem = > I am unable to work wit

RE: svn upgrade fails with database table is locked

> -Original Message- > From: Markus Schaber [mailto:m.scha...@3s-software.com] > Sent: dinsdag 23 augustus 2011 8:31 > To: Ivan Zhakov; Bert Huijben > Cc: dev@subversion.apache.org > Subject: AW: svn upgrade fails with database table is locked > > Hi, > > Von: Ivan Zhakov [mailto:i...@v

Re: bring on your concerns about svn:hold, please

Mark Phippard wrote: > [...] You like to talk about the IDE use case, so let's talk about > it. That is where I am coming from on this too. In Subclipse, [...] Mark (or anyone), do you recognize the use case described by Clemens Anhuth in

Re: 1.7.0-rc1 up for testing / signing

On Tue, Aug 23, 2011 at 2:51 AM, Hyrum K Wright wrote: > FYI: by my count we're still lacking one Windows sig. > > Ivan, I know you tested the release but had some concerns, which folks > have discussed.  If you're comfortable with the resolution, would you > mind sending over signatures? > > (One

Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

On Tue, Aug 23, 2011 at 5:13 AM, Neels J Hofmeyr wrote: > I can reproduce the corrupted WC reported by David Wallace with 1.6.17. > 1.7.x does not show this bug. > > I have attached a reproduction script that is roughly based on David's > typescript, but is only a fraction of the size. > > The err