[darcs-users] Re: bookmarks

Csaba Henk dzsekijo at creo.hu
Thu Mar 31 07:46:04 UTC 2005

On 2005-03-31, Phil Frost <indigo at bitglue.com> wrote:
> On Wed, Mar 30, 2005 at 10:32:56PM +0000, Csaba Henk wrote:
>> So, what do you think of supporting a lightweight, non-constraining form
>> of archive registry, namely bookmarks?
> bash has this feature.
> put this in ~/.bashrc:
>     <nick>='<repo loc>'
> start a new bash, or reload the rc in a new one:
>     source ~/.bashrc
> and run darcs like so:
>     darcs push $nick

Unix shells' features are sorely lacking. They won't give you
reflection, and flexible configuration of these data. Even if you can do
something like this, that will be an ugly, painful kludge. (How good I
don't write anymore anything in shell over 3 LOC...)

Apart from shell, I understand that you could manage this stuff with an
external tool somehow. But if you wanted to make it really good, that
would take time and would be a more complex problem than just adding
this feature to darcs itself. Not a big deal, advanced ftp clients like
yafc and ncftp have such a feature, and ints nicely integrated with the
flow of interaction (just play for a five minute with these). Well, it's
all about user friendliness. The possility of being able to write
wrapper scripts is a basic interface requirement since Unix hit the
ground with its toolbox philosophy; however my idea of the optimal user
interface is one where just noone happens to think of wrapping (when it
comes to user interaction).

It's arch where no guru touches the binary itself, they rather use the
emacs interface or tons of custom wrapper scripts... Luckily darcs is
far from that state.

Otoh, if such an info would be made available by darcs itself, other
kind of interfaces (guis, eg.) could make use of it in an uniform and
predictable way. As by the current situation, the gui designer wouldn't
know of my cool cli wrappers/filters. And then, if s/he also happens to
be considered about this problem, s/he will roll her/his own, in an
arbitrary way...

> One could argue that it would be better to attach these data to the
> repo, but different people access the same repos in different ways. For
> example, my project has a master repository which collects stable
> changes from all developers. I access it over ssh because I'm a
> developer and have an account on that box. However, others access it
> over http because they don't have a shell account or write access.

No, I didn't think of attaching this info to the repo. I tought of
attaching it to the account (~/.darcsrc (or how is that called),
practically), and it wouldn't be seen from the outside.

> I don't think protocol independent names for repos is terribly useful.
> When I say, "our master repo", or really even "the repo", everyone knows
> I'm talking about a very specific repo, and also knows how to access it.
> With arch, one must initially tell it how to access the repo anyway, so
> it's only useful if you somehow remember the name of repo but not how to
> access it. Since the names must be unique, they must be pretty long, and
> thus they are hard to remember anyway. So, I'd say this feature is a lot
> of complication for very little gain.

In arch, these names are long as their presence is insitutionalized.
With bookmarks, you could do it according to your liking. Eg., noone
would tell you not to call the repo of Darcs itself just "darcs", or the
repo of Chicken Scheme just "chick", and your master repo "master" or
"the_repo". Noone would tell you to map all the repo locations you have
ever considered to nicks uniquely.

Considering protocoll independence: the location would contain the
protocol precisely, the name itself wouldn't (unless you want, say,
because you interact with a repo both via http and ssh, like
"master_web" and "master_ssh" (or "webmaster" if you like bad puns)).


More information about the darcs-users mailing list