Merging the svndiff-patch branch to trunk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.

Just wondering where we're at in the process of merging the
svndiff-patch branch to trunk.  It'd be good to get it there
so others
can start playing with it, and to get it into the 1.5
release.  I'd hate
to have to wait until 1.6 to release code from SoC '07.

I know that Charles has been working on the branch a bit
lately.
Charles, what would it take to get it mergeable, and do you
think you
can have that ready in the next day or two?

It'd also be good if some of the committers reviewed what's
there.  I
haven't had the chance to yet, but hope to take a look
sometime this
weekend.

- -Hyrum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFHBYqWCwOubk4kUXwRAiN2AJ0fkKBQhBqy2vBeGRj03m4BNMnzNgCe
OXHg
GYMuzH2EtbwDY3KsTQ68PyY=
=r92o
-----END PGP SIGNATURE-----

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

"Hyrum K. Wright" <hyrum_wrightmail.utexas.edu> writes:

> Just wondering where we're at in the process of merging
the
> svndiff-patch branch to trunk.  It'd be good to get it
there so others
> can start playing with it, and to get it into the 1.5
release.  I'd hate
> to have to wait until 1.6 to release code from SoC
'07.

1.5 is a monster of a release already, and that branch date
is
just around the corner.  I've expressed before my desire to
see a
smaller, sooner 1.6 as the next release.  I'd much rather
hold
this feature back until then.  svnpatch + random polishing,
including picking up the remaining merge-tracking issues
(there
are some, aren't they, that were pushed back?) would make
for a
nice 1.6 release, I think.

I'm excited about this feature, and can't wait to use it. 
But, I
think we have enough to worry about with 1.5 already.  This
is
just a suggestion, not a veto or even a vote.

P.S. Then 1.7 would be another big one, with the wc rewrite
as
the tent pole feature .

-- 
Eric Gillespie <*> epgpretzelnet.org

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

Hm, I guess I disagree.  'svn patch' doesn't feel like a
such a huge
feature to me that it's worth holding back.  If were
half-implemented,
sure, we wouldn't want to wait on it.  But it's basically
finished...
it just needs some testing now, and I think it will
(frankly) get a
heck of a lot more testers attracted to it than
merge-tracking.
(Mainly because it's a much simpler, much more accessible
new
feature.)

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 10/5/07, Hyrum K. Wright <hyrum_wrightmail.utexas.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all.
>
> Just wondering where we're at in the process of merging
the
> svndiff-patch branch to trunk.  It'd be good to get it
there so others
> can start playing with it, and to get it into the 1.5
release.  I'd hate
> to have to wait until 1.6 to release code from SoC
'07.
>
> I know that Charles has been working on the branch a
bit lately.
> Charles, what would it take to get it mergeable, and do
you think you
> can have that ready in the next day or two?

I meant to let people know in the next few days about how
the
svnpatch-diff branch is doing.  But I'll take the
opportunity of your
post to do it right away.

While there's still some work to be done, I think the branch
is quite
ready for merging back to trunk.  It's just that I'm not
sure whether
we want this for 1.5 or not, as I've been hearing both 'for'
and
'against' opinions.  So in the meantime I endeavor to make
the branch
as stable as possible before we reach consensus on that
point.

BTW, the branch got some code review (thanks glasser  on some
of
the last svnpatch-diff commits, and malcolm might have had a
look at
the branch too during GSoC, but I think it's fairly far from
covering
the whole branch work.

As for the work left to be done, I'm currently working on
it.  Here's
a task list that I have in mind for those interested with
details:

  * file move operations:  a move operation is represented
with an
add-with-history and a del.  Because we're driving the
editor in a
depth-first manner, it may occur that the del precedes the
add-with-history.  It turns out to be a problem since the
add-with-history is precisely a file copy of the file which
the del
command just deleted.  I have some code partly working that
I'll
commit soon (next 24h hopefully).  It involves maintaining a
list of
schedule-delete files and using the on-delete-keep-local
feature to
defer disk file deletion until after the copy is actually
made.

 * directory copy and move operations:  basically carefully
duplicate/use file's code with a 'recursive' flavor.

  * ensure fuzzing is working as expected, if we can say so.
 (I've
already tried svnpatch fuzzing but I'm sure it needs more
testing as
really anything can happen)

  * write some more patch_tests.py tests

And possibly:

  * copyfrom information:  I was able to generate
copyfrom-enabled
patch for wc/wc diffs, but since the server doesn't send
this copyfrom
information both wc/repos and repos/wc diffs lack this
feature.  This
needs some work on all three RA implementations I guess, in
a similar
way to sussman's recent work on copyfrom stuff for updates.

Hope it helps see the overall picture of this branch.

Charles

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 10/5/07, Ben Collins-Sussman <sussmanred-bean.com> wrote:
> Hm, I guess I disagree.  'svn patch' doesn't feel like
a such a huge
> feature to me that it's worth holding back.  If were
half-implemented,
> sure, we wouldn't want to wait on it.  But it's
basically finished...
> it just needs some testing now, and I think it will
(frankly) get a
> heck of a lot more testers attracted to it than
merge-tracking.
> (Mainly because it's a much simpler, much more
accessible new
> feature.)

Well, I'm for holding back. Myself, I have decided to set up
branches
more frequently, in order to do work I want to be done.
Then, when the
branch is done, we can move the work to trunk.

If we used that approach more, we could have a shorter
release cycle
because new features are already waiting on a branch to be
merged
right after the latest branches off for a release.

This way, right after a release we already have something
new and
exciting for a new release... (Which should be an
encouragement to
'not post-pone' as we have been doing with 1.5 when we
started
merge-tracking. We already had releasable material when it
started...)

Anyway, +1 to post-poning ctypes and svnpatch, to be merged
to trunk
right after branching 1.5.

bye,

Erik.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Oct 4, 2007, at 7:09 PM, Ben Collins-Sussman wrote:

> Hm, I guess I disagree.  'svn patch' doesn't feel like
a such a huge
> feature to me that it's worth holding back.  If were
half-implemented,
> sure, we wouldn't want to wait on it.  But it's
basically finished...
> it just needs some testing now, and I think it will
(frankly) get a
> heck of a lot more testers attracted to it than
merge-tracking.
> (Mainly because it's a much simpler, much more
accessible new
> feature.)

These suspicions about their relative testability are
probably  
sound.  'Course, if we already *had* merge tracking, then
we'd be  
just that much less concerned about merging the patch branch
back in!

-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning




------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 10/4/07, Hyrum K. Wright <hyrum_wrightmail.utexas.edu> wrote:
> Just wondering where we're at in the process of merging
the
> svndiff-patch branch to trunk.  It'd be good to get it
there so others
> can start playing with it, and to get it into the 1.5
release.  I'd hate
> to have to wait until 1.6 to release code from SoC
'07.
>
> I know that Charles has been working on the branch a
bit lately.
> Charles, what would it take to get it mergeable, and do
you think you
> can have that ready in the next day or two?
>
> It'd also be good if some of the committers reviewed
what's there.  I
> haven't had the chance to yet, but hope to take a look
sometime this
> weekend.

I am personally -1 on merging this branch to trunk until it
gets quite
a bit more review.  As far as I can, a large amount of
Charles'
commits were not reviewed by any committers.  I have started
doing
some review recently, but (a) that was only after a large
amount of
the work was done and (b) my comments were often somewhat
superficial.

My general impression of the branch is that it is an
important feature
that we should try to get released by 1.6 at the latest, but
that
there are actually a huge number of complications that I
don't think
were recognized until Charles actually tried to do it. 
Charles is
doing a great job*, but the feature is complex enough that
more review
of his commits (not just the newer ones, but the earlier
ones that
didn't get any review) is essential in order for us to be
confident
that the implementation lives up to the project's
standards.

I will try to keep reviewing his new commits, but I'm not
sure if I
have time to go back and look at the older ones.  Can anyone
volunteer
to do so?

(I am also generally concerned that 1.5 will end up being a
release of
a large number of half-baked features.  It's also worth
pointing out
that the big features currently being implemented (merge
tracking,
sparse directories, extra copyfrom information, svnpatch,
etc etc etc)
do interact with each other in subtle and complicated ways. 
Pushing
at least one of them off until 1.6 will limit the
combinatorial
explosion of interactions between new features in 1.5.)

--dave

* and please don't read anything in this vote to suggest
otherwise!
I'm really happy with Charles's work so far... but the
feature is
complex enough that one newcomer to the project shouldn't be
expected
to be able to complete it solo without much review!

-- 
David Glasser | glasserdavidglasser.net | http://www.davidglasser.
net/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On Fri, 05 Oct 2007, Erik Huelsmann wrote:
...
> Anyway, +1 to post-poning ctypes and svnpatch, to be
merged to trunk
> right after branching 1.5.

While I'd love to get the svnpatch branch into 1.5, the
combinatoral
concerns cited by glasser really resonate with me.  Given
that, I'd rather
follow Erik's suggested approach.
-- 

Daniel Rall

On 10/5/07, David Glasser <glasserdavidglasser.net>
wrote:

> I am personally -1 on merging this branch to trunk
until it gets quite
> a bit more review.  As far as I can, a large amount of
Charles'
> commits were not reviewed by any committers.  I have
started doing
> some review recently, but (a) that was only after a
large amount of
> the work was done and (b) my comments were often
somewhat superficial.

For what it's worth, I agree with David on this.  I'm very
much
looking forward to the feature being merged and released,
but I don't
think it's gotten the attention it needs.

Again, not trying to put down Charles' work, he's done a
fantastic job
as far as I can tell, but it is a tough problem and we want
to make
sure we've gotten it right before anything goes into a
public release
and becomes intertwined with our backwards compatibility
promises and
so forth.

-garrett

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

I, too, am now persuaded we should delay the patch-stuff for
svn 1.6.  

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org