Re: copy folders instead of sequential hg clones
Hi Jon, I am on VPN from Austin. It has always taken forever. And downloading programs from the internet when on VPN takes forever. I started looking into this a while back and I don't know if this is the issue but I found that the DNS servers are in Europe when I am on VPN. Right now as reported by ipconfig /all my Cisco AnyConnect DNS servers are: 144.20.190.70 in Madrid 192.135.82.132 in Amsterdam Pete On 4/11/14 7:07 PM, Jonathan Gibbons wrote: > To me, this message raises the questions of "why does it take > forever?" and, "how long should it take?" > > I see a wide range of expectations. Some folk can clone fast, and > assume that everyone else can as well. And then there's reports like > this, that it takes "forever". > > I'm all in favor of doing whatever it takes to speed up the workflow, > but where is the threshold between "yeah, it really does take this > long" and "if it takes this long, something must be broken"? > > -- Jon > > > On 04/11/2014 04:26 PM, Pete Brunet wrote: >> Since it takes forever to clone on my Win machine, in the case where I >> want to work on several bugs, is it OK to instead clone the first >> directory and then cp -ar that to n additional directories? -Pete >
Re: copy folders instead of sequential hg clones
To me, this message raises the questions of "why does it take forever?" and, "how long should it take?" I see a wide range of expectations. Some folk can clone fast, and assume that everyone else can as well. And then there's reports like this, that it takes "forever". I'm all in favor of doing whatever it takes to speed up the workflow, but where is the threshold between "yeah, it really does take this long" and "if it takes this long, something must be broken"? -- Jon On 04/11/2014 04:26 PM, Pete Brunet wrote: Since it takes forever to clone on my Win machine, in the case where I want to work on several bugs, is it OK to instead clone the first directory and then cp -ar that to n additional directories? -Pete
Re: copy folders instead of sequential hg clones
You might wish instead to do local clones of the first repo. hg clone http://hg.openjdk.java.net/jdk9/dev first cd first sh get_source.sh (with possibly some "magic" url) cd .. hg clone first second cd second sh get_source.sh ../first If you need to move repos between local machines or VMs you can also use, for jdk9 repos, sh common/bin/hgforest.sh serve and then use hg clone http://myhost.com:8000/repo repo cd repo sh get_source.sh http://myhost.com:8000/ where "myhost.com" and "repo" are replaced with the names shown in the status output from the serve command. There is nothing encoded in the repo which should cause problems due to copying but a local clone *should* be faster and use less disk space. HTH, Mike On Apr 11 2014, at 16:26 , Pete Brunet wrote: > Since it takes forever to clone on my Win machine, in the case where I > want to work on several bugs, is it OK to instead clone the first > directory and then cp -ar that to n additional directories? -Pete
Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider
On 4/11/2014 3:42 PM, Xueming Shen wrote:
webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
It's good to see the source of the zip provider moved to the jdk repo.
You have made some public classes to package-private which is good. I
wonder whether a few remaining public classes can be made
package-private (e.g. ZipFileAttributes, ZipInfo etc). Is
JarFileSystemProvider used anywhere? ZipFileSystemProvider is the only
provider listed in the service configuration.
Do you mean to make Demo.java as a regression test?
basic.sh - I wonder if you can get rid of this shell test. Do Basic,
PathOps, ZipFSTester have any relationship? I was thinking if they can
be made as individual java test and constructor the input path of
zipfs.jar.With zipfs.jar part of the jdk build, it will be found
under ${java.home}/lib/ext/zipfs.jar. When we move to modules, this
jar file won't exist. It might be better for the tests to create a JAR
file (one to share by all zipfs tests) to get ready for modules.
Mandy
copy folders instead of sequential hg clones
Since it takes forever to clone on my Win machine, in the case where I want to work on several bugs, is it OK to instead clone the first directory and then cp -ar that to n additional directories? -Pete
RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider
Hi, Please help review this changeset to upgrade the zip filesystem provider implementation from demo to a supported provider. Back in JDK7 we created a demo file system provider for zip/jar files. It is shipped in two forms, one as a binary under lib/ext that works "out of the box" to support zip/jar file access as a nio filesystem, the second is source form with a BSD license. We are now proposing to drop it as a demo and instead just "release" it as a filesystem provider that shipped with the JDK. issue: https://bugs.openjdk.java.net/browse/JDK-8038500 webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev Thanks! -Sherman
Re: RFR 8030011: Update Hotspot version string output
On 4/10/2014 8:11 PM, David Holmes wrote: On 11/04/2014 1:42 AM, Alejandro E Murillo wrote: Hi David, thanks for the feedback, see below On 4/9/2014 8:38 PM, David Holmes wrote: Hi Alejandro, Given we have to maintain the JDK version information in two places (top level repo and hotspot repo) wouldn't it have been simpler to keep hotspot_version file and HOTSPOT_RELEASE_VERSION and simply set the major/minor/build values to match those of the JDK version? The file is still used, just renamed as only jdk info is in there. HOTSPOT_RELEASE_VERSION was also kept, we just don't get the major,minor,micro and build number from it anymore, mainly it is now set very similar to the JDK_RELEASE_VERSION (plus other values), and that format it's not fixed as it used to be for hotspot express. Those values (major,minor,micro and build number) are already defined in the makefiles, so we just pass them to vm_version.cpp, so no more parsing in it. I still think the overall changes could have been much smaller but okay. The change actually is not that big, what happens is that due to the makefile structure the exact same change has to be replicated on each platform. Then, some of the changes themselves are actually comment changes, to remove references to the hsx hs version, and/or removal of lines of code that had been removed in some platform (Solaris) but not in others; also renaming some macros to better reflect what they are for. I also fixed some typos on macros names that were incorrect already, like these: http://cr.openjdk.java.net/~amurillo/9/8030011/make/windows/makefiles/defs.make.wdiff.html In a nutshell I just added the ability to get major,minor,micro and build number available to vm_version.cpp, in addition to hotspot_release_version, so that we don't have parse that to obtain those. And of course, adding additional testing of those values that is minimal right now. The other changes are related to now having to handle the micro_version, which was ignored with the old hotspot_version, but that has to be done regardless of how the values were obtained. The change is actually simple, compared to understanding how the makefiles work and how vm_version receives the values. Alejandro Thanks, David - That aside, in jdk_version file hotspot copyright should now be 2014 will fix that */vm.make: This line is way too long. ! VM_VER_DEFS = -DHOTSPOT_RELEASE_VERSION="\"$(HS_BUILD_VER)\"" -DJRE_RELEASE_VERSION="\"$(JRE_RELEASE_VER)\"" -DJDK_MAJOR_VERSION="\"$(JDK_MAJOR_VERSION)\"" -DJDK_MINOR_VERSION="\"$(JDK_MINOR_VERSION)\"" -DJDK_MICRO_VERSION="\"$(JDK_MICRO_VERSION)\"" -DJDK_BUILD_NUMBER="\"$(JDK_BUILD_NUMBER)\"" ok Not clear why we suddenly need defines for all the component pieces either. You could have kept the HS_XXX variables, just adding the micro part. as mentioned above, the micro part was actually added to HOTSPOT_RELEASE_VERSION, we just don't get those values by parsing it, so we just pass those values to the vm_version.cpp, since they are already defined in the makefiles. The format of the JDK version is not that fixed. Thanks Alejandro David On 10/04/2014 10:15 AM, Alejandro E Murillo wrote: Please review this change to make the hotspot related output produced by "java -version" match the corresponding JDK output: webrev: http://cr.openjdk.java.net/~amurillo/9/8030011/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030011 Note that we initially wanted to obtain more information from the repo being built and add it to the hotspot version output, but that will require changes in the JPRT, so we have decided to split the change in 2 bugs. One to make the version match (above webrev) and another one, an RFE, to add additional information extracted from the repo. Note that in the current version of vm_version.cpp, there is no error checking in product mode, I was suggested to make that explicit. Release Engineering did some testing and I also ran several cases with full and just hotspot JPRT builds. Here is a summary of how the new output compares to the old one: (1) Release Engineering builds (9-dev): from jdk9-dev build: java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-langtools-nightly-h257-20140328-b07-b00, mixed mode) compared with what we currently have java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-langtools-nightly-h247-20140326-b06-b00) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (2) Release Engineering builds (jdk9): java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) Server VM (build 1.9.0-ea-b07, mixed mode) compared with what we currently have java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b07) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b62, mixed mode) (3) JPRT Full builds: java version "1.9.0-int
Re: RFR [9] : get_source.sh should be more friendly to MQ
On Apr 11 2014, at 12:06 , Chris Hegarty wrote:
> On 11 Apr 2014, at 18:55, Mike Duigou wrote:
>
>> Have you looked at using rebase?
>
> I have not, in any detail.
>
>> I've been using
>>
>> sh common/bin/hgforest.sh pull
>> sh common/bin/hgforest.sh rebase
>> sh common/bin/hgforest.sh update
>>
>> rather than get_source.sh as it allows me to skip the qpop/qpush steps.
>
> Yes, this may work. I was just looking for a single command to active this.
> Maybe this combination could be baked into get_source.sh if patch
> repositories exist, and we can verify the existence of the rebase extension (
> rather than my previous proposal ) ?
I have contemplated adding this as an alternative to the pull -u step in
get_source.sh but wasn't others would agree. Some people hate rebase.
We can detect whether rebase is enabled via :
hg showconfig extensions | grep ^extension.rebase | wc -l
Play with this approach manually and see if it works for you. If it does then
we can consider enhancing get_source.sh
Mike
>
> -Chris.
>
>>
>> Mike
>>
>> On Apr 11 2014, at 07:58 , Chris Hegarty wrote:
>>
>>> Anyone using MQ for their daily development will know about this,
>>> forgetting to qpop before sync'ing up. It would be nice it get_source would
>>> pop and push patches ( only if you are using MQ ) automatically. If you do
>>> not have patch repos, then there is no change.
>>>
>>> diff --git a/get_source.sh b/get_source.sh
>>> --- a/get_source.sh
>>> +++ b/get_source.sh
>>> @@ -28,6 +28,21 @@
>>> # Get clones of all nested repositories
>>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>>
>>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>>> + ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>>> +
>>> +# Pop all patches, if any, before updating
>>> +if [ "${patchdirs}" != "" ] ; then
>>> + echo "Found queue repository, qpop."
>>> + sh ./common/bin/hgforest.sh qpop -a || exit 1
>>> +fi
>>> +
>>> # Update all existing repositories to the latest sources
>>> -sh ./common/bin/hgforest.sh pull -u
>>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>>
>>> +# Push all patches, if any, after updating
>>> +if [ "${patchdirs}" != "" ] ; then
>>> + echo "Found queue repository, qpush."
>>> + sh ./common/bin/hgforest.sh qpush -a
>>> +fi
>>> +
>>>
>>> -Chris.
>>
>
Re: RFR [9] : get_source.sh should be more friendly to MQ
On 11 Apr 2014, at 18:55, Mike Duigou wrote:
> Have you looked at using rebase?
I have not, in any detail.
> I've been using
>
> sh common/bin/hgforest.sh pull
> sh common/bin/hgforest.sh rebase
> sh common/bin/hgforest.sh update
>
> rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Yes, this may work. I was just looking for a single command to active this.
Maybe this combination could be baked into get_source.sh if patch repositories
exist, and we can verify the existence of the rebase extension ( rather than my
previous proposal ) ?
-Chris.
>
> Mike
>
> On Apr 11 2014, at 07:58 , Chris Hegarty wrote:
>
>> Anyone using MQ for their daily development will know about this, forgetting
>> to qpop before sync'ing up. It would be nice it get_source would pop and
>> push patches ( only if you are using MQ ) automatically. If you do not have
>> patch repos, then there is no change.
>>
>> diff --git a/get_source.sh b/get_source.sh
>> --- a/get_source.sh
>> +++ b/get_source.sh
>> @@ -28,6 +28,21 @@
>> # Get clones of all nested repositories
>> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>>
>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
>> + ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
>> +
>> +# Pop all patches, if any, before updating
>> +if [ "${patchdirs}" != "" ] ; then
>> + echo "Found queue repository, qpop."
>> + sh ./common/bin/hgforest.sh qpop -a || exit 1
>> +fi
>> +
>> # Update all existing repositories to the latest sources
>> -sh ./common/bin/hgforest.sh pull -u
>> +sh ./common/bin/hgforest.sh pull -u || exit 1
>>
>> +# Push all patches, if any, after updating
>> +if [ "${patchdirs}" != "" ] ; then
>> + echo "Found queue repository, qpush."
>> + sh ./common/bin/hgforest.sh qpush -a
>> +fi
>> +
>>
>> -Chris.
>
Re: RFR [9] : get_source.sh should be more friendly to MQ
Could we do the same with the trees extension?
-- Jon
On 04/11/2014 10:55 AM, Mike Duigou wrote:
Have you looked at using rebase? I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Mike
On Apr 11 2014, at 07:58 , Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this, forgetting to
qpop before sync'ing up. It would be nice it get_source would pop and push
patches ( only if you are using MQ ) automatically. If you do not have patch
repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: RFR [9] : get_source.sh should be more friendly to MQ
Have you looked at using rebase? I've been using
sh common/bin/hgforest.sh pull
sh common/bin/hgforest.sh rebase
sh common/bin/hgforest.sh update
rather than get_source.sh as it allows me to skip the qpop/qpush steps.
Mike
On Apr 11 2014, at 07:58 , Chris Hegarty wrote:
> Anyone using MQ for their daily development will know about this, forgetting
> to qpop before sync'ing up. It would be nice it get_source would pop and push
> patches ( only if you are using MQ ) automatically. If you do not have patch
> repos, then there is no change.
>
> diff --git a/get_source.sh b/get_source.sh
> --- a/get_source.sh
> +++ b/get_source.sh
> @@ -28,6 +28,21 @@
> # Get clones of all nested repositories
> sh ./common/bin/hgforest.sh clone "$@" || exit 1
>
> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
> + ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
> +
> +# Pop all patches, if any, before updating
> +if [ "${patchdirs}" != "" ] ; then
> + echo "Found queue repository, qpop."
> + sh ./common/bin/hgforest.sh qpop -a || exit 1
> +fi
> +
> # Update all existing repositories to the latest sources
> -sh ./common/bin/hgforest.sh pull -u
> +sh ./common/bin/hgforest.sh pull -u || exit 1
>
> +# Push all patches, if any, after updating
> +if [ "${patchdirs}" != "" ] ; then
> + echo "Found queue repository, qpush."
> + sh ./common/bin/hgforest.sh qpush -a
> +fi
> +
>
> -Chris.
Re: Java compilation and -g
What is the size difference? On 4/11/14, 10:53 AM, Chris Hegarty wrote: On 11/04/14 15:40, Erik Joelsson wrote: Hello, While converting the build to the new build-infra makefiles, one thing that annoyed me was the fact that we aren't consistently compiling with or without -g for java code. In the new makefiles we just emulate the same behavior, but I would like to sort it out properly now. Currently langtools, jaxp and jaxws repos build with -g always, while corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or slowdebug. How would we really like this to work? Is there a reason not to ship with -g enabled? I know from personal experience that I get very annoyed when I can't step into the jdk classes and look at local variable values when debugging my own java applications. +1. I can understand that this may be different for actual product builds. -Chris. /Erik
Re: RFR [9] : get_source.sh should be more friendly to MQ
On 11 apr 2014, at 17:19, Jonathan Gibbons wrote:
> Is it common to use mq in all repos of a forest?
For me it is very common to be working on a fix that spans multiple repos (up
to 5 different repos at times). So, yes.
I like this fix, but I would be very annoyed if all my patches were applied
(not just those that were applied before get_source.sh ran). I frequently have
lots of patches in the queue that I don’t want to have applied.
Thanks,
/Staffan
>
> I've never used mq that way; it would only have occurred to me to use mq in
> the repo I'm interested in -- in my case, langtools. But then, I admit I tend
> not to clone forests more than necessary. configure.sh
> --with-override-repo-name is your friend ;-)
>
> -- Jon
>
>
> On 04/11/2014 08:19 AM, Chris Hegarty wrote:
>> On 11/04/14 15:59, Michael McMahon wrote:
>>> That's very useful Chris. I wonder is it okay to assume that all patches
>>> must be pushed back again after the update?
>>>
>>> Would it be feasible to remember which (if any) patches had been popped
>>> first, and only push the same ones again?
>>
>> That would require a much more involved set of changes in hgforest, but
>> could be doable. All you need to know is queue tip, 'hg qtop', of each repo,
>> qpush back to it.
>>
>> -Chris.
>>
>>>
>>> Michael
>>>
>>> On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
>>>
>
Re: RFR [9] : get_source.sh should be more friendly to MQ
On 11/04/14 16:19, Chris Hegarty wrote:
On 11/04/14 15:59, Michael McMahon wrote:
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
That would require a much more involved set of changes in hgforest,
but could be doable. All you need to know is queue tip, 'hg qtop', of
each repo, qpush back to it.
or something like:
list=`hg qapplied`
hg qpop -a
before doing the update and then afterwards
hg qpush `echo $list`
-Chris.
Michael
On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches
2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: RFR [9] : get_source.sh should be more friendly to MQ
Is it common to use mq in all repos of a forest?
I've never used mq that way; it would only have occurred to me to use mq
in the repo I'm interested in -- in my case, langtools. But then, I
admit I tend not to clone forests more than necessary. configure.sh
--with-override-repo-name is your friend ;-)
-- Jon
On 04/11/2014 08:19 AM, Chris Hegarty wrote:
On 11/04/14 15:59, Michael McMahon wrote:
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
That would require a much more involved set of changes in hgforest,
but could be doable. All you need to know is queue tip, 'hg qtop', of
each repo, qpush back to it.
-Chris.
Michael
On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches
2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: RFR [9] : get_source.sh should be more friendly to MQ
On 11/04/14 15:59, Michael McMahon wrote:
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
That would require a much more involved set of changes in hgforest, but
could be doable. All you need to know is queue tip, 'hg qtop', of each
repo, qpush back to it.
-Chris.
Michael
On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: RFR [9] : get_source.sh should be more friendly to MQ
On 11/04/14 15:59, Jonathan Gibbons wrote:
Popping all patches beforehand is reasonable, but afterwards, it would
be better to reset to the patches that were previously applied than to
try and push all of them.
Michael as requested same.
What is the behavior if you cannot qpush patches after the pull, because
of merge issues?
The parts of the specific patch that applied cleanly remain applied,
them that did not are written out to reject files to be analyzed. The
remainder of the patches in that repository are not applied. get_source
will then exit with an appropriate error exit code and you can take action.
-Chris.
-- Jon
On 04/11/2014 07:58 AM, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: RFR [9] : get_source.sh should be more friendly to MQ
Popping all patches beforehand is reasonable, but afterwards, it would
be better to reset to the patches that were previously applied than to
try and push all of them.
What is the behavior if you cannot qpush patches after the pull, because
of merge issues?
-- Jon
On 04/11/2014 07:58 AM, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: RFR [9] : get_source.sh should be more friendly to MQ
That's very useful Chris. I wonder is it okay to assume that all patches
must be pushed back again after the update?
Would it be feasible to remember which (if any) patches had been popped
first, and only push the same ones again?
Michael
On 11/04/14 15:58, Chris Hegarty wrote:
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
RFR [9] : get_source.sh should be more friendly to MQ
Anyone using MQ for their daily development will know about this,
forgetting to qpop before sync'ing up. It would be nice it get_source
would pop and push patches ( only if you are using MQ ) automatically.
If you do not have patch repos, then there is no change.
diff --git a/get_source.sh b/get_source.sh
--- a/get_source.sh
+++ b/get_source.sh
@@ -28,6 +28,21 @@
# Get clones of all nested repositories
sh ./common/bin/hgforest.sh clone "$@" || exit 1
+patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \
+ ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null`
+
+# Pop all patches, if any, before updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpop."
+ sh ./common/bin/hgforest.sh qpop -a || exit 1
+fi
+
# Update all existing repositories to the latest sources
-sh ./common/bin/hgforest.sh pull -u
+sh ./common/bin/hgforest.sh pull -u || exit 1
+# Push all patches, if any, after updating
+if [ "${patchdirs}" != "" ] ; then
+ echo "Found queue repository, qpush."
+ sh ./common/bin/hgforest.sh qpush -a
+fi
+
-Chris.
Re: Java compilation and -g
On 11/04/14 15:40, Erik Joelsson wrote: Hello, While converting the build to the new build-infra makefiles, one thing that annoyed me was the fact that we aren't consistently compiling with or without -g for java code. In the new makefiles we just emulate the same behavior, but I would like to sort it out properly now. Currently langtools, jaxp and jaxws repos build with -g always, while corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or slowdebug. How would we really like this to work? Is there a reason not to ship with -g enabled? I know from personal experience that I get very annoyed when I can't step into the jdk classes and look at local variable values when debugging my own java applications. +1. I can understand that this may be different for actual product builds. -Chris. /Erik
Java compilation and -g
Hello, While converting the build to the new build-infra makefiles, one thing that annoyed me was the fact that we aren't consistently compiling with or without -g for java code. In the new makefiles we just emulate the same behavior, but I would like to sort it out properly now. Currently langtools, jaxp and jaxws repos build with -g always, while corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or slowdebug. How would we really like this to work? Is there a reason not to ship with -g enabled? I know from personal experience that I get very annoyed when I can't step into the jdk classes and look at local variable values when debugging my own java applications. /Erik
