Adam Spiers wrote: > > 9c87f2352214175de307efedb8fd93889a26afbc > > Can you give an example of when this is needed? > > I can't remember but I definitely saw it happen at least once :-/
My worry is that, since that really shouldn't happen AFIACS, you were actually seeing a bug. Either that or it's a corner case I have not identified. > > 602f26714254f3c65389b7665d15d1d5d0e227a9 > > mr is quite typically (I know, not by you) run > > inside the repository. Which would leave the user > > in an apparently empty directory after mr update if > > an mr update deleted and remade the whole repository. > > > > I don't like that; I don't think things in mr should be > > deleting repositories in general; mr doesn't even delete > > a repo that has deleted = true, it only warns the user about it. > > Hmm, that's a fair point, although the only alternative is to change > the contents of the directory rather than the directory itself - > similarly to how `git checkout' does, for instance. I'll see if I can > get around to doing that. Perhaps some of the effort could be reused > for implementing download_diff (diff against the archive file). I think you could just use rsync :) > > cf3388f443b9d7afe6dc7d8a2159b45fb01ab4e4 > > This is a slow way to make machine-parsable info available -- > > the similar mr list takes 8 seconds here, since it has to run > > 169 shells. That's ok when you're just running mr, but I would > > not like to use a command that depended on that information. > > Sure, that's why I used a simple on-disk cache: > > > https://github.com/aspiers/kitenet-mr/commit/b60acb2e767b91ca6d406198d7eea1b3f73ad2bf > > It works fine. I could get more sophisticated and allow per-user > configuration of the cache invalidation strategy, e.g. so that it > would automatically rebuild the cache when ~/.mrconfig et al. are > changed, but manual rebuilds aren't a great hardship. In fact I could > even rebuild the cache every time mr runs! > > > If a machine-parseable list of repositories is needed, > > I think it'd be better to have a perl function that emits > > it in one go. > > I don't see how that's possible without ignoring the `skip', > `deleted', and `include' parameters. The include parameter is not a big problem, it's unlikely to require more than one shell process, which will be relatively fast. It's not clear to me what should be done about skip and deleted. skip in particular can behave in weird ways, when something like hours_since is used. To handle that all the skips would need to be tested, which would be less work than "mr list" but still verging on expensive. Depending on the application, it might be better to just dump all the defined repositories including skipped and deleted ones; if the consumer than runs mr in a skipped/deleted repo, mr will do something sane after all. -- see shy jo
signature.asc
Description: Digital signature
_______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home