New integration branch

[Joey Hess]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20111205/00afbd1b/attachment.pgp>