[Gnu-arch-users] revc responses

[Thomas Lord]

Rene and Eric:


 Rene> So, what SCM are you going to use for the new stuff?
 Rene>   - tla?
 Rene>   - plain revc?
 Rene>   - something else?

Subversion.

No, not really.  Plain revc.

 Rene> How could you, being a hacker, use any of the above three
 Rene> options when you *know* that there's a better way to do it:
 Rene> something like a new "tla" with revc storage: GNU Arch 2.0!  It
 Rene> just needs to be written :-).  And even better: you know how to
 Rene> implement GNU Arch 2.0, already!  The plan is in your head.

*Mostly* in my head.  There's always the risk that some subtask
I think is trivial turns out to be harder than expected.


 Rene> This makes you the person suited best to implement GNU Arch
 Rene> 2.0, in my eyes.  At least, this option looks more viable to me
 Rene> than you mentoring someone through the process of hacking GNU
 Rene> Arch 2.0.  Quite likely, once there's enough code out there,
 Rene> GNU Arch 2.0 will attract contributors (like: current tla users
 Rene> interested in 2.0) so you might not need to write it all
 Rene> yourself.  Plus, you know that there are a few people out there
 Rene> who would be willing to contribute at least a bit of money to
 Rene> the GNU Arch 2.0 project...

 Rene> So, while hacking the new stuff:  Ask yourself at every commit  
 Rene> whether you really don't see a point in writing 2.0.... ;-)

Thanks for the encouragement.  Let me explain my thinking:

1) It's not like I'm *not* working on -- it's just that I'm working
   on it rather indirectly.

   The stuff I'm working on will be useful during the (hypothetical) 
   development of Arch 2.0.  (It's also independently useful.)  I'd 
   actually rather have the current thing done before going further
   with 2.0.


2) Yes, I do think about that with every commit.

   Using "plain revc" it's currently awkward to work on branches.
   And if (hypothetically) I succeed in releasing stuff, that'll
   become more important.

   So, in some sense, I'm creating my own future motivation for 
   proceeding with Arch 2.0


3) The dominating issue is resources.

   I need a current project that fits available resources and Arch 2.0
   is too big for that.


4) Mentoring someone else doing it wouldn't be such a bad thing.

   I really had no intention of becoming a revision control expert
   or spending anywhere near as much time as I have on it.  There
   are other long ago shelved projects I'd much rather get back to.

   Part of my idea in suggesting the "hire your manager" approach is
   to build-in solving of the technology transfer problem

   (I didn't have high hopes the idea would work but it seemed worth
   suggesting at least).

5) I'm leary of "attracting contributors".

   As you know, I think that pattern has evolved into a corrupt
   system.


 Eric> If work were to continue on revc (and I really hope it does
 Eric> even though I can't afford to fund it), I'd like to see it
 Eric> moved to an archive format that:
        
 Eric>         1. does not rely on binary metadata formats
 Eric>         2. uses gzip instead of raw zlib compression

 Eric> Since most files are pretty small, I highly doubt that any
 Eric> performance gains by using raw zlib or a binary metadata format
 Eric> would have a noticeable impact on performance.

 Eric> I (and I suspect many Arch users) really like the transparent
 Eric> and orthogonal aspects of Arch, and would like to see Arch 2.0
 Eric> continue that tradition.

I chose the binary metadata formats because:

  a) they cut down code size and speed performance (look ma, no
parsing!)
  b) they elegantly solve "whitespace in _____ names" without escaping

Note that although he metadata formats are partly binary, they
internally use plain text wherever to do otherwise would make the 
formats platform-specific.

Also note that, with only one exception (the format of directory
blobs), the formats are strings that can't contain a nul character,
separated by nul characters.   There is at least a minor convention
in some GNU tools that recognize that format as an alternative to
newline-separated lines.

I'm unclear what advantage you see (or even what exactly you mean)
about gzip vs. zlib.  Do you mean fork/exec the gzip program?  Why
would that be an improvement?

-t