Re: [Gnu-arch-users] GNU Arch review - am I accurate?

[Adrian Irving-Beer]

On Wed, Mar 03, 2004 at 07:07:09AM +0000, David A. Wheeler wrote:

> There are some things I didn't see:
> * Is anyone currently working on automated caching?

As I learned the other day, cacherev'ing is now default when cycling an
archice, i.e. tagging from one archive to another.  (Great feature,
thanks!)  That aside, I don't know of any other automated cacherevs.

> * Is it even slightly plausible to change the default
>   filename/tagname conventions so arch will
>   work more easily with common tools (e.g., vi/vim, more, csh,
>   bash, Windows (it doesn't handle long names well))?
>   Conventions are so arbitrary, yet the ones arch uses
>   seem designed to cause unnecessary problems.

Unsure of what you mean by this one.

The only long-named files the user ever typically has to deal with are
files created by 'tla make-log', which you typically use as 'vi `tla
make-log`' anyway.  (I wrote a 'makelog' script to do this, and am now
migrating to 'aba elog'.)

If you mean file naming ({arch}, +, =, etc.), these are dealt with on
wiki.gnuarch.org under 'FunkyFileNames', and I don't have much to add
about them.

I like em, personally, and I don't think they're going to change; but
then, I run Unix exclusively, where perhaps they're less of a trade-off.

> * Is there any reason that "mv" and "move" couldn't be the
>   same thing (and let mv-id or an mv flag be the id mover)?

Don't see why not; however, I usually use tagline instead of explicit,
so I'll let the explicit-junkies respond to this.

> * Has anyone thought about the "signing of signing" issue
>   (A signs A's code, B accepts it, C accepts B's, and we
>   have a chain of signatures from all 3 showing the transition)?
>   Centralized systems don't need this as much, but distributed
>   systems need more if you're going to show where code came from.

As I see it, signing was meant mainly as a way to simply certify code
against modification.  It doesn't do anything to guarantee the quality
of the code.  Same way a PGP signature doesn't confirm someone's words
as the gospel truth; only that the words came out of their mouth, which
may be just as bogus as someone else's unsigned claims.

That being said, signing of someone else's *code* effectively occurs
when person B merges person A's signed code into their signed project
and signs it on commit.  Somehow preserving A's signature would be nice,
but what if the code doesn't merge cleanly (i.e. has conflicts, or
breaks the application) and needs modification?

Frankly, it all comes back to trust -- if I really don't trust person B
to write good code with no sneaky back-doors, I'm not going to run her
software, no matter how many other people contribute to it.  YMMV.

> * Is there an intent to fix the remaining problems in the
>   native Windows port (e.g., symlinks, newline oddities)?

No clue.  Does XP now have full support for symlinks, or what?  I heard
rumours to that effect.

> Also - has anyone tried to compare BitKeeper and Arch in detail?

Maybe you saw it already, but http://better-scm.berlios.de/comparison/
is broad, if not particularly detailed . . .

> For example, BitKeeper claims its 3-way merge is better than anyone's,

. . . but conspicuously misses the aspect of merging.  Considering the
site is so anti-CVS, and merging is one of CVS sorest points, I can't
figure out why!

Wish I could say more, but I've never done a three-way merge.  And while
I carefully researched SCMs to find an alternative to CVS, my
consideration of BitKeeper was dismissed, with prejudice and no chance
of appeal, when I hit the bit about licensing.

'tla file-diff3' command, anyone?  (To make diff3ing against an older
version possible without checking it out?)  Or some tricks involving
combinediff/interdiff?

signature.asc
Description: Digital signature