Re: Can unison better help with renamed hosts?

Tõivo Leedjärv <[email protected]> writes:

> Greg, your opposition is based on the assumption that the hostname is
> the one and only ID to be used. What I'm saying is that it doesn't
> need to be that way. If you consider the proposal from this
> perspective then (at least to me) all the opposing arguments fall
> away.

A fair point, but then we shouldn't call the replacement "name" which
has a lot of baggage (names, addresses, uids) in networking.  If it's
really an identifier (no semantics, no link to anything else), then
calling it clientidentifier avoids that baggage.

If what we are doing is saying that it should be a hostname, and we are
remediating that changing, that's different from saying that it is an
arbitrary string that should be unique and unchanging, and that we
default to hostname because it traditionally had those properties.

My real concern, though was initiating a sync from A to B and then *on
A* configuring the identifier for B, rather than having it configured on
B.  The whole point of B knowing its name is to keep state between two
computers, and if all the naming is from A, then that's no longer how it
is.  That is what seems messy.  So now B doesn't have an identifier;
each peer has a B identifier.  The archive files on B can't be
understood from "head -2", without knowing the config of every A that
has synced.

>> Do we really have a problem that is not resolved by UNISONLOCALHOSTNAME,
>> once understood?
>
> In my mind, it's just very technically involved and the user shouldn't
> be forced to go that route. You may argue that anyone using Unison is
> already technically skilled enough, but it shouldn't be that way. It
> also doesn't suit the permanent rename scenario well.

So:

  it works but it is too hard

  permanent rename is still messy

which leads me to

  we should generate a per-host identifier which can bootstrap from a
  non-dynamic dhcp name and store it, perhaps with some random bits to
  avoid collissions

  we should just use that identifier

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].