Re: lose unversioned data with revert

On 02/29/2012 04:23 PM, Stefan Sperling wrote: > On Wed, Feb 29, 2012 at 04:07:10PM +0100, Neels J Hofmeyr wrote: >> My impression was that svn tries to leave unversioned data around until the >> user takes care of it (as with 'svn delete dir'). That's what I thought >> obstructed states are for. >

Re: delete callback in editorv2 and tree conflicts

On Wed, Feb 29, 2012 at 05:30:51PM -0500, Greg Stein wrote: > But the short answer is: we have no design for conflict management in > Ev2. Thus, there will be a ton of out-of-band communication between > the merge process and the underlying state. Both reading, and writing > conflict information.

Re: delete callback in editorv2 and tree conflicts

On Wed, Feb 29, 2012 at 16:55, Stefan Sperling wrote: > On Wed, Feb 29, 2012 at 08:19:52AM -0500, Greg Stein wrote: >> The editor interface is not for merging. It is for *applying* the results >> of a merge, to a stateful representation of a tree to alter that held state. > > Sorry, but I still do

Re: delete callback in editorv2 and tree conflicts

On Wed, Feb 29, 2012 at 08:19:52AM -0500, Greg Stein wrote: > The editor interface is not for merging. It is for *applying* the results > of a merge, to a stateful representation of a tree to alter that held state. Sorry, but I still don't understand how you want to solve the problem. You seem to

Re: svn commit: r1295287 - /subversion/trunk/subversion/libsvn_delta/compat.c

On Feb 29, 2012 4:28 PM, "Hyrum K Wright" wrote: > > On Wed, Feb 29, 2012 at 3:25 PM, wrote: > > Author: hwright > > Date: Wed Feb 29 21:25:19 2012 > > New Revision: 1295287 > > > > URL: http://svn.apache.org/viewvc?rev=1295287&view=rev > > Log: > > Ev2 shims: Improve the order we use to drive t

Re: svn commit: r1295148 - /subversion/trunk/subversion/include/svn_error.h

Thanks for the recompile. ;-) On Feb 29, 2012 10:20 AM, wrote: > Author: hwright > Date: Wed Feb 29 15:20:18 2012 > New Revision: 1295148 > > URL: http://svn.apache.org/viewvc?rev=1295148&view=rev > Log: > When running the clang static analyzer, it is useful to use a vanilla > assert, > rather t

Re: svn commit: r1295287 - /subversion/trunk/subversion/libsvn_delta/compat.c

On Wed, Feb 29, 2012 at 3:25 PM, wrote: > Author: hwright > Date: Wed Feb 29 21:25:19 2012 > New Revision: 1295287 > > URL: http://svn.apache.org/viewvc?rev=1295287&view=rev > Log: > Ev2 shims: Improve the order we use to drive the shims by keeping track of the > order actions were added, rather

Please Ignore - trigger to setup mail list filter processing.

Hi all, just a quick message to make it easier for me to set up list processing of incoming mails.

Re: Symmetric Merge -- Wiki page

On Mon, Feb 27, 2012 at 01:15:30PM +, Julian Foad wrote: > As many of you are aware I've been looking at improving merge in > various ways.  I'd like to ask for feedback at this stage on the Wiki > page (renamed from > SvnMergeTheory).  The ess

Re: svn commit: r1295006 - /subversion/trunk/

On 02/29/2012 03:52 AM, Greg Stein wrote: > This revision means that trunk is effectively a branch. It now has a > non-zero copy_id. > > Philip/Mike: will this pose us any problems? > > I asked Daniel, and he confirmed the new copy_id, but neither of us > know whether this is really a problem. Wi

Re: Status of the Mac OS build slave

I'm happy removing it from the s.a.o/buildbot redirect, but I'm concerned that if we do we'll just forget about it that things will *never* get fixed. I think having an OS X-based buildslave is valuable, and hope we don't put it off indefinitely. Out of curiosity, what is the hold up with infra's

Re: [RFC] Inheritable Properties

On Mon, Feb 27, 2012 at 6:33 PM, Branko Čibej wrote: > On 28.02.2012 00:20, Paul Burba wrote: >> On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej wrote: >>> On 16.02.2012 16:46, C. Michael Pilato wrote: On 02/16/2012 05:50 AM, Branko Čibej wrote: > On 15.02.2012 21:18, Greg Stein wrote: >>

Re: Status of the Mac OS build slave

There are no news yet wrt infra's mac boxes -- but +1 to removing the builder from, say, the s.a.o/buildbot redirect. Is there anything else you meant by 'remove it from rotation'? Hyrum K Wright wrote on Wed, Feb 29, 2012 at 09:44:55 -0600: > Does anybody have any idea what the status is for the

Status of the Mac OS build slave

Does anybody have any idea what the status is for the Mac OS build slave? We still include it in our rotation, but the machine has been offline for over 5 months--hardly a temporary condition. Last time I checked, I thought ASF Infra had ownership of this slave, but I couldn't verify that a few m

Re: lose unversioned data with revert

On Wed, Feb 29, 2012 at 04:07:10PM +0100, Neels J Hofmeyr wrote: > My impression was that svn tries to leave unversioned data around until the > user takes care of it (as with 'svn delete dir'). That's what I thought > obstructed states are for. Revert is a bit of a fine line. It is a command that

Re: lose unversioned data with revert

On 02/29/2012 03:46 PM, Julian Foad wrote: >> You are explicitly reverting x, are you saying revert should fail? My >> first instinct is that revert is doing the right thing. > > Agreed. "revert" means "revert to the base state", so that's as expected. > Did you (or the user) mean to run "svn

Re: lose unversioned data with revert

Philip Martin wrote: > Neels J Hofmeyr writes: > >> Found this but haven't got the time to dive into right now. >> An unversioned file should never be killed, right? >> Should I create an issue? >> >> [[[ >> svn mkdir -mm ^/x >> echo important data > x >> svn st >> svn up >> svn st >>

Re: svn propchange: r1292402 - svn:log

On Wed, Feb 29, 2012 at 09:13:10AM -0500, Greg Stein wrote: > I guess I should look at that branch, but Neels mentioned wc_db functions. > So those should already be using db_kind, not node_kind. It's not a function parameter. It is the 'kind' member of struct parse_cache in svn_wc__db_t. That is

Re: svn propchange: r1292402 - svn:log

On Feb 29, 2012 9:08 AM, "Stefan Sperling" wrote: > > On Wed, Feb 29, 2012 at 08:25:45AM -0500, Greg Stein wrote: > > On Feb 29, 2012 8:02 AM, wrote: > > > > > > Author: neels > > > Revision: 1292402 > > > Modified property: svn:log > > > > > > Modified: svn:log at Wed Feb 29 13:02:36 2012 > > >

Re: svn propchange: r1292402 - svn:log

On Wed, Feb 29, 2012 at 08:25:45AM -0500, Greg Stein wrote: > On Feb 29, 2012 8:02 AM, wrote: > > > > Author: neels > > Revision: 1292402 > > Modified property: svn:log > > > > Modified: svn:log at Wed Feb 29 13:02:36 2012 > > > -

Re: delete callback in editorv2 and tree conflicts

Greg Stein wrote: > Julian Foad wrote: >> ... >> Client applies these changes to the WC -- which it could theoretically do >> via another editor but it just does it directly. > Not theoretical! It makes the changes using Ev2. That is why we have Ev2: a > uniform API for applying changes to tree

Re: lose unversioned data with revert

Neels J Hofmeyr writes: > Found this but haven't got the time to dive into right now. > An unversioned file should never be killed, right? > Should I create an issue? > > [[[ > svn mkdir -mm ^/x > echo important data > x > svn st > svn up > svn st > svn revert x > svn st > # empty status > ls -l

lose unversioned data with revert

Found this but haven't got the time to dive into right now. An unversioned file should never be killed, right? Should I create an issue? [[[ svn mkdir -mm ^/x echo important data > x svn st svn up svn st svn revert x svn st # empty status ls -l # x is now a dir, and "important data" is gone. ]]]

Re: svn propchange: r1292402 - svn:log

On Feb 29, 2012 8:02 AM, wrote: > > Author: neels > Revision: 1292402 > Modified property: svn:log > > Modified: svn:log at Wed Feb 29 13:02:36 2012 > -- > --- svn:log (original) > +++ svn:log Wed Feb 29 13:02:36 2012 > @@

Re: delete callback in editorv2 and tree conflicts

On Feb 29, 2012 8:05 AM, "Julian Foad" wrote: >... > Client applies these changes to the WC -- which it could theoretically do via another editor but it just does it directly. Not theoretical! It makes the changes using Ev2. That is why we have Ev2: a uniform API for applying changes to tree stat

Re: delete callback in editorv2 and tree conflicts

On Feb 29, 2012 8:05 AM, "Julian Foad" wrote: > > Greg Stein wrote: > > I'm not sure this has anything to do with Ev2. The editor is for making the actual changes; ie. examine the merge sources, and if acceptable, then you call svn_editor_delete() to perform the deletion. The merge logic is in the

Re: delete callback in editorv2 and tree conflicts

On Feb 29, 2012 8:01 AM, "Stefan Sperling" wrote: > > On Wed, Feb 29, 2012 at 07:27:46AM -0500, Greg Stein wrote: > > I'm not sure this has anything to do with Ev2. The editor is for making the > > actual changes; ie. examine the merge sources, and if acceptable, then you > > call svn_editor_delet

Re: delete callback in editorv2 and tree conflicts

Greg Stein wrote: > I'm not sure this has anything to do with Ev2. The editor is for making the > actual changes; ie. examine the merge sources, and if acceptable, then you > call svn_editor_delete() to perform the deletion. The merge logic is in the > *driver*, not the receiver. The way merge

Re: delete callback in editorv2 and tree conflicts

On Wed, Feb 29, 2012 at 07:27:46AM -0500, Greg Stein wrote: > I'm not sure this has anything to do with Ev2. The editor is for making the > actual changes; ie. examine the merge sources, and if acceptable, then you > call svn_editor_delete() to perform the deletion. The merge logic is in the > *dri

Re: delete callback in editorv2 and tree conflicts

I'm not sure this has anything to do with Ev2. The editor is for making the actual changes; ie. examine the merge sources, and if acceptable, then you call svn_editor_delete() to perform the deletion. The merge logic is in the *driver*, not the receiver. Cheers, -g On Feb 29, 2012 5:59 AM, "Stefan

Re: delete callback in editorv2 and tree conflicts

Stefan Sperling wrote: > I've been briefly considering about issue #3150 again. > http://subversion.tigris.org/issues/show_bug.cgi?id=3150 > "tree conflicts with directories as victims" > > The problem of this issue is that, during a merge, when deleting a directory, > we want to know whether the

delete callback in editorv2 and tree conflicts

I've been briefly considering about issue #3150 again. http://subversion.tigris.org/issues/show_bug.cgi?id=3150 "tree conflicts with directories as victims" The problem of this issue is that, during a merge, when deleting a directory, we want to know whether the merge is deleting the same content

Reintegrating the svnmucc branch? Re: svnmucc component Re: [Issue 4131] New - svnmucc uses Subversion-private APIs

Daniel Shahaf wrote on Wed, Feb 29, 2012 at 11:19:50 +0200: > Greg Stein wrote on Wed, Feb 29, 2012 at 03:50:19 -0500: > > Please wait for some consensus before changing the product like that. > > I thought we had had consensus and were waiting for someone to have the > cycles. If I was wrong I a

Re: svn commit: r1295006 - /subversion/trunk/

Philip Martin wrote: > Greg Stein writes: >> While talking about svnmucc on IRC, I tried to find out when it was >> moved from contrib to tools: >> >> $ svn log svnmucc --stop-on-copy | less [Returns r1295004 when trunk was copied over itself.] > So we need to implement "--stop-on-copy N" t

Re: svnmucc component Re: [Issue 4131] New - svnmucc uses Subversion-private APIs

Greg Stein wrote on Wed, Feb 29, 2012 at 03:50:19 -0500: > On Wed, Feb 29, 2012 at 03:03, Daniel Shahaf wrote: > > Can someone create a 'svnmucc' component please? > > Added. > Thanks. > >... > > The test suite relies on it, > > Hmm? When did that happen? I can just as readily claim that reli

Re: svn commit: r1295006 - /subversion/trunk/

Greg Stein writes: > While talking about svnmucc on IRC, I tried to find out when it was > moved from contrib to tools: > > $ svn log svnmucc --stop-on-copy | less So we need to implement "--stop-on-copy N" to stop on the N'th copy. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.co

Re: svn commit: r1295006 - /subversion/trunk/

While talking about svnmucc on IRC, I tried to find out when it was moved from contrib to tools: $ svn log svnmucc --stop-on-copy | less That gave me just one revision: when trunk was copied over itself. I had to go back to the trunk-before-replace: $ svn log svnmucc@1295003 --stop-on-copy | les

Re: svn commit: r1295006 - /subversion/trunk/

This revision means that trunk is effectively a branch. It now has a non-zero copy_id. Philip/Mike: will this pose us any problems? I asked Daniel, and he confirmed the new copy_id, but neither of us know whether this is really a problem. Will it affect merges? I bet it will affect --stop-on-copy

Re: svnmucc component Re: [Issue 4131] New - svnmucc uses Subversion-private APIs

On Wed, Feb 29, 2012 at 03:03, Daniel Shahaf wrote: > danie...@tigris.org wrote on Tue, Feb 28, 2012 at 23:59:51 -0800: >> http://subversion.tigris.org/issues/show_bug.cgi?id=4131 >>                  Issue #|4131 >>                  Summary|svnmucc uses Subversion-private APIs >>                Co

Re: svn commit: r1294646 - /subversion/trunk/subversion/tests/cmdline/svndumpfilter_tests.py

Greg Stein writes: > Couldn't you just make a Posix-specific test for pattern=* testing? Put the '*' in a file and use --targets and it should work for all systems -- that's what we do when passing '*' as a property value, -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com

Re: MTime resurrected

Rick Yorgason wrote: > On 2012-02-21 4:29 AM, Julian Foad wrote: >> Rick, thanks for that!  I haven't read it yet but I've put it up > at: >> >>     > > Has anybody had the time to read this yet? Sorry Rick, I still haven't. - Julian

Re: svn commit: r1294646 - /subversion/trunk/subversion/tests/cmdline/svndumpfilter_tests.py

Greg Stein wrote: > Couldn't you just make a Posix-specific test for pattern=* testing? > That would give us at least *some* testing coverage for it. My patch was all about fixing the plain prefix (non-pattern) mode, and there is already a test for the pattern mode with pattern=/A/D/G/* so no co

svnmucc component Re: [Issue 4131] New - svnmucc uses Subversion-private APIs

danie...@tigris.org wrote on Tue, Feb 28, 2012 at 23:59:51 -0800: > http://subversion.tigris.org/issues/show_bug.cgi?id=4131 > Issue #|4131 > Summary|svnmucc uses Subversion-private APIs >Component|subversion > Version|1.6.x >