Re: Corrupt git-annex repository
On Fri, Oct 28, 2011 at 23:44, Joey Hess j...@kitenet.net wrote: git log git-annex..origin/git-annex fails, so both are *not* there. (git branch may show them, which means nothing when your repository is corrupted) Ah. Sorry, then. What I meant to say is that the only place that git-annex looks to determine the UUID of the current repository is .git/config. Of course it *stores* information about a UUID in various places -- in your example you told it to store a description test for that UUID, so status displays that even if it doesn't know of any repository that has that UUID. Notice it did not say test (here) Makes sense. Thanks :) Is there any technical reason that would make git annex init test --uuid=foo impossible? That way, I could re-use the UUID when I _know_ it's OK to reuse them. As an aside you are using v1 UUIDs, I hugely prefer v4. Is there any way to change which are being generated? The best that could be done is to add a fourth trust state that is like untrusted UUIDs but causes them to be hidden from view. But this would mean additional work, to handle this edge case -- and simply changing the description of a dead repository seems to work nearly as well. My mental implementation did exactly that: Introduce a hidden trust state. Unfortunately, this is not an edge case, for me. I have a total of three repos that died on me which means 75% of the repos I have, at the moment. After fixing everything up again, I will have 3/7 permanently gone repos in the repo graph. Unless there's a way to init while a given UUID? Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: how to refactor path duplication in .mrconfig section headers?
On Sat, Oct 29, 2011 at 03:11, Adam Spiers vcs-h...@adamspiers.org wrote: By you are you referring to me or Joey? Yes, my intention was that ~/.git-repos contains all git repos (or at least most). Yes, sorry for the confusion. If you mean, every repo *contains* its own .mrconfig, then I don't see how that would work - wouldn't it create a chicken and egg situation prior to first checkout? Exactly. The way I read Joey's, I thought that's what was being suggested. I like that scheme with things like apache (sites-available vs. sites-enabled) although with mr config, the same effect can by automated via the special 'skip' parameter, which to me seems nicer than manually fiddling with symlinks. If you use skip, you will have to manually fiddle with mr to do the first checkout ;) I still hope to sell Joey on the idea of incorporating link management in mr. A definite yes/no/onlyifyousubmitapatch would be nice, here. If that doesn't work out, I will most likely extend vcsh to do this. Along with zsh completion to grab available repos from your local setup. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: how to refactor path duplication in .mrconfig section headers?
On Sat, Oct 29, 2011 at 2:11 PM, Richard Hartmann richih.mailingl...@gmail.com wrote: On Sat, Oct 29, 2011 at 03:11, Adam Spiers vcs-h...@adamspiers.org wrote: I like that scheme with things like apache (sites-available vs. sites-enabled) although with mr config, the same effect can by automated via the special 'skip' parameter, which to me seems nicer than manually fiddling with symlinks. If you use skip, you will have to manually fiddle with mr to do the first checkout ;) Why? mr bootstrap http://... which then checks out the repo containing all the mr config files, and then chain-loads them. Each repo subsequently loaded can then optionally have a skip parameter which intelligently decides whether or not it should apply to this machine (personally I do this by giving each machine a unique nickname contained in ~/.nickname, and then building conditionals on that; sometimes I'll also base it on the DNS domain name for repos which are only relevant to a particular LAN). I still hope to sell Joey on the idea of incorporating link management in mr. A definite yes/no/onlyifyousubmitapatch would be nice, here. I'd be willing to help if it's only if you submit a patch. If that doesn't work out, I will most likely extend vcsh to do this. Along with zsh completion to grab available repos from your local setup. Yes, gotta have proper zsh completion ;-) ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 6:08 PM, Joey Hess j...@kitenet.net wrote:
Having two namespaces for the same thing does not strike me as
necessarily a good idea.
But if you wanted to do that with mr, you could
maybe take advantage of a little-known thing it does with determining the
absolute path:
joey@gnu:~mkdir namespace
joey@gnu:~cd namespace
joey@gnu:~/namespaceln -s ~/lib/sound
joey@gnu:~/namespaceln -s ~/src/git-annex
joey@gnu:~/namespacecd git-annex
joey@gnu:~/namespace/git-annexmr update
mr update: /home/joey/src/git-annex
I already did this; in fact I *had* to, in order to support GNU stow,
which requires the stow package namespace to be the list of
directories under a single stow directory. If you look for
$STOW_PKG_PATH in the code I originally posted, you'll see:
STOW_DIR=$HOME/.cfg
...
MR_NAME=`basename $MR_REPO`
...
STOW_PKG_PATH=$STOW_DIR/$MR_NAME
and then post_{checkout,update} call the install() function which
does:
ensure_symlink_exists $STOW_PKG_PATH ${MR_REPO%/}
However, the basename operation does not preserve the uniqueness
property which $MR_REPO had, and that's why I say that we need an
additional namespace. I can easily hack one, e.g.:
[$HOME/.my-repos/foo]
lib = MR_NAME=my-foo
[$HOME/.upstream-repos/foo]
lib = MR_NAME=your-foo
but that's ugly, and requires execution of shell code which would make
it difficult to implement a reverse lookup from package name to repo
path.
The only problem with this approach is that it only work when inside the
symlinked directory, so mr update in ~/namespace won't update the
directories symlinked to there.
Right. I feel like there's probably some elegant tweak we could make
to mr which would solve all this cleanly without much effort, but I'm
still trying to figure out what it is :-)
Let's examine the status quo. Currently mr has:
- a namespace for repositories (let's call it R) which is a subset
of the filesystem namespace, and values are specified in mr config
section headers,
- a namespace for mr config files (let's call it C) which is a
different subset of the filesystem namespace from R, and
- a 1:many mapping between C and R, i.e. each config file can
contain one or more repos.
I don't think there's anything wrong with this design - in fact that
1:many mapping is a nice configuration-time grouping mechanism, but
it's not quite enough to cater for some use cases.
For instance, sometimes it's just not acceptable to update all repos
at once, e.g. if you know that something is broken in repo X but you
really need the updates from repos Y and Z.
However mr cannot currently perform actions on repos at a finer
granularity than how they are grouped in config files. So if you
wanted to update your 'zsh' and 'emacs' repos, you could only do that
if they were in a config file containing no other repos. In general,
unless you restrict yourself to one config file per repo, there is no
way to get mr to operate on an arbitrary subset of R.
Similarly, if the 1:many mapping between C and R is used to logically
group repositories together (e.g. CLI, X11 and so on), there is no
way to get mr to operate on an arbitrary collection of groups.
Another issue is that whilst mr -c $config ls extracts mappings from
C to R, there's no way to extract the reverse mapping from R to C,
i.e. what config file do I need to use in order to perform actions
on repo X?
In summary, maybe the tweak I'm looking for is simply to decouple
configuration-time grouping of repos from run-time selection of which
repos to act on:
[$HOME/.my-repos/emacs]
name = emacs
[$HOME/.my-repos/zsh]
name = my-zsh
[$HOME/.upstream-repos/zsh]
name = upstream-zsh
which would allow:
$ mr -r my-zsh,emacs
And then the reverse mapping from R to C could be extracted via:
[DEFAULT]
showconfig = echo $MR_CONFIG
(except at the moment, MR_CONFIG isn't changed via includes
which could cause a problem.)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
Adam Spiers wrote:
I already did this; in fact I *had* to, in order to support GNU stow,
which requires the stow package namespace to be the list of
directories under a single stow directory. If you look for
$STOW_PKG_PATH in the code I originally posted, you'll see:
STOW_DIR=$HOME/.cfg
...
MR_NAME=`basename $MR_REPO`
...
STOW_PKG_PATH=$STOW_DIR/$MR_NAME
and then post_{checkout,update} call the install() function which
does:
ensure_symlink_exists $STOW_PKG_PATH ${MR_REPO%/}
However, the basename operation does not preserve the uniqueness
property which $MR_REPO had, and that's why I say that we need an
additional namespace.
So pick an operation that does? tr / _ would do, for example.
--
see shy jo
signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
Richard Hartmann wrote: Is there any technical reason that would make git annex init test --uuid=foo impossible? That way, I could re-use the UUID when I _know_ it's OK to reuse them. There is no technical reason that could not be done, but copying the .git/config has the same effect today. As an aside you are using v1 UUIDs, I hugely prefer v4. Is there any way to change which are being generated? It's up to the uuid program in PATH. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
On Sat, Oct 29, 2011 at 18:58, Joey Hess j...@kitenet.net wrote: There is no technical reason that could not be done, but copying the .git/config has the same effect today. OK, so git annex init, edit the UUID manually and then start to add data? That would still leave me with Yet One More repo in the repo list, defeating the initial purpose of re-using UUIDs. As a hardcore way of getting rid of old repos, would deleting all occurences of the repo from the logs and then _not_ union-merging, but merging normally work? It's up to the uuid program in PATH. K, I will change that then; thanks. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Corrupt git-annex repository
Richard Hartmann wrote: On Sat, Oct 29, 2011 at 18:58, Joey Hess j...@kitenet.net wrote: There is no technical reason that could not be done, but copying the .git/config has the same effect today. OK, so git annex init, edit the UUID manually and then start to add data? That would still leave me with Yet One More repo in the repo list, defeating the initial purpose of re-using UUIDs. copy .git/config before running git annex init. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
