Better name for dpush wanted

[Harald Meland]

[Ben Finney]

> Jelmer Vernooij <jelmer at vernstok.nl> writes:
>
>> Ben Finney wrote:
>> > I'm against adding another command; conceptually, it's the same
>> > operation as ‘push’ with a different option.
>> >   
>> It's conceptually different from push: it does not copy revisions from
>> the source branch to the remote branch, it creates derived versions of
>> the source branches' revisions in the target branch. It also changes
>> the source branch, something which push should never ever do imo.
>
> I still don't understand why it would be necessary for this operation
> to alter the source branch,

I haven't used the dpush command at all, but I think its modus
operandi is something like this:

  1. You get your bzr branch from svn.  The bzr revisions are
     "special" in some way; they know which svn revisions they
     correspond with; this is e.g. useful for "bzr missing".

  2. Next you commit some revisions in your bzr branch.  These extra
     revisions aren't known in svn yet, and so do not know how they
     (will) correspond with svn revisions.

  3. Now, you want to publish your bzr-only revisions to the svn
     repository, but you'd rather avoid publishing bzr-specific
     metadata (as that can lead to noisy commit-mails and so on); you
     use "bzr dpush".

  4. The part that's transforming your bzr-only revisions into new
     (derived) svn revisions is obvious (at least conceptually, I
     hope), but what about the need for having the previously bzr-only
     revisions know which svn revisions they correspond to?  AFAIK,
     bzr revisions are immutable once committed, so you can't just add
     the extra now-available svn-derived metadata to these revisions
     after the fact.

  5. The answer is to create new bzr revisions based on the
     bzr-revisions-that-have-now-been-transformed-to-svn-revisions,
     which is not entirely unlike a rebase operation.

-- 
Harald