New integration branch

[Adam Spiers]

On Mon, Dec 5, 2011 at 5:38 PM, Joey Hess <joey at kitenet.net> wrote:
> 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.

It's on my TODO list to try to reproduce; I'll let you know if I
manage to.

>> > 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 :)

Yeah, that sounds worth trying.

>> >        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.

Skipper functions like hours_since could (and probably should) decide
not to skip if MR_ACTION is set to a read-only action such "list" -
arguably "diff" and "status" too, although that's a matter of personal
taste.

But maybe we should step back a bit.  Currently we know that a full
"mr list" is not particularly fast, but has anyone actually profiled
it to find out where most of the time is being spent?  If we're only
guessing then we might have it completely wrong ...