please store binary blobs in $XDG_DATA_HOME, not $XDG_CONFIG_HOME

[bremner]

For me, config is something I can edit with a text editor. So I think the repos belong on $XDG_DATA_HOME.

I admit that 1) this is pretty subjective. 2) most software that uses XDG_CONFIG_HOME does it wrong according to my definitions. But we can do better, right ? ;)

[RichiH]

As per IRC, the main problem is to deal with legacy. My only real answer is a softlink...

Richard

Sent by mobile; excuse my brevity.

[bremner]

Richard Hartmann [email protected] writes:

As per IRC, the main problem is to deal with legacy. My only real answer is a softlink...

Let me see if I understand the problem. The problem is changing the default for VCSH_REPO_D, and having new vcsh unable to find old repo.d ? what about having it look in both places if no explicit value is given for VCSH_REPO_D ? I guess it's not so nice to special case that variable; maybe you could convert it to a path, then give a default value with $XDG_DATA_HOME first?

d

[RichiH]

What happens when, not if, someone uses an old release with a migrated $HOME?

I only see symlinks as a way out.

Richard

Sent by mobile; excuse my brevity.

[bremner]

Richard Hartmann [email protected] writes:

What happens when, not if, someone uses an old release with a migrated $HOME?

I only see symlinks as a way out.

They lose. I would find that acceptable, but I guess you don't.

d

[nfarrar]

I would agree that $XDG_CONFIG_HOME is not the proper place for the repo.d directory. However - I also do not think that $XDG_DATA_HOME is correct.

While these are 'binary blobs' - they aren't data you'd want to backup or transport to another system. I believe it would be most correct to stored them in $XDG_CACHE_HOME.

[4nd3r]

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

not really sure if repository is non-essential. things shouldn't break if you delete .cache content.

[RichiH]

cache is not an option; it's ephemeral by definition...

@bremner I think I can use the new path for new clones etc, then check both paths every time I do any action and print a warning if both exist. Sounds sane?

[bremner]

Richard Hartmann [email protected] writes:

cache is not an option; it's ephemeral by definition...

@bremner I think I can use the new path for new clones etc, then check both paths every time I do any action and print a warning if both exist. Sounds sane?

Sure.

d

[alerque]

What happens when, not if, someone uses an old release with a migrated $HOME?

I think I'm with @bremner on this on, they loose. And I'm okay with that.

I don't think they loose too badly though. At worst they just wouldn't see anything created under a new version.

Proposal:

• Start creating new repos in $XDG_DATA_DIR.
• Look for them in $XDG_DATA_DIR first, if found use them there.
• If not found, rather than throwing a "repository not found" error right off, add a check to make sure they aren't in the legacy location. If they are, throw a warning to STDERR about legacy locations and how to migrate them, but carry on with the operation anyway.
• Add a migrate or upgrade or setup command that moves any legacy repos to the new default location.
• Add a git config key to newly initialized or upgraded repos that identifies the version of VCSH being used. This will make future upgrade checks a lot easier.

I think all those steps can be done pretty safely and the case of old vcsh being used on new data will be both rare and fail gracefully.

[RichiH]

Sounds good. Making the functionality part of the existing vcsh upgrade allows a simple vcsh foreach -g vcsh upgrade and the whole system is upgraded to the current layout.

vcsh upgrade mirrors e.g. git-annex which also simply upgrades to the most current version the code being run knows about.