the 'takeover' feature

Jonathan,

Thanks for being so patient. I think your patch will make for a great
new feature -- it's just that most of the developers haven't had time
to study your patch. We've all been busy with other features.

Despite the delay, I think the last batch of emails showed that there
*was* a general consensus on what we'd like to see in your patch. And
it's obvious that you took a lot of time and care -- your code is
meticulous.

Would you be willing to submit a new version of your patch (the one
attached to issue 2392) which:

    * implements 'svn checkout --takeover' rather than 'svn takeover'

          --> We have a great resistance to adding new subcommands.
              The main use-case for this feature is to avoid having to
              to do a full checkout immediately after an import.

    * actually saves bandwidth

          --> The client should ask the server for a tree-delta that
              doesn't contain any inline filedata; this probably means
              driving the editor returned by svn_ra_do_status(), rather
              than the one returned by svn_ra_do_update(). We'll have
              to add an svn_ra.h API as well, so that checksums are
              fetchable -- either by adding a flag to do_status(), or
              defining a new function. If the checksum matches the
              existing working file, then it gets installed as the
              text-base. If not, the text-base is wholly fetched.

    * has a log message which conforms to our hacking.html guidelines

          --> Your log message is wonderfully written and amazingly
              (almost too) verbose. Instead of writing "added new
              field 'foo' to function 'bar'", our convention is to put
              function names in parens:

                   (bar): added new field 'foo'.

    * is written against /trunk, rather than the 1.2.0 tag

          --> Yes, trunk is a moving target, but not as much as you
              think. The chances that someone is changing the exact
              same functions as you is quite small. And, since new
              features are only allowed to be committed against trunk
              anyway, it's far easier for the author of the patch to
              write against trunk, rather than make a reviewer forcibly
              port the patch to trunk later on.

The patch in question (attached to 2392) doesn't have the rsync stuff
in it, which is just fine. The rsync code might make the takeover a
bit faster, but most of the speedup comes from not having to do a
complete checkout... and we're not convinced that the extra code
complexity is worth the extra speedup. I know you were zealous about
this, so maybe you can submit it as a followup patch to evaluate later
on, after the main patch is applied...?

I hope you have given up hope on us. If you come back with
another iteration of the change, I promise to help you steer it
through to completion.

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org