[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Smith
Subject: Re: [Arx-users] The Future (long)
Date: Thu, 08 Dec 2005 20:15:48 -0500
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051011)

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]