I'm attempting to implement a dummy target as illustrated in mrconfig.complex to run fixups after all updates have been completed:
[tmp]
# This is a dummy target, all it does is run fixups at the end of
# an update.
fixups = $HOME/bin/fixups
checkout = mkdir -p $HOME/tmp
status = :
order = 25
After adding the above section to my .mrconfig, I received the following error message when executing
mr up
:mr update: unknown repository type and no defined update command for /Users/tom/tmp
This was easily resolved by adding
update = :
to the [tmp] section. git repository containing proposed change.I now discovered that the [tmp] target was not being executed after all other targets (as the
order = 25
should have required). NOTE: none of my other targets have an order setting of greater than 15.I normally have
jobs = 5
set in my .mrconfig file--changing this tojobs = 1
resulted in the desired behavior.
Enhancement Request:
Please revise mr to respect the order setting, even if jobs is set to a number greater than 1.
order
is still honored with --jobs, in that the repos are processed in order. It's just that the concurrent processing doesn't guarantee a low order repository will be done being processed by the time a higher order repository starts being processed (or even finishes).It would of course be possible to stall the concurrent processing to guarantee that.
I think there are probably two ways
order
might be used:These are both valid; might be better to keep order as it is to handle #2, and add a more formal dependency mechanism for #1.
The use of a dummy target to run a
fixups
at the end of the update, which is what we're both usingorder
for suggests a simpler approach: Just make fixups commands be run after all repositories are updated, instead of the current behavior of running them when the repository that defines them is updated.After thinking about your comment suggesting the simplest way might be to run all fixups at the end, it occurred to me that for some it might be important to keep the fixups where they are. I can't think of a specific example offhand, but might there not be a time that cloning a repository, and executing its fixups, be a prerequisite before cloning another repository? Like I mentioned, I can't think of a specific example right now; however, I'm sure someone can think of something.
A quick fix for the way we're both using the dummy target might be to simply create a reserved 'order' value (e.g "order = 99" or "order = last") that is is broken out of the repo list and kept until last. I can barely make out what's happening when I try to read perl, but maybe the target containing the reserved 'order' value could be processed immediately after completion of the 'while' loop contained within the 'mrs' subroutine? (I hope that made sense)
Long-term, I see the value of keeping the original intent of 'order' (i.e. make a dependent repository be processed after another). Now that I know what's happening, I've revised my .mrconfig to eliminate the need for the 'final' fixups. If I ever need it again, I can always run with jobs=1.
This is honestly exactly how I thought it was meant to work when I started using
mr
. It's always been confusing to me that it doesn't work this way. So, insofar voting is relevant: +1Hi,
I too experienced this issue with
order
anjobs
, but in my case I wanted to process one specific repository (the vcsh one withorder=1
) before all the others.The specific case I wanted to cover is when the main vcsh repository has some updated hooks, so I want it to be updated before updating or cloning all the other repositories managed by vcsh.
The idea of having some value of
order
mean "first" or "last", and serialize the repositories which use them outside of the multi-processing dispatch is tempting.Ciao, Antonio