And attaching the script would probably be helpful...
On 7/13/07, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
I thoroughly agree with what you are proposing.
You may find the attached script (my own work) useful for cherry-picking
patches from one mercurial repo to another.
In particular, it preserves the log, timestamp and author which is useful
when trawling through changesets at a later date. It uses this information
to detects when changesets have already been applied and skips them.
Basic usage for importing patches from 'dev' into 'test' is:
# cd test
# hgpatch ../dev
Although I encourage the use of --blacklist <filename> so that you are not
re-prompted to apply skipped patches next time.
Oh, and it probably requires bash.
On 7/13/07, Alan Robertson <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have a few things to say here, and a change of mind, which I'll
> explain in more detail.
>
> First, I appreciate the work that Andrew and Dejan and Dave and others
> have gone to to get us what looks like a really solid release. Awesome
> work guys!
>
> Second, I want to apologize for not fully understanding what Mercurial
> can do for us in better managing our releases. My lack of gut-level
> understanding (which is now hopefully mostly past) led me to follow the
> procedures we'd used in the past - which worked out OK, but weren't
> optimal. In addition, I want to thank Andrew for prodding me into using
> Mercurial the way it was meant to be used. Now I get it.
>
> As a result, I now have some freedom in putting out the release which I
> didn't have pre-Mercurial, because there is no need for a code freeze at
>
> all. In spite of "getting it" there is still a bit of a learning curve
> to go through here, in terms of how to get more community involvement,
> and so on. No doubt I'm not not done with learning. I reserve the
> right to get smarter.
>
> Some people are concerned that we haven't put enough effort into testing
> this release, and are don't have as much confidence as I think they
> should in this process. Rather than arguing that I know what I'm doing
> (which I think I do), I'd rather just delay the release, and put in some
> more testing, and shore up that confidence through more testing, and
> more opportunity for others to do testing.
>
> To accommodate this, I've decided to delay the release for one week.
> The official release date for 2.1.1 is now 23 July, 2007.
>
> You can get the latest source for this release here:
> http://hg.linux-ha.org/test/archive/tip.tar.bz2
> or here http://hg.linux-ha.org/test/archive/tip.tar.gz
> You can see the patches and so on in this release here:
> http://hg.linux-ha.org/test/
>
> Here are the proposed rules of engagement for this one week period:
> - Each additional changeset will have a bugzilla for it, and will be
> linked to by the bugzilla, and the changeset on 'dev'
> will link to the bugzilla entry.
> - Every proposed bug fix will be announced on the -dev mailing list
> - Every proposed changeset will be inspected by myself and the
> community before being accepted.
> - Each accepted changeset will be announced on the -dev list
> right after it has been pushed to the 'test' repository
> - I have final authority on whether a given fix will go in
> during this time.
>
> Here are some of the criteria I will use to decide if a fix will go in:
> - Does it fix a regression?
> Fixes that fix regressions will be given priority
> - Does it fix something that would cause data damage?
> Fixes that fix data damage will be given high priority.
> - Is the patch "obviously harmless"? - like a documentation
> or release description change, or comments, or similar.
> - Will it require starting our long-running tests over?
> Things which will require this will likely have to wait for
> the next release, unless they are likely to destroy data.
> - Is it something that our long-running CTS tests don't test for?
> If so, then we won't have to start tests over.
> For example, if it's a *BSD-only fix, or a GUI fix, and
> if it's early enough to get reasonable manual testing, then
> I may take it.
>
> These are not exhaustive, but indicative of the criteria I will use.
>
> If we find too many regressions or probable data damage fixes (which is
> unlikely), then we would likely have to delay the release.
>
> --
> Alan Robertson <[EMAIL PROTECTED] >
>
> "Openness is the foundation and preservative of friendship... Let me
> claim from you at all times your undisguised opinions." - William
> Wilberforce
> _______________________________________________
> Linux-HA mailing list
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
function hg_patch_menu() {
source_repo=$1
changeset=$2
blacklist=$3
echo -n "Apply patch $changeset? (yes|no|log|diff|diffstat) [no] "
read do_patch
done=0
case "$do_patch" in
Y|y|Yes|yes|YES)
hg -R $source_repo export $changeset > $changeset.patch
hg import $changeset.patch
rc=$?
if [ $rc != 0 ]; then
echo "Hg import failed: $rc"
return $rc
fi
rm $changeset.patch
new_id=`hg id | awk '{print $1}'`
if [ "$new_id" != "$changeset" ]; then
echo Imported $changeset as $new_id
fi
done=1
;;
log)
hg -R $source_repo log -r $changeset
;;
diffstat)
hg -R $source_repo log -r $changeset -p | diffstat
;;
patch|diff)
hg -R $source_repo log -r $changeset -p
;;
n|N|NO|No|no|"")
if [ "x$blacklist" != "x" ]; then
echo "Blacklisting changeset $changeset in $blacklist"
echo "$changeset `date`" >> $blacklist
fi
done=1
;;
*) echo "Unknown response: '$do_patch'";;
esac
if [ $done = 0 ]; then
hg_patch_menu $source_repo $changeset $blacklist
fi
return 0
}
function hgpatch() {
done=0
verbose=0
while test "$done" = "0"; do
case "$1" in
-v) verbose=1; shift;;
--skip) skip_until=$2; shift; shift;;
--blacklist) cs_blacklist=$2; shift; shift;;
--list) cs_list=$2; shift; shift;;
"") done=1;;
*) source_repo="$1"; shift;;
esac
done
if [ "x$source_repo" = "x" ]; then
echo "Usage $0 [--skip until_patch] [--blacklist file] source_repo"
return
fi
echo "Reading blacklist from $cs_blacklist..."
if [ "x" = "x$cs_list" ]; then
echo "Retrieving list of patches..."
PATCHES=`hg in -M $source_repo | grep changeset: | tr ':' ' ' | awk
'{print $4}' | tr '\n' ' '`
else
PATCHES=$cs_list
fi
num_patches=`echo $PATCHES | wc -w`
echo Processing $num_patches patches
fuzz_limit=`expr $num_patches + 100`
hg_id=`hg id`
if [ "x$hg_id" = "x$skip_until" ]; then
skip_until=""
fi
for change in $PATCHES; do
rc=0
do_patch=1
shortlog=`hg log -R $source_repo -r $change -M --template
"{author|email}\t{desc|firstline|strip} On: {date|date}\n"`
if [ "x$skip_until" != "x" ]; then
do_patch=0
if [ "x$change" = "x$skip_until" ]; then
skip_until=""
echo "Found change root..."
else
echo "Skipping $change..."
fi
elif [ "x$cs_blacklist" != "x" ]; then
grep $change $cs_blacklist &> /dev/null
if [ $? = 0 ]; then
echo "- Patch $change is blacklisted: $shortlog"
do_patch=0
fi
fi
if [ $do_patch = 1 ]; then
# Search based on shortlog output
match=`hg log -l $fuzz_limit -M --template "CS: {node|short}. Patch
by {author|email}\t{desc|firstline|strip} On: {date|date})\n" | /usr/bin/grep
-F "$shortlog"`
if [ $? = 0 ]; then
echo "+ Patch $change previously applied as: $match"
do_patch=0
fi
fi
if [ $do_patch = 1 ]; then
echo ""
hg -R $source_repo log -r $change
hg_patch_menu $source_repo $change $cs_blacklist
rc=$?
echo ""
fi
if [ $rc != 0 ]; then
echo "Aborted"
break
fi
done
}
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
