Issue 747: Moving (and copying) multiple files

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

Issue 747 succinctly states:
'svn mv *.c somedir' does not work. It should.

Over the past few months, I've been working on a patch which will allow
just that.  Instead of the naïve approach, which previous patches have
attempted (looping in the command line client), my approach introduces a
new client-level API (svn_client_[copy,move]_into) and uses that to fold
multiple moves into the same commit.  It supports both version of move,
repo->repo and wc->wc, as well as all four directions methods of
multiple copy, repo->repo, repo->wc, wc->repo and wc->wc.  I've also
added additional tests for this functionality and the patch passes all
existing tests.

The one uncertainty I have is how to submit it.  The patch is almost 70
kB and close to 2000 lines long.  I'm happy to break it into chunks, but
I would like to know if there is a preferred way to break something like
this up.  Should I introduce new APIs, and then introduce changes to the
client which use them?  Should I change the client, stub out the new
APIs and then submit the new functionality?

No doubt there will be some review on the patches as they come in, and I
am sure they can be optimized in places, but I just wanted give people a
heads up that they are coming.

-Hyrum

Re: Issue 747: Moving (and copying) multiple files

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

Ivan Zhakov wrote:
> On 11/19/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
>> On 11/19/06, David Glasser <gl...@mit.edu> wrote:
>>
>> > Probably other people have more wisdom here; I think sending the
>> > single massive patch (or uploading it to the issue, as it is big) is a
>> > reasonable start, though you're probably right that breaking it up for
>> > review and smaller commits may be the way to go eventually.  But I'd
>> > rather there be a massive patch on the issue tracker than have it
>> > vanish if you don't find the time to break it up soon.
>> >
>>
>> What would people think if we gave Hyrum a private feature branch?
>> Hyrum could then commit his massive change to the branch in small
>> pieces, and the automatic commit-emails would make it easier for the
>> rest of us to review the chunks.
> +1
> I had the same idea.

That would be great!

-Hyrum

Re: Issue 747: Moving (and copying) multiple files

[Ivan Zhakov <ch...@gmail.com>]

On 11/19/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 11/19/06, David Glasser <gl...@mit.edu> wrote:
>
> > Probably other people have more wisdom here; I think sending the
> > single massive patch (or uploading it to the issue, as it is big) is a
> > reasonable start, though you're probably right that breaking it up for
> > review and smaller commits may be the way to go eventually.  But I'd
> > rather there be a massive patch on the issue tracker than have it
> > vanish if you don't find the time to break it up soon.
> >
>
> What would people think if we gave Hyrum a private feature branch?
> Hyrum could then commit his massive change to the branch in small
> pieces, and the automatic commit-emails would make it easier for the
> rest of us to review the chunks.
+1
I had the same idea.

-- 
Ivan Zhakov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Issue 747: Moving (and copying) multiple files

[David Glasser <gl...@mit.edu>]

On 11/19/06, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 11/19/06, David Glasser <gl...@mit.edu> wrote:
>
> > Probably other people have more wisdom here; I think sending the
> > single massive patch (or uploading it to the issue, as it is big) is a
> > reasonable start, though you're probably right that breaking it up for
> > review and smaller commits may be the way to go eventually.  But I'd
> > rather there be a massive patch on the issue tracker than have it
> > vanish if you don't find the time to break it up soon.
> >
>
> What would people think if we gave Hyrum a private feature branch?

+1

--dave

-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Issue 747: Moving (and copying) multiple files

[Ben Collins-Sussman <su...@red-bean.com>]

On 11/19/06, David Glasser <gl...@mit.edu> wrote:

> Probably other people have more wisdom here; I think sending the
> single massive patch (or uploading it to the issue, as it is big) is a
> reasonable start, though you're probably right that breaking it up for
> review and smaller commits may be the way to go eventually.  But I'd
> rather there be a massive patch on the issue tracker than have it
> vanish if you don't find the time to break it up soon.
>

What would people think if we gave Hyrum a private feature branch?
Hyrum could then commit his massive change to the branch in small
pieces, and the automatic commit-emails would make it easier for the
rest of us to review the chunks.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Issue 747: Moving (and copying) multiple files

[David Glasser <gl...@mit.edu>]

On 11/18/06, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> Issue 747 succinctly states:
> 'svn mv *.c somedir' does not work. It should.
>
> Over the past few months, I've been working on a patch which will allow
> just that.  Instead of the naïve approach, which previous patches have
> attempted (looping in the command line client), my approach introduces a
> new client-level API (svn_client_[copy,move]_into) and uses that to fold
> multiple moves into the same commit.  It supports both version of move,
> repo->repo and wc->wc, as well as all four directions methods of
> multiple copy, repo->repo, repo->wc, wc->repo and wc->wc.  I've also
> added additional tests for this functionality and the patch passes all
> existing tests.

Hyrum, if nothing else, I want to say that it's great that you're
working on this, because this is a seriously annoying deficiency which
as you've seen is a reasonable amount of work to fix.  Thanks!

> The one uncertainty I have is how to submit it.  The patch is almost 70
> kB and close to 2000 lines long.  I'm happy to break it into chunks, but
> I would like to know if there is a preferred way to break something like
> this up.  Should I introduce new APIs, and then introduce changes to the
> client which use them?  Should I change the client, stub out the new
> APIs and then submit the new functionality?

Probably other people have more wisdom here; I think sending the
single massive patch (or uploading it to the issue, as it is big) is a
reasonable start, though you're probably right that breaking it up for
review and smaller commits may be the way to go eventually.  But I'd
rather there be a massive patch on the issue tracker than have it
vanish if you don't find the time to break it up soon.

--dave

-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org