[RFC] history editing vs history presentation

[Robert Collins]

On Wed, 2009-06-10 at 13:19 +1000, Jonathan Lange wrote:
> On Tue, Jun 9, 2009 at 4:12 PM, Robert
> > Splitting or joining code
> > -------------------------
> >
> > VCS systems require users to make fairly arbitrary divisions between
> > code they manage, and code that isn't managed. Often users make
> > decisions that later experience shows would be better made differently.
> >
> 
> For example, taking a project managed as one tree/branch and splitting
> it into two distinct projects?

Yes. Or starting with a very structured set of projects and realising
the structure is a burden.

> > A subset of the changes introduced are wanted - e.g. a slice of some
> > sort through time. This sort of edit is sometimes very simple, and
> > sometimes very complex - consider detangling a library which was in a
> > subdir but wasn't perfectly isolated. Joining code is similar but in
> > reverse. Note that doing a merge between two projects to get their
> > history to join is not the same thing as editing the history so they
> > appear to have had a single origin: In the latter case you end up with
> > one history root, whereas in the former case you have two and there is
> > no clear version of the subproject to use at any given point in the
> > upper project.
> >
> 
> FWIW, I had to read these two paragraphs a couple of times to figure
> out what was meant.

Thanks, I will reword when making a more permanent version of this.

> >
> > A call to arms
> > ++++++++++++++
...
> Agreed.
> 
> As far as I can tell, this won't actually address the split/join,
> tweaking or cherrypicking cases, only the polishing case -- is that
> right? If so, what do you think we should do to address the other
> three cases?

We have a design for incremental deployment of better cherrypicking.
JFDI according to that design. Splitting and joining edits require
filter-branch style tools and I think they would naturally live in the
same toolbox. I their frequency of use is lower but that shouldn't
preclude us writing them.

> I personally would love to see a patch-centric loom-like feature in
> Bazaar core. The principles you describe (clear warnings, one system
> that scales from single developer to multiple folk, etc) are the right
> ones, I think, but they are only a starting point. This RFC doesn't
> say what such a feature would actually look like or how it would
> work.[1]
> 
> What should it look like? How would it work? What do we have to do to
> get this wonderful new UI?

I have a few UI and data model ideas; I'd like to get broad consensus
and input on this analysis first :- nothing worse than going off into
ivory towers of theory on a shaky basis.

In particular, as Stephen Turnbull has made a very strong case for
history-presentation as one of the things that make git attractive I'd
like his thoughts.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090611/f3ec4f89/attachment.pgp