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/
- Prev by Date: Re: [PATCH] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
- Next by Date: Re: [PATCH] I2C rtc8564.c remove duplicate include (fixed)
- Previous by thread: Re: Kernel SCM saga..
- Next by thread: Re: Kernel SCM saga..
- Index(es):
 |