Ok, this was literally screaming for a rebuttal! :-)
> Arch isn't a sound example of software design. Quite contrary to the
>
> random notes posted by it's author the following issues did strike me
>
> the time I did evaluate it:
>
(Note that here you take a stab at the Arch design fundamentals, but
actually fail to substantiate it later)
> The application (tla) claims to have "intuitive" command names. However
>
> I didn't see that as given. Most of them where difficult to remember
>
> and appeared to be just infantile. I stopped looking further after I
>
> saw:
>
[ UI issues snipped, not really core design ]
Yes, some people perceive that there _are_ UI issues in Arch.
However, as strange as it may sound, some don`t feel so.
> As an added bonus it relies on the applications named by accident
>
> patch and diff and installed on the host in question as well as few
>
> other as well to
>
> operate.
>
This is called modularity and code reuse.
And given that patch and diff are installed by default on all of the
relevant developer machines i fail to see as to why it is by any
measure a derogatory.
(and the rest you speak about is tar and gzip)
> Better don't waste your time with looking at Arch. Stick with patches
>
> you maintain by hand combined with some scripts containing a list of
>
> apply commands
>
> and you should be still more productive then when using Arch.
>
Sure, you should`ve had come up with something more based than that! :-)
Now to the real design issues...
Globally unique, meaningful, symbolic revision names -- the core of the
Arch namespace.
"Stone simple" on-disk format to store things -- a hierarchy
of directories with textual files and tarballs.
No smart server -- any sftp, ftp, webdav (or just http for read-only access)
server is exactly up to the task.
O(0) branching -- a branch is simply a tag, a continuation from some
point of development. A network-capable-symlink if you would like.
It is actually made possible due to the global Arch namespace.
Revision ancestry graph, of course. Enables smart merging.
Now, to the features:
Archives/revisions are trivially crypto-signed -- thanks to the "stone-simple"
on-disk format.
Trivial push/pull mirroring -- a mirror is exactly a read-only archive,
and can be turned into a full-blown archive by removal of a single
file.
Revision libraries as client-side operation speedup mechanism with partially
automated updates.
Cached revisions as server-side speedup.
Possibility for hardlinked checkouts for local archives. This requires that
your text editor is smart and deletes the original file when it writes
changes.
Various pre/post/whatever-commit hooks.
That much for starters... :-)
---
cheers,
Samium Gromoff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
