From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Greg A. Woods" Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!) Date: Tue, 01 Dec 2009 12:59:58 -0500 Message-ID: References: <7vskbxewti.fsf@alter.siamese.dyndns.org> <20091130211744.GA27278@dpotapov.dyndns.org> <20091201054734.GB11235@dpotapov.dyndns.org> Reply-To: The Git Mailing List Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Dec__1_12:59:58_2009-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Dmitry Potapov To: The Git Mailing List X-From: git-owner@vger.kernel.org Tue Dec 01 19:00:15 2009 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1NFX1L-00015U-4j for gcvg-git-2@lo.gmane.org; Tue, 01 Dec 2009 19:00:15 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752709AbZLASAB (ORCPT ); Tue, 1 Dec 2009 13:00:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752704AbZLASAB (ORCPT ); Tue, 1 Dec 2009 13:00:01 -0500 Received: from mail.planix.com ([204.92.254.2]:62391 "EHLO most.weird.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751957AbZLASAA (ORCPT ); Tue, 1 Dec 2009 13:00:00 -0500 Received: from once.weird.com ([204.92.254.13] port=50751) by most.weird.com([204.92.254.2] port=25) via TCP with esmtp (4264 bytes) (sender: ) (ident using rfc1413) id for ; Tue, 1 Dec 2009 13:00:03 -0500 (EST) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2009-Feb-3) In-Reply-To: <20091201054734.GB11235@dpotapov.dyndns.org> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.7 Emacs/22.3 (i386--netbsdelf) MULE/5.0 (SAKAKI) X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Tue_Dec__1_12:59:58_2009-1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable At Tue, 1 Dec 2009 08:47:34 +0300, Dmitry Potapov wrot= e: Subject: Re: "git merge" merges too much! >=20 > On Mon, Nov 30, 2009 at 07:24:14PM -0500, Greg A. Woods wrote: > >=20 > > Things get even weirder if you happen to be playing with older branches > > too -- most build tools don't have ability to follow files that go back > > in time as they assume any product files newer than the sources are > > already up-to-date, no matter how much older the sources might become on > > a second build. >=20 > No, files do not go back in time when you switch between branches. The > timestamp on files is the time when they are written to your working > tree Hmmm, I didn't really say anything in particular about file timestamps -- I meant the file content may go back in time. More correctly I should have said that the file content may become inconsistent with the state of other files that have just been compiled. If the timestamps do not get set back to commit time, but rather are simply updated to move the last modify time to the time each change is made to a working file (which is as you said, to be expected), regardless of whether its content goes back in time or not, then this may or may not help a currently running build to figure out what really needs to be re-compiled. Likely it won't even for a recursive-make style update build, but certainly not for one where all build actions are pre-determined before any of them are started. If the content of one or more files goes back in time to an earlier state while the compile is happening then ultimately the result must be considered to be undefined. The best you can hope for is a break in the compile. This is why I agreed with you that a build should never be done in a working directory where any file editing or VCS action is occurring simultaneously. I just disagreed that "git archive" was a reasonable alternative to leaving the working directory alone during the entire time of the build. It is not really reasonable for large projects any more than stopping all work on the sources is reasonable. --=20 Greg A. Woods Planix, Inc. +1 416 218 0099 http://www.planix.com/ --pgp-sign-Multipart_Tue_Dec__1_12:59:58_2009-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQBLFVmeZn1xt3i/9H8RAvqJAKCk3i9w/W1k9YJGBzell10CKnzHRACgvxdW i8HcxwOKBp4adAAXYoJgB2U= =6hnL -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Dec__1_12:59:58_2009-1--