bzr copy (Re: Weekly 0.10 release status)

[Andrew Bennetts]

On Tue, Aug 15, 2006 at 10:22:17AM +0200, Stefan (metze) Metzmacher wrote:
> Hi *,
> 
> I think 'bzr copy' or at least the storing format for it should go into
> the final 1.0 release. I'm not sure howmany releases will happen before 1.0.
> 
> See http://bazaar-vcs.org/BzrFileCopies.

It's not clear to me what exactly this is proposing -- the semantics of the "bzr
copy" command are far from clear.  Is it purely recording that NEWFILE started
as a copy of ORIGINAL, so that annotate and log can give slightly richer
reports, or something more fundamental?  Is bzr merge affected or not (and if
so, how?)?

So, I don't actually know what you're asking to include in bzr 1.0.

The spec seems to be in two minds: what's actually wanted, and "probably" and
"possibly" use cases that don't belong in this spec (or at least should be
confined to a "Future Directions" section).  The spec needs a consistent
summary, use cases and implementation proposal that says what it wants to
happen.  Leave the ifs and maybes to the Discussion section -- or make another
spec if you have multiple proposals[1].

I think the spec needs work if it's going to be considered for 1.0.

-Andrew.

[1] Occasionally the Python "PEP" process will have multiple PEPs to address the
    same use case in different ways, as a way to explore the options.  Gradually
    some options are withdrawn or rejected until there's one (or none!) left.
    (If there's no acceptable PEP at the end, generally the python-dev community
    will write a informational PEP summarising why a particular idea will never
    be accepted.)