Re: [Arx-users] The Future (long)

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> >>It seems that the primary use of bzr shelve is:
> >>
> >>I have made several changes to my working tree, but they really should 
> >>be two different revisions/changesets. I can "shelve" some of my 
> >>changes, leaving me with a single changeset that I can test and commit. 
> >>Then I can unshelve those changes, test the full result, and commit the 
> >>second revision. It includes darcs-style per-hunk selection.
> > 
> > 
> > This is supported through "arx undo".  "bzr shelve" has the option of
> > per-hunk undo's.  That is not present in "arx undo", but could be
> > added.
> 
> Ummm. Not sure about that. brz shelve allows you to set aside changes 
> that have never yet been checked in.

This is exactly what undo does.  "arx undo foo" reverts all changes
made to file foo.  It stores it in a directory ,,undo.N.  Running "arx
redo" reapplies the changes.  It allows you to have any number of
pending changes to the tree.

> The philosophical goal is that you never create a revision that
> didn't exist completely in a testable form in the working tree.

I have heard this philosophy many times.  Enforcing it in the tool
gets wearisome.  ArX is my slave, not my master.  I really am sure
that updating the NEWS file does not require me to run all of the
tests again.  If you really want to enforce this kind of thing, that
is what a pqm is for.

> With CVS, I often check in a few files at a time, with different commit 
> messages, indicating that they were different tasks.

ArX allows that as well.  I use it all the time.

> With darcs, commit allows you to include/exclude hunks. Both of
> these run the risk of committing something that doesn't even
> build. Granted, darcs has a cool automated test facility that could
> catch most problems.
> 
> Another approach would be to check in everything, and then back out each 
> set of changes related to particular tasks, and then check them back in. 
> That's kind of messy, too.
> 
> So unless arx undo is doing something I'm not aware of, it is somewhat 
> different. I would be fine having arx shelve as a separate tool (it's a 
> bzr plugin), but it is a valuable feature at some point.

Except for the per-hunk part, I think ArX has what you want.

> >>It seems that the primary use of quilt is:
> >>
> >>I am tracking an upstream repo. I am maintaining several of my own 
> >>patches on top of that repo. Every time I sync with the upstream repo, I 
> >>can push my patches (changesets) aside, sync with upstream, and then 
> >>re-apply my patches on top. The unit of work is changesets, not files or 
> >>hunks.
> >>
> >>Further, I can (or at least theoretically could) do patch refactoring:
> >>- Combine small patches into a single large patch
> >>- Split a large patch into several smaller patches
> >>- Reorder patches
> >>- Modify the patch description or other metadata
> > 
> > 
> > This is only partly supported.  Combining and splitting patches is
> > supported.  Having multiple patches that can only apply in a certain
> > order is more tricky.  ArX wants a tree to diff against, and the only
> > one available is the original pristine.  I could see how it could be
> > done, but I think it would be best as a separate tool (like mq).
> 
> Separate tool would be fine, as long as it could be built. I'm not sure 
> what you mean by "can only apply in a certain order". The main thing is 
> having a pool of patches that you can reapply. Normally it would be 
> easiest for the SCM tool to keep them in the same order, but I'm not 
> sure that's strictly necessary.

You can easily create a number of independent patches.  It is just
non-trivial to create patches against a patched tree, so a patch that
depends on having another patch applied is difficult to create and
maintain.  In general, you have to do a lot of the patch maintenance
yourself.  That could be automated, but I think it would be best in a
separate tool.

Cheers,
Walter