Messages in this thread | | | From | Samium Gromoff <> | Subject | Re: Kernel SCM saga.. | Date | Sat, 09 Apr 2005 15:02:38 +0400 |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |