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

[Kevin Smith]

Walter Landry wrote:
> With the exception of the manifest file, I don't think any of the
> formats uses raw binary.
>
>
> > 2) That the full file spec is documented. I want to be able to write a 
> > tool in any language to access the data, and reverse-engineering binary 
> > data is a royal pain. I think this is more important to me than #1, and 
> > I would shy away from a format that might change at any moment due to 
> > the whims of the boost developers. Unless they provide assurances about 
> > stability.
>
>
> Documenting the file spec is not hard.  Once it is all implemented, I
> can certainly do that.  Also, the format only changes when I decide to
> incorporate a new version of boost.

Ok. I would still rather use a format (even a binary format) that you 
control completely, but I can live with this one simple boost-serialized 
binary file.

> > Even so, disallowing newlines and nul bytes doesn't seem like a
> > severe limitation on branch names.
>
>
> It is not just newlines.  Some encodings like to use null's, and ArX
> should not be getting in the way.

Ah. I was thinking that everything would be UTF-8 by the time it was 
stored, but especially if we're including filenames, that would be a bad 
assumption.

> > > > You mentioned several drawbacks of skip-deltas. What are the big 
> > > > benefits they bring, and what alternatives did you consider?

(I'll reply to this separately)
> > My concern is simply that MS-Windows FAT32 users should not be 
> > second-class citizens. They should be able to work as efficiently, using 
> > the same processes, as other folks. That's not the case right now with 
> > darcs or mercurial. Or bzr, but the bzr folks are working on it.
>
>
> I see what you're thinking. I think you don't have to worry about it.

Yes, that's what it sounds like.

> > 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. The philosophical goal is that you 
never create a revision that didn't exist completely in a testable form 
in the working tree.

With CVS, I often check in a few files at a time, with different commit 
messages, indicating that they were different tasks. 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.

> > 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.

> > There are some concerns that mq is dangerous because it can remove 
> > changesets from a repo that may already have been published. Darned 
> > handy, though.
>
>
> I don't see how there could be any danger in the context of ArX.  It
> is as if you published some microbranches that are no longer being
> developed.  That is one of the benefits of separating the project tree
> from the repo.

I think that makes sense.

> > I understand the hassle of using indirection to avoid using branch names 
> > as filenames, but that still seems like a significant problem to me.
>
>
> There are basic problems with reliability that I don't want to expose
> ArX to.

Ok. Just make sure it's well documented. If you want portability, stick 
to a common subset of characters in your [xxx] names. (I'll leave it to 
you to figure out all values of xxx.

> But streamy diffs are required for big (larger than memory) files.

True. I was thinking that it's enough to have a diff that just says SAME 
or DIFFERENT. Doing that in a streamy way is entirely trivial.

> That would be simple enough to add with an alias command.  However, I
> want to thoroughly implement what I have, and then we can see if this
> sort of thing is required.

Makes sense. I can't think of why it would cause problems. Except that 
you resisted it in ArX 2 :-)

> The standard problem is that the file you have on disk is not the file
> you commit to the repo.  Automatic conversion just gives me the
> heebie-jeebies, especially since ArX goes to so much effort to ensure
> file integrity.  Also, Subversion is _still_ having problems from
> line-conversions.

Interesting. Hopefully hooks will be an answer for projects that 
absolutely need that capability.

> Doing C++ plugins portably would be a bit of a pain.  I am more
> inclined to get everything else working first.

Makes sense. I doubt there are many of us who would be interested in 
writing C++ plugins. I do think ArX would generate more excitement and 
participation if people could easily enhance it with python or ruby code.

Kevin