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

[Jan Hudec]

On Wed, Mar 03, 2004 at 07:07:09 +0000, David A. Wheeler wrote:
> Hi - I've been trying to understand various SCM tools
> (primarily CVS, Subversion, and Arch), and
> ended up putting my thoughts down in an article:
>  http://www.dwheeler.com/essays/scm.html
> I list a number of problems/issues I have with tla's
> current implementation, but I'm obviously not an arch
> guru, so please send me corrections where I've made mistakes.
> 
> I really like arch.  My congrats to Tom Lord et al
> for the many clever ideas here.  Yet, I'm also frustrated
> by arch's current implementation (tla 1.2) due to various issues.
> It appears to me that several small things obscure an
> outstanding program.  In at least some cases, I
> think people are working on my concerns
> (Windows support, archd, etc.).. but not all.
> 
> There are some things I didn't see:
> * Is anyone currently working on automated caching?

- If you mean automatic adding to revision library, that works for some
  time already. There are some options to set by library-config command.
- If you mean automatic creation of cached revisions, I have not heared
  about it, except it's a trivial shell script to set as hook.
- There is currently work on "smart" server, that will be able to do
  caching and patch combining.
- There is currently work on backpatching logic (creating older version
  by backpatching newer version from library).

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

- If you mean the builtins -- `,' for temporary and `+' for precious --
  what other characters would you prefer? All the rest is fully
  customizable -- just rewrite {arch}/=tagging-method

> * 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)?

- It's already settled this way.

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

- Don't think it has actual use. Moreover, no, it's not possible, since
  the diffs are combined on merge, so the parts are not there to be
  signed.

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

- Sure. All three windows ports are being worked on.

> Also - has anyone tried to compare BitKeeper and Arch in detail?
> For example, BitKeeper claims its 3-way merge is better than anyone's,

BitKeeper's 3-way merge is a graphical tool to resolve conflicts. It is
arguably better then open-source tools aiming to do the same. The
underlaying mergeing mechanism is the same, however.

> and Monotone claims its 3-way merge is better than Arch's, but

As I looked monotone's page, it seems, that they have the same
mechanism, just they don't understand arch has it too. However, they
might be a bit better if they search other branches for common ancestor.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature