From sussman@collab.net Mon Apr 7 15:33:09 2003 Received: from collab.net (newton.ch.collab.net [216.127.237.130]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h37KX9bt027528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Apr 2003 15:33:09 -0500 Received: from kepler.ch.collab.net (localhost [127.0.0.1]) by collab.net (8.12.6/8.11.1) with ESMTP id h37KWnSd004002 for ; Mon, 7 Apr 2003 15:32:50 -0500 (CDT) (envelope-from sussman@collab.net) Received: (from sussman@localhost) by kepler.ch.collab.net (8.12.6/8.12.6/Submit) id h37KWn4e003997; Mon, 7 Apr 2003 15:32:49 -0500 (CDT) X-Authentication-Warning: kepler.ch.collab.net: sussman set sender to sussman@collab.net using -f To: changesets@sanpietro.red-bean.com Subject: test Reply-To: sussman@red-bean.com From: Ben Collins-Sussman Date: 07 Apr 2003 15:32:45 -0500 Message-ID: <864r5am4k2.fsf@kepler.ch.collab.net> Lines: 2 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Is this thing on? From sussman@collab.net Mon Apr 7 16:04:08 2003 Received: from collab.net (newton.ch.collab.net [216.127.237.130]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h37L47bt028616 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Apr 2003 16:04:08 -0500 Received: from kepler.ch.collab.net (localhost [127.0.0.1]) by collab.net (8.12.6/8.11.1) with ESMTP id h37L3mSd004121 for ; Mon, 7 Apr 2003 16:03:48 -0500 (CDT) (envelope-from sussman@collab.net) Received: (from sussman@localhost) by kepler.ch.collab.net (8.12.6/8.12.6/Submit) id h37L3iqX004118; Mon, 7 Apr 2003 16:03:44 -0500 (CDT) X-Authentication-Warning: kepler.ch.collab.net: sussman set sender to sussman@collab.net using -f To: changesets@red-bean.com Subject: testing Reply-To: sussman@red-bean.com From: Ben Collins-Sussman Date: 07 Apr 2003 16:03:32 -0500 Message-ID: <86n0j2kokb.fsf@kepler.ch.collab.net> Lines: 2 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Another test of new changesets list. From kfogel@newton.ch.collab.net Mon Apr 7 16:13:46 2003 Received: from newton.ch.collab.net (newton.ch.collab.net [216.127.237.130]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h37LDkbt028888 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Apr 2003 16:13:46 -0500 Received: (from kfogel@localhost) by newton.ch.collab.net (8.11.6/8.11.6) id h37KW4v27974; Mon, 7 Apr 2003 15:32:04 -0500 (CDT) (envelope-from kfogel@newton.ch.collab.net) To: changesets@red-bean.com Subject: Goals References: <86n0j2kokb.fsf@kepler.ch.collab.net> Reply-to: kfogel@collab.net X-Windows: dissatisfaction guaranteed. From: Karl Fogel Date: 07 Apr 2003 15:32:00 -0500 In-Reply-To: <86n0j2kokb.fsf@kepler.ch.collab.net> Message-ID: <85istqdp6n.fsf@newton.ch.collab.net> Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I probably won't be able to participate in this list as much as I'd like :-(... But that won't stop me from proposing some initial goals for the discussion :-) ! Goal: design a patch format that a) is compatible with the standard `patch' program in the sense that `patch' will not choke on it, and will apply as much of it as it can. b) expresses tree changes (directories and files added, copied, renamed, and removed) c) supports generic metadata. What I have in mind are Subversion's "properties", but there may be other sorts of metadata used by Arch or other systems; none of it should be lost. I think (a) is pretty easy to achieve. Just put the extra data after the last hunk of a file, and before the "Index: " line of the next file. Or it may be that patch has provision for custom headers of some sort? That's all. If these goals seem wildly off-base, this would be a good time to say so :-). -Karl From lord@emf.net Mon Apr 7 16:43:56 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h37Lhsbs029826 for ; Mon, 7 Apr 2003 16:43:54 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id OAA24098; Mon, 7 Apr 2003 14:53:21 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 14:53:21 -0700 (PDT) Message-Id: <200304072153.OAA24098@morrowfield.regexps.com> From: Tom Lord To: kfogel@collab.net CC: changesets@red-bean.com In-reply-to: <85istqdp6n.fsf@newton.ch.collab.net> (message from Karl Fogel on 07 Apr 2003 15:32:00 -0500) Subject: Re: Goals References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> --text follows this line-- Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Goal: design a patch format that a) is compatible with the standard `patch' program in the sense that `patch' will not choke on it, and will apply as much of it as it can. I would make that a "desirable" goal, not a "constraining" goal. b) expresses tree changes (directories and files added, copied, renamed, and removed) And there's a need to deal with "inexact" patching regarding those (i.e. the tree to which a path is applied has different structure from the ORIG tree used to generate the patch). c) supports generic metadata. What I have in mind are Subversion's "properties", but there may be other sorts of metadata used by Arch or other systems; none of it should be lost. A design principle of arch is that "meta-data" is part of the source tree. Thus, the patch mechanism in arch is unaware of a distinction between data and meta-data. When arch needs to add meta-data, it takes the changeset format as a design constraint. That's all. If these goals seem wildly off-base, this would be a good time to say so :-). Not wildly. Just slightly. And slightly misfocused. Let's talk tree reararrangements. They imply the ability to recognize a logical identity of a file that is not tied to its physical location in the tree. I think the "logical identity" problem is a separable subproblem of the general changeset challenge. So: how do we assign logical identities to files? Towards a _straw man_ proposal, I'll point to some tutorial docs about arch's approach: http://regexps.srparish.net/tutorial/inventories.html http://regexps.srparish.net/tutorial/inventory-tags.html When we want to talk about how that relates to changesets, this may be relevant: http://www.fifthvision.net/open/bin/view/Arch/PatchSetFormalSemantics -t From eli@pflash.com Mon Apr 7 18:25:51 2003 Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h37NPobs000336 for ; Mon, 7 Apr 2003 18:25:50 -0500 Received: from dialup-67.31.233.253.dial1.dallas1.level3.net ([67.31.233.253] helo=citadel) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 192fzo-0007Dc-00; Mon, 07 Apr 2003 16:25:48 -0700 Content-Type: text/plain; charset="us-ascii" From: Eli To: changesets@sp.red-bean.com Subject: Re: Goals Date: Mon, 7 Apr 2003 18:32:04 -0500 User-Agent: KMail/1.4.3 Cc: kfogel@collab.net MIME-Version: 1.0 Message-Id: <200304071832.04724.eli@pflash.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sanpietro.red-bean.com id h37NPobs000336 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! copy'n'paste from the archives: (Karl Fogel) Goal: design a patch format that a) is compatible with the standard `patch' program in the sense that `patch' will not choke on it, and will apply as much of it as it can. b) expresses tree changes (directories and files added, copied, renamed, and removed) c) supports generic metadata. What I have in mind are Subversion's "properties", but there may be other sorts of metadata used by Arch or other systems; none of it should be lost. ------------- Ok, here is something that addresses a and b, and some of c. You may dismiss it out-of-hand, but I've been finding it useful for my own work, so I thought I'd bring it up for the sake of discussion. I like it because I can use it with a minimal amount of software. Basic format: ----- # date, user@host, etc. # # User's commit comments... # # Output from 'diffstat -c' (or similar) # touch 'anewfile' chmod g+x,u+x 'anewfile' rm 'testing/myoldfile' mv 'testing/hello.c' 'testing/goodbye.c' rmdir 'someolddir' mkdir 'anewdir' mv 'anotherdir/' 'yetanotherdir/' cat "$0" | patch -p1 exit 0 --- reference/anewfile etc... +++ sandbox/anewfile etc... + Late one night, early this morning, ... ----- The basic idea is that you can apply this in a number of ways: 1) Use a program that interprets the touch/chmod/rm/etc commands in a _secure_ way, dealing with shell escapes, etc., etc, and either calls patch or does that itself. 2) Apply the touch/chmod/etc commands by hand, then feed the whole file through patch. 3) Look over the touch/chmod/mv/rm/etc. commands for "nastinesses", then '/bin/sh patchname' It is human-readable, and fairly simple (*cough* simplistic *cough*). :) However, the software in #1 can deal with conflicts in an intelligent manner by seeing that execute permissions are already set, or testing/goodbye.c already exists, deal with mv's with an existing destination directory, and on and on. I'm a fan of using bzip2 or gzip when space consumption is a concern. A decent program would know how to deal with .bz2 and .gz files in some fashion. It is also *nix-centric, needs software from #1 to revert, or gracefully deal with conflicts. Binary files are also a "bit" of a problem, short of an extension to 'patch' that defines a text->binary conversion or something. (For what I do, hexdump or xxd conversion at build time is acceptable, but I recognize that _isn't_ sufficient for all cases.) And probably a miriad of other problems. ;) Hold on! *dons abspestos underwear* *dives for cover behind nice, big rock* Ok, flame away! ;) Have fun! Eli From pasky@machine.sinus.cz Mon Apr 7 18:44:43 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h37Nifbs000866 for ; Mon, 7 Apr 2003 18:44:42 -0500 Received: (qmail 5694 invoked by uid 2001); 7 Apr 2003 23:44:40 -0000 Date: Tue, 8 Apr 2003 01:44:40 +0200 From: Petr Baudis To: Tom Lord Cc: kfogel@collab.net, changesets@red-bean.com Subject: Re: Goals Message-ID: <20030407234439.GA3037@pasky.ji.cz> References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304072153.OAA24098@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Let's try to drop around some random ideas and see what does it do ;-). (I will use spatch (smart patch) as the shortcut alias for "new patch format" below.) Dear diary, on Mon, Apr 07, 2003 at 11:53:21PM CEST, I got a letter, where Tom Lord told me, that... > > Goal: design a patch format that > > a) is compatible with the standard `patch' program in the sense > that `patch' will not choke on it, and will apply as much of it > as it can. > > I would make that a "desirable" goal, not a "constraining" goal. Then we will just end up with people sending around both old and new patches, wasting time and resources. Is that desirable? (I'm not implying that it is not, though, since the spatch non-users would have to manually fix ie. renames.) > b) expresses tree changes (directories and files > added, copied, renamed, and removed) > > And there's a need to deal with "inexact" patching regarding those > (i.e. the tree to which a path is applied has different structure from > the ORIG tree used to generate the patch). > > c) supports generic metadata. What I have in mind are Subversion's > "properties", but there may be other sorts of metadata used by > Arch or other systems; none of it should be lost. > > A design principle of arch is that "meta-data" is part of the source > tree. Thus, the patch mechanism in arch is unaware of a distinction > between data and meta-data. When arch needs to add meta-data, it > takes the changeset format as a design constraint. Well, one of the implementation approaches could indeed be that we establish a special file name under which would be bundled all the meta-changes in some arbitrary format. Like: --- # METADATA Tue Apr 8 00:41:28 2003 +++ # METADATA Tue Apr 8 00:41:29 2003 @@ -1,3 +1,3 @@ -xyz:foo:mani:bar name=mani.c mode=755 rcs:rev=1.3 +xyz:foo:mani:bar name=main.c mode=644 rcs:rev=1.4 -xyz:baz:NEWS:bar name=NEWS +xyz:baz:NEWS:bar name= -xyz:mee:TODO:bar name= +xyz:mee:TODO:bar name=TODO (xyz:...:...:bar being a unique file id, as described below.) (The first change is rename and mode change [bundled together]. It also denotes information about revision number change, specific for RCS.) (The second change is removal of the NEWS file. Renaming to an empty name should be safely unambiguous and it gives us cute simplicity and genericity.) (The third change is introduction of the TODO file. It is needed to keep the file ids synchronized across repositories. See below for discussion.) Let's define the format informally: * It has to be a diff which: - does not need to preserve a context - must contain both the original and new form Thus ie. a classic diff or unified diff is fine, but context diff or an ed script isn't. (On the other side, do we need to make this restriction? It will reduce some possibilities of conflict detection, but so it does for normal files. Anyway, the important point is that it is diff-like.) * The diff is done upon special reserved filename "# METADATA". Or propose something else exotic enough. * The diff SHOULD NOT contain any context. Unchanged lines may be useful (ie. some unique repository id...) but none are defined, thus they MUST follow the rules for SCM-specific extensions outlined below. * Each line consists of several fields separated by tabs. A backslash is treated as an escape character and any its natural occurence must be escaped to '\\'. Natural in-field occurences of tabs must be escaped to '\t', natural in-field occurences of newlines must be escaped to '\n'. * The first field is a unique file id, as described below. If the change is concerning the whole repository, this field is to be left empty. Only per-file changes are defined for the global namespace. * The other fields are [:]= pairs. Except the escaping rules, there are no constraints regarding the value contents. The key string may not contain a '=' and the namespace string may not contain '=' or ':'. * There is a global namespace (where the namespace part is missing from the pair), with a well-defined set of keys with universal meaning across all the possible users. Any user (SCM) can also introduce own namespace (which SHOULD be named carefully not to clash with any other) where it may carry own specific informations. No specific namespace nor any non-global namespace keys are defined. * Both lines of a line pair representing one change must share the exactly same file id and set of keys. * In addition to a file id, each line MUST include a "name" field to help to fuzzily identify a subject of change even when the file ids are not synchronized (ie. the file was not introduced by a spatch and thus it got assigned a different file id). One of the disadvantages would be that patch would always generate conflicts when trying to apply such a diff (how to call the "changes description" ? "a patch" or "a diff" ?), but maybe that's in fact a good thing, the user is aware that some of the changes wasn't applied. > That's all. If these goals seem wildly off-base, this would be a good > time to say so :-). > > Not wildly. Just slightly. > > And slightly misfocused. > > Let's talk tree reararrangements. They imply the ability to recognize > a logical identity of a file that is not tied to its physical location > in the tree. I think the "logical identity" problem is a separable > subproblem of the general changeset challenge. > > So: how do we assign logical identities to files? > > Towards a _straw man_ proposal, I'll point to some tutorial docs about > arch's approach: > > http://regexps.srparish.net/tutorial/inventories.html Would we use the name conventions and file categories for anything? Sure, maybe you want to skip backup files etc, but that is IMHO entirely end-application spatch implementation matter. > http://regexps.srparish.net/tutorial/inventory-tags.html (A terminology note: tag is kind of confusing, IMHO, as probably most of us are used more to the CVS/SVN/others;] terminology, where this means primarily a named moment in the repository history. Thus, I will stick with a "file id" term here.) We need to use file ids instead of just file names not only to solve properly some conflicts, but also to handle a "revival" of a file --- file which was deleted before but in this patch, it materializes in the repository again. In order to have the file ids usable, such a file id must be unique in the global scope, not only in the frame of one repository. However not all of the spatch implementations could have the necessary means to fill in all the possibly required data. Thus, the file id particular format must not be relied upon, it is a matter of the side first introducing the file to the system to declare its unique id, which must not be altered in any way anymore. The other sides must use that unique id when identifying any later changes, that is adopting that unique id or keeping a translation table between the "interoperable" unique ids and their internal unique ids. The RECOMMENDED format of a file id is to include a globally unique identifiation of the change originator (ie. an email), time of the change as accurate as possible (in a suitable format, ie. the number of seconds from 1970-01-01 01:00) and at least one other additional distinguishing information (ie. the original file name). The recommended separator is a colon (':'). What do you think? ;-) -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From lord@emf.net Mon Apr 7 19:16:13 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h380GCbs001622 for ; Mon, 7 Apr 2003 19:16:12 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id RAA24580; Mon, 7 Apr 2003 17:25:43 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 17:25:43 -0700 (PDT) Message-Id: <200304080025.RAA24580@morrowfield.regexps.com> From: Tom Lord To: pasky@ucw.cz CC: kfogel@collab.net, changesets@red-bean.com In-reply-to: <20030407234439.GA3037@pasky.ji.cz> (message from Petr Baudis on Tue, 8 Apr 2003 01:44:40 +0200) Subject: Re: Goals References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> <20030407234439.GA3037@pasky.ji.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Let's try to drop around some random ideas How about: let's not. -t From ghudson@MIT.EDU Mon Apr 7 19:33:36 2003 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h380XZbt002204 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Mon, 7 Apr 2003 19:33:36 -0500 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h380XXFt018298; Mon, 7 Apr 2003 20:33:33 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h380XWtG023181; Mon, 7 Apr 2003 20:33:32 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h380XVFJ012642; Mon, 7 Apr 2003 20:33:31 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3p2) id UAA02841; Mon, 7 Apr 2003 20:33:30 -0400 Subject: Re: Goals From: Greg Hudson To: Tom Lord Cc: changesets@red-bean.com In-Reply-To: <200304080025.RAA24580@morrowfield.regexps.com> References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> <20030407234439.GA3037@pasky.ji.cz> <200304080025.RAA24580@morrowfield.regexps.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049762009.2729.1.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 07 Apr 2003 20:33:30 -0400 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Mon, 2003-04-07 at 20:25, Tom Lord wrote: > Let's try to drop around some random ideas > > How about: let's not. If you don't like someone's ideas, you can criticize them or (less optimally) you can ignore them. This sort of random dismissal is only going to make it less likely that people will try to collaborate with you. From lord@emf.net Mon Apr 7 19:35:56 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h380Zsbs002281 for ; Mon, 7 Apr 2003 19:35:55 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id RAA24636; Mon, 7 Apr 2003 17:45:35 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 17:45:35 -0700 (PDT) Message-Id: <200304080045.RAA24636@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com Subject: Towards Basic Definitions (notation, mostly) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: So, what's a changeset? This is not intended to be a formal definition -- just towards one, mostly with the idea of introducing some terminology. Let's assume that we know what a "source tree" is. If we have two source trees, ORIG and MOD, then let's say that a changeset is the value of the function `delta': delta(ORIG, MOD) == "changeset from ORIG to MOD" Informally, a changeset describes how ORIG and MOD differ in terms of "edits", where "edits" includes internal-to-file changes, file meta-data changes, and tree-structure changes. I propose that a changeset can be abstractly regarded as a function, mapping source trees to source trees. You "apply" a changset, for which I like the notation: changeset[TREE] == "the resulting tree" Even with these informal definitions, and not quite stating the definition of equality between source trees, we have an important invariant (call it the "fundamental equation"): delta(ORIG, MOD)[ORIG] == MOD which means that if you apply the changeset between ORIG and MOD to a tree equal to ORIG, you get a tree equal to MOD. The "inexact patching problem" concerns what happens when you apply a changeset to a tree that is not equal to ORIG: delta(ORIG, MOD)[NOT_ORIG] == ??? To define changesets for real, we have to fill out these definitions. What's a source tree? What happens when a changeset is applied to NOT_ORIG? And we have to consider the uses of changesets. A trivial definition that satisfies the fundamental equation would say: for all source trees X, delta(ORIG,MOD)[X] == MOD but that's clearly not what we intend in the larger context. -t From lord@emf.net Mon Apr 7 20:19:06 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h381J4bs003691 for ; Mon, 7 Apr 2003 20:19:05 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id SAA24778; Mon, 7 Apr 2003 18:28:40 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 18:28:40 -0700 (PDT) Message-Id: <200304080128.SAA24778@morrowfield.regexps.com> From: Tom Lord To: ghudson@MIT.EDU CC: changesets@red-bean.com In-reply-to: <1049762009.2729.1.camel@error-messages.mit.edu> (message from Greg Hudson on 07 Apr 2003 20:33:30 -0400) Subject: Re: Goals References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> <20030407234439.GA3037@pasky.ji.cz> <200304080025.RAA24580@morrowfield.regexps.com> <1049762009.2729.1.camel@error-messages.mit.edu> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > Let's try to drop around some random ideas > > How about: let's not. If you don't like someone's ideas, you can criticize them or (less optimally) you can ignore them. This sort of random dismissal is only going to make it less likely that people will try to collaborate with you. Let me clarify my curmodgeonly remark then. Petr: as advertised, your post is a string of random ideas. Some of them sound promising, others less so. But by "dropping around random ideas", you're asking others to spend a lot of time trying to figure out exactly what you might mean, to separate the wheat from the chaff, and to respond to that. And if that's not what you're asking for -- then what? a long spiral of contentless back-and-forth threads characterized mostly by misunderstanding? That kind of thing is a common failure mode of technical discussions on mailing lists, so please try to avoid it. -t From willu.mailingLists@cse.unsw.edu.au Mon Apr 7 20:29:16 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h381TFbs004074 for ; Mon, 7 Apr 2003 20:29:15 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Tue, 8 Apr 2003 11:29:14 +1000 From: William Uther To: changesets@red-bean.com Date: Tue, 8 Apr 2003 11:29:00 +1000 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: Goals Content-Transfer-Encoding: 7bit Message-Id: <79CF3216-6961-11D7-AE74-000393CDF554@cse.unsw.edu.au> X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi all, I really don't have time to contribute much here, but I do find the topic interesting, and so I'll probably poke my head in every now and then... > Goal: design a patch format that > > a) is compatible with the standard `patch' program in the sense > that `patch' will not choke on it, and will apply as much of it > as it can. > > b) expresses tree changes (directories and files > added, copied, renamed, and removed) > > c) supports generic metadata. What I have in mind are Subversion's > "properties", but there may be other sorts of metadata used by > Arch or other systems; none of it should be lost. This all looks good. The one thing I would suggest is that the changeset format should be able to handle binary files. Mayhap it only uses the original patch format only if the patch would be entirely printable ascii chars, and the maximum line length 120 chars? Another email is following... Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From willu.mailingLists@cse.unsw.edu.au Mon Apr 7 21:58:57 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h382wubs006817 for ; Mon, 7 Apr 2003 21:58:56 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Tue, 8 Apr 2003 12:58:54 +1000 From: William Uther To: changesets@red-bean.com Date: Tue, 8 Apr 2003 12:58:41 +1000 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Subject: Variance Adjusted Changesets Content-Transfer-Encoding: 7bit Message-Id: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi all, I like parts of Tom's formalism. I have some issues with parts of it too. There are three parts to this mail. i) My preferred take on file tagging ii) Problems with file tagging as currently being discussed (i.e. Normally this would come before i, but I prefer to be positive :) iii) If you really want to go with tagging, some thoughts on heuristic techniques. ----- What I think we should be doing ---- At the bottom of one of Tom's recent emails he lists some URL's describing the arch system: > Let's talk tree reararrangements. They imply the ability to recognize > a logical identity of a file that is not tied to its physical location > in the tree. I think the "logical identity" problem is a separable > subproblem of the general changeset challenge. > http://regexps.srparish.net/tutorial/inventory-tags.html In particular, note the section titled "Why_is_it_Like_This_--_The_Purpose_of_Inventory_Tags" in that last URL where he discusses the reason behind 'tagging' every file. Basically, noone thinks this will be too hard: (using Tom's proposed formalism) delta(ORIG, MOD)[ORIG] == MOD but we want to handle the case where we are patching a file that has been moved as well: delta(ORIG, MOD)[NOT_ORIG] == ??? In Tom's current view, this means explicit tagging the individual files. I am not sure that this *explicit* tagging is necessary. For background, people may like to read: http://svn.collab.net/repos/svn/trunk/www/variance-adjusted- patching.html When patching a single file, you don't assign explicit labels to every line in the file and then match based on the labels. Rather, you track the changes as ORIG changes into NOT_ORIG to match the lines in the patch up correctly. This means that I'd change the formalism above to consider 3-way merges. We don't have the three trees, but if we can assume that both sender and receiver have ORIG, and that the receiver has delta(ORIG, NOT_ORIG). Then, delta(ORIG, MOD)[NOT_ORIG] == 3WayMerge(ORIG, delta(ORIG, MOD)[ORIG], delta(ORIG, NOT_ORIG)[ORIG]) Another way to think about this is to use as the tag for the entire patch. This information is included with the patch to label ORIG, it is then assumed that the local changes are known so that the tag can be brought up to date for each individual file. Another, more changeset oriented, option is a patch tag of , FILE_PATH>. In the second suggestion, the ordered list of changesets specifies ORIG instead of a revision. Is there another good way to specify ORIG? (I'm not sure if this document is also relevant to the discussion: http://svn.collab.net/repos/svn/trunk/notes/repeated-merging ) ----- some more problems I see with explicit tagging ---- There are a number of problems I see with explicit tagging. i) I don't want to have to deal with it manually. The version control system has to do it for me. I'm willing to 'svn mv', but not to 'svn label' afterwards. ii) If all you do is assign a UUID to a file as a tag when the file is created and then track that over copy history, then that is *not* enough. I often create Makefiles by copying a previous one and then modifying it. At some point I start thinking about this as its own file, and would be disturbed if a patch to the old file was mistakenly applied to it. (the 3-way merge suggestion above doesn't have this problem - history starts at ORIG.) ----- Thoughts on heuristic solutions ----- If you really want to go with file tagging, then because of ii) above, File UUID's that are invariant across all time will not cut it. You need ID's based on ORIG. However, if the receiving end had access to ORIG, you could use the patch directly. Sooo, you need to find short labels for the files in ORIG in such a way that you can recognise them later even if their names have changed. One possibility is checksumming. If you include checksums of all the original files in the patch, then if one of them has moved when you try to apply the patch, you can look for a file with the same checksum in NOT_ORIG. If you find one, assume that it was moved. What happens if the file was not only moved, but also modified? In this case you want an index that allows you to recognise the moved file, is robust to changes in the file, and is small enough to include in the patch. I'm thinking of something along the lines of a function indexFile(File) -> number. This would be like a checksum, but whereas a checksum is designed to NOT be robust, we would want this to be somewhat robust. The numbers are relatively distinct among files in the patch, and a small change in a file leads to only a small change in number. Good ways to solve this problem are a hot research topic in document retrieval (makes sense, huh :). See http://www.cs.rutgers.edu/~mlittman/topics/dimred02/ for one academic page on the problem. Simple forms of dimensionality reduction should work OK here, but you'd need to agree on the transform, or include it in the patch. ----- I'd go with Variance Adjusted Patching if I had a choice. Thoughts? Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From mass@akuma.org Mon Apr 7 22:51:49 2003 Received: from mail.aspect.net (adsl-65-69-210-161.dsl.hstntx.swbell.net [65.69.210.161]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h383pnbs008308 for ; Mon, 7 Apr 2003 22:51:49 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.aspect.net (Postfix) with ESMTP id CED991A6FF for ; Mon, 7 Apr 2003 22:51:48 -0500 (CDT) Received: from mail.aspect.net ([127.0.0.1]) by localhost (pavia.aspect.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08618-01 for ; Mon, 7 Apr 2003 22:51:46 -0500 (CDT) Received: from akuma.org (12-253-230-167.client.attbi.com [12.253.230.167]) by mail.aspect.net (Postfix) with ESMTP id 9581C1683A for ; Mon, 7 Apr 2003 22:51:45 -0500 (CDT) Message-ID: <3E92474D.4060009@akuma.org> Date: Mon, 07 Apr 2003 21:51:41 -0600 From: David Waite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: changesets@red-bean.com Subject: Re: Goals Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030314-p1 (Debian) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Karl Fogel wrote: > Goal: design a patch format that > > a) is compatible with the standard `patch' program in the sense > that `patch' will not choke on it, and will apply as much of it > as it can. > > b) expresses tree changes (directories and files > added, copied, renamed, and removed) > > c) supports generic metadata. What I have in mind are Subversion's > "properties", but there may be other sorts of metadata used by > Arch or other systems; none of it should be lost. > > I think (a) is pretty easy to achieve. Just put the extra data after > the last hunk of a file, and before the "Index: " line of the next > file. Or it may be that patch has provision for custom headers of > some sort? > > That's all. If these goals seem wildly off-base, this would be a good > time to say so :-). (I'm going to try to use Tom Lord's basic definitions for now, e.g. delta(ORIG, mod) = NEW) Here's some of the thoughts I had: 1) Well-defined way of specifying the base (ORIG set) on which the patch is defined. This includes the possibility of specifying URL(s) for the location of the base (ORIG set) 3) I don't care if it is compatible with patch, because - patch only supports a small subset of the files I work on (no binary and poor xml support) - knowing the ORIG set and the URL(s) for the location of the base means that person operating on the changeset can generate both the ORIG and NEW sets defined by the mod - the difference display and merging system used for file changes may very well differ based on the exact type of file (tree-based merging for structured data like XML, HTML, and maybe even parsed program text) However, I would imagine that I would get soundly outvoted on having binary diffs, and envision a text-safe format for changesets which includes (one, several) line-based diff formats, or a binary diff format, encoded via base64 or base85. Custom diff and merge tools will have to generate the original and new files based on these for more glorified display anyways. 4) Changesets should be heirarchial - they should be able to contain multiple changesets, as well as individual 'changes' to either content (files, metadata) or structure (create, move, delete, copy). That is, multiple distinct changes should not need to be collapsed into one before serialization into this format. 5) I haven't messed around with a system using changesets enough to know if a dependancy graph is desired between changesets, or if a linear order is sufficient. In either case, changes contained directly within a changeset should be order-independant (i.e. The only way to have multiple content modifications or structural modifications against a single file within a changeset is to have them indirectly included by sub-changesets) 6) It should be possible to represent a file within the managed space of a repository by a unique name in order to apply content changes in the lack of dependant structure changes. It looks like arch already has such a feature. 7) Changesets themselves should be trackable with a unique name/identifier. 8) The requirements for function delta envisioned above should not be part of the changeset format if possible - the changesets should be generic across systems with different merging strategies. I do see the need to create changesets which are able to describe the resolution to merge conflicts (but unfortunately I'm not mathmatically adept currently to 'prove' this to be possible). 9) It should be possible for me to invert a changeset, i.e. revert the changes. 10) It should be possible to only partially apply a changeset. Comments? -David Waite From willu.mailingLists@cse.unsw.edu.au Mon Apr 7 23:01:10 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h38418bs008523 for ; Mon, 7 Apr 2003 23:01:09 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Tue, 8 Apr 2003 14:01:07 +1000 From: William Uther To: Robert Anderson Date: Tue, 8 Apr 2003 14:00:54 +1000 Subject: Re: Variance Adjusted Changesets Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@red-bean.com In-Reply-To: <1049774424.1406.29.camel@lan1> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi, I've CC'd the list with this reply. I hope you don't mind. On Tuesday, April 8, 2003, at 02:00 PM, Robert Anderson wrote (amongst other things): > On Mon, 2003-04-07 at 19:58, William Uther wrote: >> ----- some more problems I see with explicit tagging ---- >> >> There are a number of problems I see with explicit tagging. >> >> i) I don't want to have to deal with it manually. The version control >> system has to do it for me. I'm willing to 'svn mv', but not to 'svn >> label' afterwards. > > I don't know what "svn label" is or why you think you would need to do > it. The arch system, for example, has two mechanisms for maintaining > file tags (three really, but one of them does not capture file > renames), > and at most they require a "larch mv" operation. If you put the tag in > the file itself, then there is no extra operation (so-called implicit > tags in arch). I was assuming that "svn label" would be something like the explicit form of "larch". My understanding of larch is the following, and please correct me if I am confused. larch has three systems: i) Just use the filename: Doesn't help us - cannot track files across renames. ii) Implicit labelling: embed a UUID into the file so that you can track it. This has the problem that it requires modifying the file. (amongst other problems) Our patch format should NOT require modifying the files! iii) Explicit labelling: I was assuming that "svn label" was something like this. In this case, the labels are stored outside the files. In arch they are tracked by larch. This has the problem that a copy command duplicates the UUID, and so it is no longer unique. This was my second point that you cut out above. Hmm - there may be a misunderstanding on my part here. Arch people: What happens to the tag when you move a file? I would assume it stays the same. What happens to the tag when you copy a file? It might stay the same, or a new one might be generated. In any case, I don't see a reason for these tags to be explicit in the patch format. All we need is an explicit means of specifying the starting point. Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From lord@emf.net Mon Apr 7 23:50:22 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h384oJbs010041 for ; Mon, 7 Apr 2003 23:50:20 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id VAA25317; Mon, 7 Apr 2003 21:59:56 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 21:59:56 -0700 (PDT) Message-Id: <200304080459.VAA25317@morrowfield.regexps.com> From: Tom Lord To: willu.mailingLists@cse.unsw.edu.au CC: changesets@red-bean.com In-reply-to: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> (message from William Uther on Tue, 8 Apr 2003 12:58:41 +1000) Subject: Re: Variance Adjusted Changesets References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: From: William Uther > Let's talk tree reararrangements. They imply the ability to recognize > a logical identity of a file that is not tied to its physical location > in the tree. [....] In Tom's current view, this means explicit tagging the individual files. I am not sure that this *explicit* tagging is necessary. [...] For background, people may like to read: http://svn.collab.net/repos/svn/trunk/www/variance-adjusted- patching.html When patching a single file, you don't assign explicit labels to every line in the file [....] We seem to have a deep miscommunication here. The variance-adjusted-patching file is about changes to the text within a file. Tagging is about tree structure. The two are nearly completely unrelated. Tagging relates to questions such as this: Programmer Quux has trees ORIG and MOD. They have the same tree structure, but Quux has modified ORIG/foo.c so that it's different in MOD/foo.c. He sends a patch, describing the change from ORIG to MOD to programmer Toom. Programmer Toom has a tree that ultimately derives from ORIG. He doesn't have ORIG around -- he has ORIG_VARIANT. In ORIG_VARIANT, the file that used to be called ORIG/foo.c is actually called ORIG_VARIANT/bar.c. Quux's patch has changes for a file named foo.c -- but Toom needs those changes to be applied to a file named bar.c. How does the `patch'-like tool know that bar.c is the same as foo.c? That's just one special case -- there are many other ways in which logical file/directory identity comes into play. There are a number of problems I see with explicit tagging. i) I don't want to have to deal with it manually. The version control system has to do it for me. I'm willing to 'svn mv', but not to 'svn label' afterwards. `svn mv' should ensure that the renamed file retains its logical identity. There's no need for an additional `svn label'. ii) If all you do is assign a UUID to a file as a tag when the file is created and then track that over copy history, then that is *not* enough. I often create Makefiles by copying a previous one and then modifying it. At some point I start thinking about this as its own file, and would be disturbed if a patch to the old file was mistakenly applied to it. (the 3-way merge suggestion above doesn't have this problem - history starts at ORIG.) A copied file, as opposed to a renamed one, should have a different tag. I wonder if you aren't restricting your attention to what arch calls "implicit tags" -- logical identifiers for files embedded in the files themselves. If you copy such a file, but don't change the embedded tag, then sure -- you wind up with two files having the same tag. That is an error. The arch command `tree-lint' detects that error -- and `tree-lint' has to pass before a `commit' can take place. In practice, unintuitively as it may sound -- I have found implicit (embedded) tags to be stunningly convenient. But it is not the only mechansism arch supports, nor the only mechanism I think a generic changeset tool should rely upon. If you really want to go with file tagging, There is _no choice_ but to provide logical identities ("inventory tags") for files if you want to support changesets that handle tree rearrangements. There is a wealth of possible mechanisms for managing tags. Roughly speaking, the mechanisms fall into two classes: 1) tags represented inside of files 2) tags represented externally, in other parts of the tree In practice, I have found that a mixture of those, both in the same tree, is the most convenient option. One possibility is checksumming. If you include checksums of all the original files in the patch, then if one of them has moved when you try to apply the patch, you can look for a file with the same checksum in NOT_ORIG. If you find one, assume that it was moved. No, that doesn't work. The file might not only have been moved -- it might also have been modified (so the hash would change). In this case you want an index that allows you to recognise the moved file, is robust to changes in the file, and is small enough to include in the patch. I'm thinking of something along the lines of a function indexFile(File) -> number. The third URL I provided proves that, for the fundamental equation, less than that index is needed provided you can compute "indexes" (tags) given a source tree. That's actually important because the list of files in many source trees is just too large to include in a reasonably sized changeset. Beyond the formal proof -- arch's `dopatch' demonstrates that truncated indexes are also suitable for inexact patching. I'd go with Variance Adjusted Patching if I had a choice. Thoughts? That's a bit like saying: "My choice of car? I like the authobhan highway personally." -t From lord@emf.net Mon Apr 7 23:56:18 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h384uGbs010192 for ; Mon, 7 Apr 2003 23:56:17 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id WAA25335; Mon, 7 Apr 2003 22:05:47 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 22:05:47 -0700 (PDT) Message-Id: <200304080505.WAA25335@morrowfield.regexps.com> From: Tom Lord To: willu.mailingLists@cse.unsw.edu.au CC: rwa@alumni.princeton.edu, changesets@red-bean.com In-reply-to: (message from William Uther on Tue, 8 Apr 2003 14:00:54 +1000) Subject: Re: Variance Adjusted Changesets References: Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: My understanding of larch is the following, and please correct me if I am confused. larch has three systems: i) Just use the filename: Doesn't help us - cannot track files across renames. ii) Implicit labelling: embed a UUID into the file so that you can track it. This has the problem that it requires modifying the file. (amongst other problems) Our patch format should NOT require modifying the files! iii) Explicit labelling: I was assuming that "svn label" was something like this. In this case, the labels are stored outside the files. In arch they are tracked by larch. This has the problem that a copy command duplicates the UUID, and so it is no longer unique. This was my second point that you cut out above. Two things: One: when you use implicit tags -- you can mix in explicit tags as well, and name tags too. In other words, roughly speaking, using your description, arch has three options: i iii i, ii, iii combined Thus you can embed tags in those files where it is convenient to do so, and use explicit or name tags elsewhere. Rather than `svn label' -- `svn add' would subsume that functionality. `svn mv' would move tags. `svn cp(?)' would generate a new tag for the copied file. Hmm - there may be a misunderstanding on my part here. Arch people: What happens to the tag when you move a file? I would assume it stays the same. What happens to the tag when you copy a file? It might stay the same, or a new one might be generated. You may not have two files with the same tag in the same tree. arch commands enforce that. In any case, I don't see a reason for these tags to be explicit in the patch format. All we need is an explicit means of specifying the starting point. I think you are confused on that point, and I'm not sure how to debug you. Perhaps if you want to elaborate. -t From rwa@alumni.princeton.edu Tue Apr 8 00:01:26 2003 Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3851Pbs010401 for ; Tue, 8 Apr 2003 00:01:26 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout3-ext.prodigy.net (8.12.3 patch/8.12.3) with ESMTP id h3851KIj493482; Tue, 8 Apr 2003 01:01:21 -0400 Subject: Re: Variance Adjusted Changesets From: Robert Anderson To: William Uther Cc: changesets@red-bean.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 07 Apr 2003 22:26:33 -0700 Message-Id: <1049779594.1406.47.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Mon, 2003-04-07 at 21:00, William Uther wrote: > Hi, > I've CC'd the list with this reply. I hope you don't mind. Not at all. Please do. > On Tuesday, April 8, 2003, at 02:00 PM, Robert Anderson wrote (amongst > other things): > > > On Mon, 2003-04-07 at 19:58, William Uther wrote: > >> ----- some more problems I see with explicit tagging ---- > >> > >> There are a number of problems I see with explicit tagging. > >> > >> i) I don't want to have to deal with it manually. The version control > >> system has to do it for me. I'm willing to 'svn mv', but not to 'svn > >> label' afterwards. > > > > I don't know what "svn label" is or why you think you would need to do > > it. The arch system, for example, has two mechanisms for maintaining > > file tags (three really, but one of them does not capture file > > renames), > > and at most they require a "larch mv" operation. If you put the tag in > > the file itself, then there is no extra operation (so-called implicit > > tags in arch). > > I was assuming that "svn label" would be something like the explicit > form of "larch". Ah. Yes, there is a "svn label" (aka "larch add") which generates the explicit tag. That is done _once_, however. Then "svn mv" or "larch move" (would) work as you would expect. > > My understanding of larch is the following, and please correct me if I > am confused. larch has three systems: > > i) Just use the filename: Doesn't help us - cannot track files across > renames. Correct. > ii) Implicit labelling: embed a UUID into the file so that you can > track it. This has the problem that it requires modifying the file. > (amongst other problems) Correct. Although for source code, it may be less of a problem than you might anticipate. In general though, it cannot be a requirement. > Our patch format should NOT require modifying the files! Agreed. "require" being a keyword. > iii) Explicit labelling: I was assuming that "svn label" was something > like this. In this case, the labels are stored outside the files. In > arch they are tracked by larch. This has the problem that a copy > command duplicates the UUID, and so it is no longer unique. This was > my second point that you cut out above. > > Hmm - there may be a misunderstanding on my part here. Arch people: > What happens to the tag when you move a file? I would assume it stays > the same. Yes. > What happens to the tag when you copy a file? It might stay > the same, or a new one might be generated. Neither. There is no "larch copy". cp, of course, knows nothing of arch tags. > In any case, I don't see a reason for these tags to be explicit in the > patch format. All we need is an explicit means of specifying the > starting point. I don't understand those two sentences, taken together. If you ORIG and MOD trees, how do you propose that files which are logically ancestral be detected? I _suspect_ that any such method that is sufficiently robust will not be worth the price of admission, relative to some kind of explicit tagging scheme. The so-called "copy history" concept is something you seem to be taking for granted. I think a first-instance question is: is that an essential feature, or more likely, one that is worth the complexities that it involves? It seems likely that such a thing generates significant complexities with respect to the inexact patching problem. But, I'm guessing at this point. Bob From rwa@alumni.princeton.edu Tue Apr 8 00:06:45 2003 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3856jbs010571 for ; Tue, 8 Apr 2003 00:06:45 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout2-ext.prodigy.net (8.12.3 patch/8.12.3) with ESMTP id h3856eqC365946; Tue, 8 Apr 2003 01:06:40 -0400 Subject: Re: Variance Adjusted Changesets From: Robert Anderson To: Tom Lord Cc: willu.mailingLists@cse.unsw.edu.au, changesets@red-bean.com In-Reply-To: <200304080459.VAA25317@morrowfield.regexps.com> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 07 Apr 2003 22:31:53 -0700 Message-Id: <1049779914.1405.51.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Mon, 2003-04-07 at 21:59, Tom Lord wrote: > > From: William Uther > > > Let's talk tree reararrangements. They imply the ability to recognize > > a logical identity of a file that is not tied to its physical location > > in the tree. > [....] > > In Tom's current view, this means explicit tagging the individual > files. I am not sure that this *explicit* tagging is necessary. > > [...] > > For background, people may like to read: > > http://svn.collab.net/repos/svn/trunk/www/variance-adjusted- > patching.html > > When patching a single file, you don't assign explicit labels to every > line in the file [....] > > > We seem to have a deep miscommunication here. I _think_ he was attempting to draw an analogy, the utility of which I was having trouble discovering myself. Or I could be wrong. Bob From lord@emf.net Tue Apr 8 00:14:47 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h385Ejbs010872 for ; Tue, 8 Apr 2003 00:14:46 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id WAA25436; Mon, 7 Apr 2003 22:24:27 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 22:24:27 -0700 (PDT) Message-Id: <200304080524.WAA25436@morrowfield.regexps.com> From: Tom Lord To: rwa@alumni.princeton.edu CC: willu.mailingLists@cse.unsw.edu.au, changesets@red-bean.com In-reply-to: <1049779914.1405.51.camel@lan1> (message from Robert Anderson on 07 Apr 2003 22:31:53 -0700) Subject: Re: Variance Adjusted Changesets References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049779914.1405.51.camel@lan1> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > We seem to have a deep miscommunication here. I _think_ he was attempting to draw an analogy, the utility of which I was having trouble discovering myself. All three of us should back off and start fresh, I think. The "deep miscommunication" I referred to was in what William was saying, not what Bob was saying. In short, talking about variance adjusted patching in the context of tree rearrangements is .... um .... pretty much off topic. (It's actually _not_ if you you're looking from a particular angle -- but I'm quite confident that that angle is very far removed from the current thread.) [But for archers following along: svn's variance adjusted changesets are a cool idea -- something to flush out and add to our suite of merge tools, at least.] -t From lord@emf.net Tue Apr 8 00:21:01 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h385Kxbs011079 for ; Tue, 8 Apr 2003 00:21:00 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id WAA25461; Mon, 7 Apr 2003 22:30:47 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Mon, 7 Apr 2003 22:30:47 -0700 (PDT) Message-Id: <200304080530.WAA25461@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com In-reply-to: <200304080524.WAA25436@morrowfield.regexps.com> (message from Tom Lord on Mon, 7 Apr 2003 22:24:27 -0700 (PDT)) Subject: Re: Variance Adjusted Changesets References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049779914.1405.51.camel@lan1> <200304080524.WAA25436@morrowfield.regexps.com> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: [But for archers following along: svn's variance adjusted changesets are a cool idea -- something to flush out and add to our suite of merge tools, at least.] Er.... "flesh out", of course. Hmm. -t From willu.mailingLists@cse.unsw.edu.au Tue Apr 8 01:54:21 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h386sJbs013872 for ; Tue, 8 Apr 2003 01:54:20 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Tue, 8 Apr 2003 16:54:16 +1000 From: William Uther To: Tom Lord Date: Tue, 8 Apr 2003 16:54:00 +1000 Subject: Re: Variance Adjusted Changesets Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@red-bean.com In-Reply-To: <200304080459.VAA25317@morrowfield.regexps.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Tuesday, April 8, 2003, at 02:59 PM, Tom Lord wrote: > For background, people may like to read: > > > http://svn.collab.net/repos/svn/trunk/www/variance-adjusted- > patching.html > > When patching a single file, you don't assign explicit labels to > every > line in the file [....] > > > We seem to have a deep miscommunication here. Er, yes. > The variance-adjusted-patching file is about changes to the text > within a file. > > Tagging is about tree structure. > > The two are nearly completely unrelated. Yes. As Rob said, I was attempting to draw an analogy. There are two sets of patching going on. There is patching of the individual files, and there is patching of the tree structure. The URL above describes variance-adjusted-patching.html of within the files. I was suggesting we could use a similar concept when patching the tree structure. I disagree that the two are completely unrelated, although maybe you're right and the analogy is not _that_ strong :). > Tagging relates to questions such as this: > > Programmer Quux has trees ORIG and MOD. They have the same tree > structure, but Quux has modified ORIG/foo.c so that it's different in > MOD/foo.c. He sends a patch, describing the change from ORIG to MOD > to programmer Toom. > > Programmer Toom has a tree that ultimately derives from ORIG. He > doesn't have ORIG around -- he has ORIG_VARIANT. In ORIG_VARIANT, > the file that used to be called ORIG/foo.c is actually called > ORIG_VARIANT/bar.c. Does Toom also have the information that his ORIG_VARIANT/bar.c is derived from ORIG/foo.c? > Quux's patch has changes for a file named foo.c -- but Toom needs > those changes to be applied to a file named bar.c. How does the > `patch'-like tool know that bar.c is the same as foo.c? In my concept, there is no explicit tag on foo.c in Quux's patch file that helps here. There is a tag on the entire ORIG tree. Also, Toom's local patch tool knows that his local bar.c is derived from the foo.c in the ORIG tree, and so the tool can apply the patch correctly. I'll say that again. The information about tagging is not in the patch file, but is stored by the patch generator and the patch applicator. They do not need to send tags in the patch format, because they agree on a common ORIG, and they both know their local changes from that point. The common ORIG is all that is needed. > i) I don't want to have to deal with it manually. The version > control > system has to do it for me. I'm willing to 'svn mv', but not to > 'svn > label' afterwards. > > `svn mv' should ensure that the renamed file retains its logical > identity. There's no need for an additional `svn label'. > A copied file, as opposed to a renamed one, should have a different > tag. Okie - got this now. Things aren't as bad as I thought. I still think I prefer the concept of remembering local change history to UUID's on files, although I can see arguments either way now. > There is _no choice_ but to provide logical identities ("inventory > tags") for files if you want to support changesets that handle tree > rearrangements. There is a wealth of possible mechanisms for > managing tags. I agree that there is not choice but to provide logical identities. That does not mean that files have to be explicitly tagged with more than the logical identity of the starting _tree_ in the patch file format. Yes, the tools that apply a patch to a locally changed tree will need to have tracked logical identities from that starting point, but again, this doesn't need to be in the patch format. > Roughly speaking, the mechanisms fall into two classes: > > 1) tags represented inside of files > 2) tags represented externally, in other parts of the tree Yes, and subversion uses something close to 2 - the information is stored in the working copy for uncommitted changes, and in the repository for committed changes. This does not mean that the identities need to be in the patch file format. > In practice, I have found that a mixture of those, both in the same > tree, is the most convenient option. > > > One possibility is checksumming. If you include checksums of all > the > original files in the patch, then if one of them has moved when you > try > to apply the patch, you can look for a file with the same checksum > in > NOT_ORIG. If you find one, assume that it was moved. > > No, that doesn't work. The file might not only have been moved -- it > might also have been modified (so the hash would change). As I said in the paragraph following the one you quote :). > In this case you want an index that allows you to recognise the > moved > file, is robust to changes in the file, and is small enough to > include > in the patch. I'm thinking of something along the lines of a > function > indexFile(File) -> number. > > The third URL I provided proves that, for the fundamental equation, > less than that index is needed provided you can compute "indexes" > (tags) given a source tree. That's actually important because the > list of files in many source trees is just too large to include in a > reasonably sized changeset. Beyond the formal proof -- arch's > `dopatch' demonstrates that truncated indexes are also suitable for > inexact patching. I agree. You only need to supply tags for those files that change. In this third section I was looking at how you could tag things in such a way that someone who didn't have the original tags, just the raw tree, and didn't have a history of their local changes, could STILL use the patch. > I'd go with Variance Adjusted Patching if I had a choice. > > That's a bit like saying: "My choice of car? I like the authobhan > highway personally." heh. Tree patching is more similar to file patching than cars are to roads. :) Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From pasky@machine.sinus.cz Tue Apr 8 01:58:11 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h386wAbs014006 for ; Tue, 8 Apr 2003 01:58:10 -0500 Received: (qmail 18176 invoked by uid 2001); 8 Apr 2003 06:58:07 -0000 Date: Tue, 8 Apr 2003 08:58:07 +0200 From: Petr Baudis To: Tom Lord Cc: ghudson@MIT.EDU, changesets@red-bean.com Subject: Re: Goals Message-ID: <20030408065807.GB3037@pasky.ji.cz> References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> <20030407234439.GA3037@pasky.ji.cz> <200304080025.RAA24580@morrowfield.regexps.com> <1049762009.2729.1.camel@error-messages.mit.edu> <200304080128.SAA24778@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304080128.SAA24778@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Tue, Apr 08, 2003 at 03:28:40AM CEST, I got a letter, where Tom Lord told me, that... > > > > Let's try to drop around some random ideas > > > > How about: let's not. > > If you don't like someone's ideas, you can criticize them or > (less optimally) you can ignore them. This sort of random > dismissal is only going to make it less likely that people will > try to collaborate with you. > > Let me clarify my curmodgeonly remark then. > > Petr: as advertised, your post is a string of random ideas. Some of > them sound promising, others less so. > > But by "dropping around random ideas", you're asking others to spend a > lot of time trying to figure out exactly what you might mean, to > separate the wheat from the chaff, and to respond to that. And if > that's not what you're asking for -- then what? a long spiral of > contentless back-and-forth threads characterized mostly by > misunderstanding? That kind of thing is a common failure mode of > technical discussions on mailing lists, so please try to avoid it. I've outlined some discussion about three topics in my mail (why (not) to use patch-compatible format, how a patch compatible format could look and about properties of a file id), which were I think clearly separated, focued and relatively compact. If you think some parts of the description are not clear, please feel encouraged to tell me which in particular and I will try to rewrite them (I'm not an English native speaker so it's possible I've build up too complicated maze from strange formulations). Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From fog@initd.org Tue Apr 8 02:03:42 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3873fbs014230 for ; Tue, 8 Apr 2003 02:03:41 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id D05CE3C0A5; Tue, 8 Apr 2003 08:49:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id C84EC1A2B8 for ; Tue, 8 Apr 2003 09:03:54 +0200 (CEST) Subject: Re: Goals From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <200304080128.SAA24778@morrowfield.regexps.com> References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> <20030407234439.GA3037@pasky.ji.cz> <200304080025.RAA24580@morrowfield.regexps.com> <1049762009.2729.1.camel@error-messages.mit.edu> <200304080128.SAA24778@morrowfield.regexps.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-dM8e9n5Ut5YxJUrARFNT" Organization: init.d Message-Id: <1049785432.1023.3.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 09:03:53 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-dM8e9n5Ut5YxJUrARFNT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 03:28, Tom Lord ha scritto: > > Let's try to drop around some random ideas=20 > >=20 > > How about: let's not. >=20 > If you don't like someone's ideas, you can criticize them or > (less optimally) you can ignore them. This sort of random > dismissal is only going to make it less likely that people will > try to collaborate with you. >=20 > Let me clarify my curmodgeonly remark then. >=20 > Petr: as advertised, your post is a string of random ideas. Some of > them sound promising, others less so. another random idea: take a look at last eva snapshot, that implements "eva metapatch" commands. they use some eva specifics (like tags cache to speed up diff lookup and manifest to keep track of "file tags") but the format is quite generic (mainly it is mime with embedded patch data). also, the python code allowas for easy addition of new patch formats (by just defining a subclass of PatchWriter) so it can be used as a testbed for new patch formats. eva snapshots are available at: http://initd.org/pub/software/eva/ ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. -- D.E.Knuth --=-dM8e9n5Ut5YxJUrARFNT Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+knRYvcCgrgZGjesRAqnUAKCZo4aYPdJVj6LSY0/JXMmsBUR/SACgh6eY BOZgW1IqS3iCkRmHeEn4VYQ= =2jaw -----END PGP SIGNATURE----- --=-dM8e9n5Ut5YxJUrARFNT-- From lars.segerlund@comsys.se Tue Apr 8 02:06:16 2003 Received: from kanga.comsys.se (gw.comsys.ideon.se [62.95.120.145]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3876Fbs014319 for ; Tue, 8 Apr 2003 02:06:15 -0500 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by localhost.0.168.192.in-addr.arpa (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h3876Dgf032711 for ; Tue, 8 Apr 2003 09:06:14 +0200 Message-ID: <3E9274E5.6070000@comsys.se> Date: Tue, 08 Apr 2003 09:06:13 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: changesets@red-bean.com Subject: Starting point .. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I think it would be wise to figure out what capabilities is needed, as for the format ( representation ), the diffs and so on. Also I am curious, will there be some code written here ? ( I cwould love to ! ). Perhaps also start of with some kind of changeset lingo ? or tutorial ? since there seem's to be much confusion about changesets. A set of testcases with increasing difficulty would also be a good start, since then one could target the first 'level' and move on. / regards, Lars Segerlund. From lord@emf.net Tue Apr 8 02:19:02 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h387Ixbs014620 for ; Tue, 8 Apr 2003 02:19:00 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id AAA25853; Tue, 8 Apr 2003 00:28:41 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 00:28:41 -0700 (PDT) Message-Id: <200304080728.AAA25853@morrowfield.regexps.com> From: Tom Lord To: willu.mailingLists@cse.unsw.edu.au CC: changesets@red-bean.com In-reply-to: (message from William Uther on Tue, 8 Apr 2003 16:54:00 +1000) Subject: Re: Variance Adjusted Changesets References: Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: The URL above describes variance-adjusted-patching.html of within the files. I was suggesting we could use a similar concept when patching the tree structure. Interesting. I don't see how that eliminates, in any way, the need for logical file identities. variance-adjusted-patching from my perspective looks like yet another merging technique -- and yes, the internal-to-file stuff has an analogy in the tree-arrangement part..... but this is still way off changesets. Changesets are a diff between two trees and you can apply them to a third. You can't drag in a fourth tree here or all the history data that might be in a repository. On the other hand, you can define variance-adjusted-patching in terms of changesets and transforms on them in the context of access to a full history. Does Toom also have the information that his ORIG_VARIANT/bar.c is derived from ORIG/foo.c? Indirectly, yes, because he knows the logical name of "bar.c", and the changeset with changes to bar.c assigns those changes to that logical name. But not directly, no. Other than by looking at the changeset, toom can _necessarily_ tell that his bar.c used to be called foo.c. In my concept, there is no explicit tag on foo.c in Quux's patch file that helps here. There is a tag on the entire ORIG tree. Also, Toom's local patch tool knows that his local bar.c is derived from the foo.c in the ORIG tree, and so the tool can apply the patch correctly. In the general case, Toom doesn't have access to ORIG or to the history between ORIG and his tree. I'll say that again. The information about tagging is not in the patch file, but is stored by the patch generator and the patch applicator. They do not need to send tags in the patch format, because they agree on a common ORIG, and they both know their local changes from that point. The common ORIG is all that is needed. I don't see why a `patch' replacement should rely on the recipient having access to ORIG or to any path from ORIG to the recipient's tree. I _think_ your "stuck" in the view of applying changesets in the context of repositories .... but changesets should be independent of repositories. I agree that there is not choice but to provide logical identities. That does not mean that files have to be explicitly tagged with more than the logical identity of the starting _tree_ in the patch file format. Yes, the tools that apply a patch to a locally changed tree will need to have tracked logical identities from that starting point, but again, this doesn't need to be in the patch format. A patch replacement should not require network roundtrips or local repository mirrors to operate. Lemme ask this: suppose I get a tar bundle of some distribution of some package. I put it on my laptop and disconnect from the net .... all I have is the tar bundle plus some patch. Are you saying that the tar bundle should contain a complete record of the renames between the ORIG of the patch and the tree in the tar bundle? I think it's far more practical just to decorate the tree in the tar bundle with a record of explicit tags. Those tags require a bounded amount of storage -- the rename history would require an unbounded amount. -t From lord@emf.net Tue Apr 8 02:23:44 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h387Ngbs014756 for ; Tue, 8 Apr 2003 02:23:43 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id AAA25904; Tue, 8 Apr 2003 00:33:28 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 00:33:28 -0700 (PDT) Message-Id: <200304080733.AAA25904@morrowfield.regexps.com> From: Tom Lord To: pasky@ucw.cz CC: ghudson@MIT.EDU, changesets@red-bean.com In-reply-to: <20030408065807.GB3037@pasky.ji.cz> (message from Petr Baudis on Tue, 8 Apr 2003 08:58:07 +0200) Subject: Re: Goals References: <86n0j2kokb.fsf@kepler.ch.collab.net> <85istqdp6n.fsf@newton.ch.collab.net> <200304072153.OAA24098@morrowfield.regexps.com> <20030407234439.GA3037@pasky.ji.cz> <200304080025.RAA24580@morrowfield.regexps.com> <1049762009.2729.1.camel@error-messages.mit.edu> <200304080128.SAA24778@morrowfield.regexps.com> <20030408065807.GB3037@pasky.ji.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I've outlined some discussion about three topics in my mail (why (not) to use patch-compatible format, how a patch compatible format could look and about properties of a file id), which were I think clearly separated, focued and relatively compact. Ok. Thanks for the guide to the earlier text and I'll revisit it with a more opened mind. I'm not an English native speaker Almost never a serious problem in my experience. It's entirely possible I just went off on you reflexively and unnecessarily. If so, sorry about that. -t From fog@initd.org Tue Apr 8 02:33:47 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h387Xkbs014954 for ; Tue, 8 Apr 2003 02:33:47 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id BD1223C282; Tue, 8 Apr 2003 09:19:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id CA01A1A2B7 for ; Tue, 8 Apr 2003 09:32:55 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <200304080459.VAA25317@morrowfield.regexps.com> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZoF7b0Nt7yPh1v94B0ct" Organization: init.d Message-Id: <1049787175.1023.18.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 09:32:55 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-ZoF7b0Nt7yPh1v94B0ct Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 06:59, Tom Lord ha scritto: > There is _no choice_ but to provide logical identities ("inventory > tags") for files if you want to support changesets that handle tree agreed, > rearrangements. There is a wealth of possible mechanisms for > managing tags. >=20 > Roughly speaking, the mechanisms fall into two classes: >=20 > 1) tags represented inside of files > 2) tags represented externally, in other parts of the tree >=20 > In practice, I have found that a mixture of those, both in the same > tree, is the most convenient option. another option is to save tags in a single "manifest" file. having a single file with well-defined format to ditribute with your sources is easy. each different SCMS implementation can then take that file, take it apart and fill implemetation specific details (as eva does with its tag cache to speedup "eva mv" operations or as arch does by writing .arch-ids directories). i think one of the main points of a genric patch set format is it to be less intrusive as possible on original sources. requiring .arch-ids directories to pollute my sources is too much but a single manifest file is good. >=20 >=20 > One possibility is checksumming. If you include checksums of all the = =20 > original files in the patch, then if one of them has moved when you tr= y =20 > to apply the patch, you can look for a file with the same checksum in = =20 > NOT_ORIG. If you find one, assume that it was moved. >=20 > No, that doesn't work. The file might not only have been moved -- it > might also have been modified (so the hash would change). yep. i suggest this notation: rename - file has moved patch - file was changed but did not change name modify - rename + patch type change - file was deleted and a different type was added last one (e.g., remove file xxx, add directory xxx) can confuse quite a lot normal patching applications. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org The devil speaks truth much oftener than he's deemed. He has an ignorant audience. -- Byron (suggested by Alice Fontana) --=-ZoF7b0Nt7yPh1v94B0ct Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+knsnvcCgrgZGjesRAo05AJ9cBBM5mLAxm/o1uBfproDxZxWEJgCfYoiZ TibK4VcAInwbj7WavuSuLr8= =7/01 -----END PGP SIGNATURE----- --=-ZoF7b0Nt7yPh1v94B0ct-- From lord@emf.net Tue Apr 8 02:39:00 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h387cwbs015029 for ; Tue, 8 Apr 2003 02:38:59 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id AAA25956; Tue, 8 Apr 2003 00:48:43 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 00:48:43 -0700 (PDT) Message-Id: <200304080748.AAA25956@morrowfield.regexps.com> From: Tom Lord To: lars.segerlund@comsys.se CC: changesets@red-bean.com In-reply-to: <3E9274E5.6070000@comsys.se> (message from Lars Segerlund on Tue, 08 Apr 2003 09:06:13 +0200) Subject: Re: Starting point .. References: <3E9274E5.6070000@comsys.se> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I think it would be wise to figure out what capabilities is needed, as for the format ( representation ), the diffs and so on. The textual format of changesets -- the syntax -- the representation: that stuff is "easy". To be sure, we should have some care about specing it out -- but the hard part: The hard part is the "capabilities": What "defines a tree" from the changeset perspective? What information is recorded in a diff between two trees? What does it mean to apply a diff to a non-ORIG tree? Those are the hard questions. There's a real danger here, too -- because it's such an open-ended topic. We could spend decades on it, really. Also I am curious, will there be some code written here ? ( I cwould love to ! ). Ideally, imo, yes. standalone `diff' and `patch' replacements in command and library form. The arch commands `mkpatch' and `dopatch' are my straw-man candidates (commands, not libraries so far). More raw materials: on the subject of tree rearrangements, there's this fragment: http://www.fifthvision.net/open/bin/view/Arch/PatchSetSemantics -t From lars.segerlund@comsys.se Tue Apr 8 02:49:48 2003 Received: from kanga.comsys.se (gw.comsys.ideon.se [62.95.120.145]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h387nlbs015293 for ; Tue, 8 Apr 2003 02:49:47 -0500 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by kanga.sys.energyx.se (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h387nkgf000707 for ; Tue, 8 Apr 2003 09:49:47 +0200 Message-ID: <3E927F19.5030008@comsys.se> Date: Tue, 08 Apr 2003 09:49:45 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: changesets@red-bean.com Subject: Re: Starting point .. References: <3E9274E5.6070000@comsys.se> <200304080748.AAA25956@morrowfield.regexps.com> In-Reply-To: <200304080748.AAA25956@morrowfield.regexps.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: So let's make some interesting testcases :-) . Preferably some scripts to set up and run 'automatically', ( by this I mean that they should be able to generate the content operated on). What we have to do is to create some tools for easy handling of patch/changesets , and preferably with some nice integration into other versioning systems such as Aegis, cvs, subversion and so on. If we make the testcases we have somewhere to progress from, perhaps also a suite to make things clearer for 'newbies'. / Lars Segerlund. Tom Lord wrote: > I think it would be wise to figure out what capabilities is > needed, as for the format ( representation ), the diffs and so > on. > > The textual format of changesets -- the syntax -- the representation: > that stuff is "easy". To be sure, we should have some care about > specing it out -- but the hard part: > > The hard part is the "capabilities": What "defines a tree" from the > changeset perspective? What information is recorded in a diff > between two trees? What does it mean to apply a diff to a non-ORIG > tree? Those are the hard questions. > > There's a real danger here, too -- because it's such an open-ended > topic. We could spend decades on it, really. > > Also I am curious, will there be some code written here ? ( I > cwould love to ! ). > > Ideally, imo, yes. standalone `diff' and `patch' replacements in > command and library form. The arch commands `mkpatch' and `dopatch' > are my straw-man candidates (commands, not libraries so far). > > More raw materials: on the subject of tree rearrangements, there's > this fragment: > > > http://www.fifthvision.net/open/bin/view/Arch/PatchSetSemantics > > -t > From willu.mailingLists@cse.unsw.edu.au Tue Apr 8 02:54:27 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h387sPbs015449 for ; Tue, 8 Apr 2003 02:54:26 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) By tone With Smtp ; Tue, 8 Apr 2003 17:54:23 +1000 From: William Uther To: changesets@red-bean.com Date: Tue, 8 Apr 2003 17:54:10 +1000 Subject: Re: Variance Adjusted Changesets Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Content-Transfer-Encoding: 7bit In-Reply-To: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> Message-Id: <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Let me try this again.... I'm going to assume that two people, Quux and Toom, both have a directory tree called ORIG: foo / \ Bar Baz Where foo is a dir and Bar and Baz are files. Quux changes the directory tree, renaming Bar to Pub and editing Baz. We will call this new tree MOD-Q. Toom also changes his directory tree, renaming Baz to Bazaar and editing it slightly. We will call this new tree MOD-T. ----- Option 1: file tags ----- (This is my understanding of what you are suggesting) We assign tags to each of the files in ORIG: foo: 1 Bar: 2 Baz: 3 The patch file specifies changes in terms of those tags. For example, if Quux were to "mkPatch ORIG MOD-Q" then you might get the following output: ---- begin patch ---- Rename 2: foo/Bar -> foo/Pub Edit 3: make changes to foo/Baz ---- end patch ---- When Toom makes his local changes, renaming Baz to Bazaar, the tag, 3, is preserved. Thus when Toom applies Quux's patch, Quux's edits to Baz can be made to Bazaar (assuming no conflicts with Toom's changes to the same file). Note that this makes the tags explicit in the patch format, and hence requires that all tools using the patch format think about tags in the same way. It also requires that any tools Toom uses to make his local changes preserve tags correctly. ----- Option 2: directory tags ----- (This is what I was suggesting) We assign a tag to the original tree: ORIG. The patch file describes changes relative to the root of that tree tag. For example, if Quux were to "mkPatch ORIG MOD-Q" then you might get the following output: ---- begin patch ---- Patch tree ORIG. Rename: foo/Bar -> foo/Pub Edit: make changes to foo/Baz ---- end patch ---- When Toom makes his local changes, renaming Baz to Bazaar, his local editor remembers this file history. It could be remembered either explicitly, as a list of renames, or in the form of local file tags. When Toom applies Quux's patch, the patch specifies the original tree ORIG. Toom's patch applicator can now trace what happened to Baz in the local copy, and apply the edits to Bazaar (again, assuming no conflicts with Toom's changes to the same file). This requires a global namespace for directory trees. It requires that Toom's system have some way of keeping track of change history - either as an explicit history or as file tags. It does NOT require that all tools using the changeset format think about file tags in the same way. ----- Option 3: file similarity numbering ----- This is the option I mentioned right at the bottom of my first email: We assign tags to each of the files in ORIG. However, a special function is used to generate these tags. This function has the following properties: - it is deterministic based on the file contents - tags are relatively short - tags do not conflict too much - small changes in a file lead to only small changes in tag AND the distance between two tags can be measured to approximate the size of the changes between any two files foo: 89458957439573498 Bar: 2298894348935458943 Baz: 6739494337483783 The patch file specifies changes in terms of those tags. For example, if Quux were to "mkPatch ORIG MOD-Q" then you might get the following output: ---- begin patch ---- Rename 2298894348935458943: foo/Bar -> foo/Pub Edit 6739494337483783: make changes to foo/Baz ---- end patch ---- Toom does not have any tags in his copy of ORIG - just the raw files. Toom does however have the function that generates ID's. He generates ID's for his files: foo: 89458957439573498 Bar: 2298894348935458943 Bazaar: 6739494337639938 Note that the ID for Bazaar is different to the ID for Baz in ORIG because Toom has edited Bazaar. Because of the nature of the function however, we can match Baz to Bazaar as the IDs are close to each other. Thus when Toom applies Quux's patch, the edits to Baz can be made to Bazaar (again, assuming no conflicts). Note that this is a heuristic solution. Unlike the other two approaches, it doesn't require any form of explicit file tracking. Yes, I think functions like this are possible, although I don't know how well they would work in practice. I'm just mentioning what I see as another solution to the problem. Later, Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From rbcollins@cygwin.com Tue Apr 8 03:08:46 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3888jbs015733 for ; Tue, 8 Apr 2003 03:08:45 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192o9l-0002On-00; Tue, 08 Apr 2003 18:08:37 +1000 Subject: Re: Variance Adjusted Changesets From: Robert Collins To: Federico Di Gregorio Cc: changesets@sp.red-bean.com In-Reply-To: <1049787175.1023.18.camel@momo.initd.org> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-V/AqZz35+75j+dIdbJfN" Organization: Message-Id: <1049789315.893.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 18:08:35 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-V/AqZz35+75j+dIdbJfN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 17:32, Federico Di Gregorio wrote: > i think one of the main points of a genric patch set format is it to be > less intrusive as possible on original sources. requiring .arch-ids > directories to pollute my sources is too much but a single manifest file > is good. A single manifest in a patch set is workable.=20 A single manifest in a project tree is less so - because it prevents trivial file operations that users intuitively expect to work. I.e. copying a subtree from one project dir to another. Rob --=20 GPG key available at: . --=-V/AqZz35+75j+dIdbJfN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+koOCI5+kQ8LJcoIRAmPrAJ9FBHKlsP/Q5dQ8TISM4RMJE8YVgACeIJYH vhx20vrif+vRnyDxprIRods= =0Af8 -----END PGP SIGNATURE----- --=-V/AqZz35+75j+dIdbJfN-- From lord@emf.net Tue Apr 8 03:19:39 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388Jbbs016020 for ; Tue, 8 Apr 2003 03:19:38 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id BAA26071; Tue, 8 Apr 2003 01:29:23 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 01:29:23 -0700 (PDT) Message-Id: <200304080829.BAA26071@morrowfield.regexps.com> From: Tom Lord To: willu.mailingLists@cse.unsw.edu.au CC: changesets@red-bean.com In-reply-to: <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> (message from William Uther on Tue, 8 Apr 2003 17:54:10 +1000) Subject: Re: Variance Adjusted Changesets References: <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: (This is what I was suggesting) [....] When Toom makes his local changes, renaming Baz to Bazaar, his local editor remembers this file history. That's what I think is bogus about your approach. Toom didn't rename Baz to Bazaar -- he got a tree from someone else who renamed Zing to Bazaar and who got their tree from someone else who renamed Kapow to Zing who got it from someone else ...... who got it from someone else who renamed Baz to Zowie. Now either the tree records the long history of those renames and each tree has a global name (unbounded storage and the new problem of global tree names) -- or we go with inventory tags as I've suggested (bounded storage, no global namespace (at this level) of trees. We assign tags to each of the files in ORIG. However, a special function is used to generate these tags. This function has the following properties: - it is deterministic based on the file contents - tags are relatively short - tags do not conflict too much - small changes in a file lead to only small changes in tag AND the distance between two tags can be measured to approximate the size of the changes between any two files Good luck :-) Yes, I think functions like this are possible, although I don't know how well they would work in practice. I'm just mentioning what I see as another solution to the problem. It'll never work in practice, imho -- but I'll bet that if you constrain the domain of files more than is really practical here, you can come up with some interesting file-signature functions. Sounds like a fun eddy-current of math to play with. -t From fog@initd.org Tue Apr 8 03:19:41 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388Jfbs016019 for ; Tue, 8 Apr 2003 03:19:41 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 1D7CF3C09A; Tue, 8 Apr 2003 10:05:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id A9C421A2B7; Tue, 8 Apr 2003 10:19:21 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: Robert Collins Cc: changesets@sp.red-bean.com In-Reply-To: <1049789315.893.29.camel@localhost> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HpM6W1cJpwd94xwd4Ps5" Organization: init.d Message-Id: <1049789961.1023.45.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 10:19:21 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-HpM6W1cJpwd94xwd4Ps5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 10:08, Robert Collins ha scritto: > On Tue, 2003-04-08 at 17:32, Federico Di Gregorio wrote: >=20 >=20 > > i think one of the main points of a genric patch set format is it to be > > less intrusive as possible on original sources. requiring .arch-ids > > directories to pollute my sources is too much but a single manifest fil= e > > is good. >=20 > A single manifest in a patch set is workable.=20 >=20 > A single manifest in a project tree is less so - because it prevents > trivial file operations that users intuitively expect to work. without a way to logically tag files (as explained by tom) you renounce to rename & patch operation. imho, patch sets using only physical names (patsh) are doomed to fail on complex non-exact patching operations. > I.e. copying a subtree from one project dir to another. {eva|arch|svn|...} mv --recursive orig_dir dest_dir --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org All programmers are optimists. -- Frederick P. Brooks, Jr. --=-HpM6W1cJpwd94xwd4Ps5 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+koYJvcCgrgZGjesRAr9MAKCRJ9kuSA5IogWQelNsCB9E9enuEgCfZ1uZ Z1URs2GugNNcJMIR5JQI614= =thSw -----END PGP SIGNATURE----- --=-HpM6W1cJpwd94xwd4Ps5-- From lord@emf.net Tue Apr 8 03:22:18 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388MHbs016102 for ; Tue, 8 Apr 2003 03:22:17 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id BAA26102; Tue, 8 Apr 2003 01:31:36 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 01:31:36 -0700 (PDT) Message-Id: <200304080831.BAA26102@morrowfield.regexps.com> From: Tom Lord To: rbcollins@cygwin.com CC: fog@initd.org, changesets@sanpietro.red-bean.com In-reply-to: <1049789315.893.29.camel@localhost> (message from Robert Collins on 08 Apr 2003 18:08:35 +1000) Subject: Re: Variance Adjusted Changesets References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: A single manifest in a project tree is less so - because it prevents trivial file operations that users intuitively expect to work. I.e. copying a subtree from one project dir to another. Bravo. -t From rbcollins@cygwin.com Tue Apr 8 03:23:04 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388N2bs016116 for ; Tue, 8 Apr 2003 03:23:03 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192oNb-0002iM-00; Tue, 08 Apr 2003 18:22:55 +1000 Subject: Re: Variance Adjusted Changesets From: Robert Collins To: Federico Di Gregorio Cc: changesets@sp.red-bean.com In-Reply-To: <1049789961.1023.45.camel@momo.initd.org> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YzWnscCvfdE1yWa/T1B3" Organization: Message-Id: <1049790175.893.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 18:22:55 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-YzWnscCvfdE1yWa/T1B3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 18:19, Federico Di Gregorio wrote: > > A single manifest in a patch set is workable.=20 > >=20 > > A single manifest in a project tree is less so - because it prevents > > trivial file operations that users intuitively expect to work. >=20 > without a way to logically tag files (as explained by tom) you renounce > to rename & patch operation. imho, patch sets using only physical names > (patsh) are doomed to fail on complex non-exact patching operations. Yup. We need logical tags. I was only addressing the mechanism you articulated. > > I.e. copying a subtree from one project dir to another. >=20 > {eva|arch|svn|...} mv --recursive orig_dir dest_dir Yuk. Between an eva and an svn project tree? Rob --=20 GPG key available at: . --=-YzWnscCvfdE1yWa/T1B3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kobfI5+kQ8LJcoIRAnFOAKCnlYu6RE/ua1IHCF2K8iRM0Wo0OwCgiGRM 3GmWNWDxNvhaKAFbtzCK51s= =0cE/ -----END PGP SIGNATURE----- --=-YzWnscCvfdE1yWa/T1B3-- From willu.mailingLists@cse.unsw.edu.au Tue Apr 8 03:24:02 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h388O1bs016133 for ; Tue, 8 Apr 2003 03:24:01 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Tue, 8 Apr 2003 18:23:56 +1000 From: William Uther To: Tom Lord Date: Tue, 8 Apr 2003 18:23:43 +1000 Subject: Re: Variance Adjusted Changesets Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@red-bean.com In-Reply-To: <200304080728.AAA25853@morrowfield.regexps.com> Message-Id: <693913D8-699B-11D7-AE74-000393CDF554@cse.unsw.edu.au> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Tuesday, April 8, 2003, at 05:28 PM, Tom Lord wrote: > I _think_ your "stuck" in the view of applying changesets in the > context of repositories .... but changesets should be independent of > repositories. hehe. I _think_ you're "stuck" in the view of designing changeset formats with arch style file tags .... but changeset formats should be independent of the tools used to generate and apply them. :) > I agree that there is not choice but to provide logical > identities. That does not mean that files have to be > explicitly tagged with more than the logical identity of the > starting _tree_ in the patch file format. Yes, the tools that > apply a patch to a locally changed tree will need to have > tracked logical identities from that starting point, but > again, this doesn't need to be in the patch format. > > A patch replacement should not require network roundtrips or local > repository mirrors to operate. You also require that local changes preserve tags. That is no more than I need. > Lemme ask this: suppose I get a tar bundle of some distribution of > some package. I put it on my laptop and disconnect from the net > .... all I have is the tar bundle plus some patch. Does the patch apply to that version of that package? If so, apply your patch :) If not, then things get more complex... Were the changes from the source of the patch, ORIG, to the tree you have, MOD, made using appropriate tools? If so, those tools would have generated meta-data... either keeping the tags up to date, or generating a change history in some other form. If you either didn't use the right tools, or don't have the meta data, then neither your system nor mine will work. If you did use the right tools, and have the meta-data, then both systems will work. > Are you saying that the tar bundle should contain a complete record of > the renames between the ORIG of the patch and the tree in the tar > bundle? I think it's far more practical just to decorate the tree in > the tar bundle with a record of explicit tags. Those tags require a > bounded amount of storage -- the rename history would require an > unbounded amount. I'm saying that either: - The tar file should be the tree the patch was designed to be applied to, or, - There needs to be some extra meta-data included with the tar file telling the patch application tools how files were moved between ORIG and the tar file (MOD). That meta-data could be in the form of a list of files that were renamed between ORIG and MOD (with their new names) - intermediate renames are not neccessary. It could also be in any one of a number of other formats. If you wish to include the meta-data with the tar file, then that is fine. You are requiring the tools to use your conception of how the changes should be tracked, and I am not sure that is necessary. Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From lord@emf.net Tue Apr 8 03:35:38 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388Zabs016379 for ; Tue, 8 Apr 2003 03:35:36 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id BAA26177; Tue, 8 Apr 2003 01:45:20 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 01:45:20 -0700 (PDT) Message-Id: <200304080845.BAA26177@morrowfield.regexps.com> From: Tom Lord To: willu.mailingLists@cse.unsw.edu.au CC: changesets@red-bean.com In-reply-to: <693913D8-699B-11D7-AE74-000393CDF554@cse.unsw.edu.au> (message from William Uther on Tue, 8 Apr 2003 18:23:43 +1000) Subject: Re: Variance Adjusted Changesets References: <693913D8-699B-11D7-AE74-000393CDF554@cse.unsw.edu.au> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > I _think_ your "stuck" in the view of applying changesets in the > context of repositories .... but changesets should be independent of > repositories. hehe. I _think_ you're "stuck" in the view of designing changeset formats with arch style file tags .... but changeset formats should be independent of the tools used to generate and apply them. :) I'm trying to stay open-minded to that possibility -- but so far, tags (of which the arch mechanisms are just a subset -- they can be expanded in some details) seem both essential and independent of rev ctl. You also require that local changes preserve tags. That is no more than I need. Please see my later message about how Toom got his tree with renames. Nothing "local" about that. Does the patch apply to that version of that package? If so, apply your patch :) If not, then things get more complex... Were the changes from the source of the patch, ORIG, to the tree you have, MOD, made using appropriate tools? If so, those tools would have generated meta-data... Well... hmm. Multi-faceted answer. 1) Is that meta-data bounded or unbounded in size? Bounded means using tags, as I've suggested -- unbounded means keeping rename histories, as you've suggested. 2) Using the "implicit" tagging method of arch, I don't need special tools 99% of the time. I just use `mv(1)'. If you either didn't use the right tools, or don't have the meta data, then neither your system nor mine will work. Most of my trees, where I actually apply these ideas, use implicit tags. I just use `mv(1)' and the only meta-data is "tag:" comments in source files. - The tar file should be the tree the patch was designed to be applied to, or, - There needs to be some extra meta-data included with the tar file telling the patch application tools how files were moved between ORIG and the tar file (MOD). That meta-data could be in the form of a list of files that were renamed between ORIG and MOD (with their new names) - intermediate renames are not neccessary. It could also be in any one of a number of other formats. Ok... that sums up your position well enough that we can refer to it. -t From fog@initd.org Tue Apr 8 03:43:41 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388hebs016522 for ; Tue, 8 Apr 2003 03:43:40 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 8DDE23C09A; Tue, 8 Apr 2003 10:29:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 3D36E1A2B7 for ; Tue, 8 Apr 2003 10:42:21 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <200304080845.BAA26177@morrowfield.regexps.com> References: <693913D8-699B-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080845.BAA26177@morrowfield.regexps.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-amDK5tJqG9JNmaUQV/jt" Organization: init.d Message-Id: <1049791340.1023.69.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 10:42:21 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-amDK5tJqG9JNmaUQV/jt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 10:45, Tom Lord ha scritto: > - The tar file should be the tree the patch was designed to be=20 > applied to, or, > - There needs to be some extra meta-data included with the tar file=20 > telling the patch application tools how files were moved between ORIG=20 > and the tar file (MOD). That meta-data could be in the form of a list=20 > of files that were renamed between ORIG and MOD (with their new names)=20 > - intermediate renames are not neccessary. It could also be in any one=20 > of a number of other formats. both of this solutions won't work when the target tree is different from MOD. e.g.: ORIG/foo.c -> MOD/bar.c (plus modifications) but in my target tree, i did: ORIG/foo.c -> TARGET/src/foo.c (a simple rename) without tags your patch will *never* apply because it won't find the target file. complex patch operations *need* logical tags. i can't do anything else than agree with tom on that. =20 --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org The number of the beast: vi vi vi. -- Delexa Jones --=-amDK5tJqG9JNmaUQV/jt Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kotsvcCgrgZGjesRAg0EAKCIwXaLKI3txT05SfakTyHW+xM5HACeNhmc QA7i6VfJKXN8h9mpXGEUm7I= =rICl -----END PGP SIGNATURE----- --=-amDK5tJqG9JNmaUQV/jt-- From fog@initd.org Tue Apr 8 03:49:41 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388nebs016650 for ; Tue, 8 Apr 2003 03:49:40 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id E12A63C09A; Tue, 8 Apr 2003 10:35:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 5FE631A2B7 for ; Tue, 8 Apr 2003 10:49:38 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> References: <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7MY/OU5ksnJCgfbqEtDs" Organization: init.d Message-Id: <1049791778.1023.76.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 10:49:38 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-7MY/OU5ksnJCgfbqEtDs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 09:54, William Uther ha scritto: > ----- Option 2: directory tags ----- >=20 > (This is what I was suggesting) >=20 > We assign a tag to the original tree: ORIG. >=20 > The patch file describes changes relative to the root of that tree tag.=20 > For example, if Quux were to "mkPatch ORIG MOD-Q" then you might get=20 > the following output: >=20 > ---- begin patch ---- > Patch tree ORIG. > Rename: foo/Bar -> foo/Pub > Edit: make changes to foo/Baz > ---- end patch ---- >=20 > When Toom makes his local changes, renaming Baz to Bazaar, his local=20 > editor remembers this file history. It could be remembered either=20 > explicitly, as a list of renames, or in the form of local file tags. so you're assuming: 1) unbounded metadata size 2) local metadata (i have no way to pass this metadata to people using a different SCMS system) both are problem and both are automatically solved if the tag format and meaning is a well defined standard. > ----- Option 3: file similarity numbering ----- [snip] > Yes, I think functions like this are possible, although I don't know=20 > how well they would work in practice. I'm just mentioning what I see=20 > as another solution to the problem. and a very interesting approach, indeed. because explicit tags and file similarity can be mixed: when generating a tag build it in two parts: - if the system you're using has a tag-caching mechanism (manifest, implicit tags, anything) you'll use full tags else you can use just the to some euristics and try to find the right files anyway. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-7MY/OU5ksnJCgfbqEtDs Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+ko0ivcCgrgZGjesRAlAEAJ9sX7gLWOBz2VW7tCRORsFEO7HUCQCgyjd2 M3G1p+SgU2RrE5HdkJaYTpA= =sWZd -----END PGP SIGNATURE----- --=-7MY/OU5ksnJCgfbqEtDs-- From fog@initd.org Tue Apr 8 03:55:43 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h388thbs016773 for ; Tue, 8 Apr 2003 03:55:43 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 7D1543C0A3; Tue, 8 Apr 2003 10:41:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 854C31A2B7; Tue, 8 Apr 2003 10:54:21 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: Robert Collins Cc: changesets@sp.red-bean.com In-Reply-To: <1049790175.893.31.camel@localhost> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pEzPp3F0ksPTTYPucq1q" Organization: init.d Message-Id: <1049792061.1023.81.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 10:54:21 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-pEzPp3F0ksPTTYPucq1q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 10:22, Robert Collins ha scritto: > > > I.e. copying a subtree from one project dir to another. > >=20 > > {eva|arch|svn|...} mv --recursive orig_dir dest_dir >=20 > Yuk. Between an eva and an svn project tree? if tags use a common format you *can* move files between different trees without too much hassle. if you have a command to extract the tag and a command to add a file with a given tag (*or* if we decide to support embedded [i like that better than implicit] tags) you just need to: cp arch-tree/foo eva-tree/foo eva add --tag `arch get-tag arch-tree/foo` eva-tree-foo (and the second line is not even necessary if you use embedded tags.) --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-pEzPp3F0ksPTTYPucq1q Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+ko49vcCgrgZGjesRAnReAJwKutYuEySUi4bBVEb7o9MT1sXuzgCfWp84 xN14zOu2PJhtw/WY65O9vlk= =M5Fh -----END PGP SIGNATURE----- --=-pEzPp3F0ksPTTYPucq1q-- From rbcollins@cygwin.com Tue Apr 8 04:01:12 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3891Bbs016932 for ; Tue, 8 Apr 2003 04:01:12 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192oyW-00031U-00; Tue, 08 Apr 2003 19:01:04 +1000 Subject: Re: Variance Adjusted Changesets From: Robert Collins To: Federico Di Gregorio Cc: changesets@sp.red-bean.com In-Reply-To: <1049792061.1023.81.camel@momo.initd.org> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iXuHGL14oGAiJ1XlcpMO" Organization: Message-Id: <1049792463.879.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 19:01:03 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-iXuHGL14oGAiJ1XlcpMO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 18:54, Federico Di Gregorio wrote: > Il mar, 2003-04-08 alle 10:22, Robert Collins ha scritto: >=20 > > > > I.e. copying a subtree from one project dir to another. > > >=20 > > > {eva|arch|svn|...} mv --recursive orig_dir dest_dir > >=20 > > Yuk. Between an eva and an svn project tree? >=20 > if tags use a common format you *can* move files between different trees > without too much hassle. if you have a command to extract the tag and a > command to add a file with a given tag (*or* if we decide to support > embedded [i like that better than implicit] tags) you just need to: >=20 > cp arch-tree/foo eva-tree/foo > eva add --tag `arch get-tag arch-tree/foo` eva-tree-foo >=20 > (and the second line is not even necessary if you use embedded tags.) embedded? Do you mean along the lines of the .arch-ids directories? Rob --=20 GPG key available at: . --=-iXuHGL14oGAiJ1XlcpMO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+ko/OI5+kQ8LJcoIRAh9FAJ0Wg3f82iU+ZiRALLcQvO5z4yVS7gCfXP5R zDYkmuzy9VrkSM3V1P2jOcw= =kctj -----END PGP SIGNATURE----- --=-iXuHGL14oGAiJ1XlcpMO-- From willu@cse.unsw.edu.au Tue Apr 8 04:05:24 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3895Nbs017034 for ; Tue, 8 Apr 2003 04:05:24 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Tue, 8 Apr 2003 19:05:20 +1000 From: William Uther To: Federico Di Gregorio Date: Tue, 8 Apr 2003 19:05:08 +1000 Subject: Re: Variance Adjusted Changesets Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@sp.red-bean.com In-Reply-To: <1049791340.1023.69.camel@momo.initd.org> Message-Id: <320B1F92-69A1-11D7-AE74-000393CDF554@cse.unsw.edu.au> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Tuesday, April 8, 2003, at 06:42 PM, Federico Di Gregorio wrote: > Il mar, 2003-04-08 alle 10:45, Tom Lord ha scritto: > >> - The tar file should be the tree the patch was designed to be >> applied to, or, >> - There needs to be some extra meta-data included with the tar >> file >> telling the patch application tools how files were moved between ORIG >> and the tar file (MOD). That meta-data could be in the form of a >> list >> of files that were renamed between ORIG and MOD (with their new >> names) >> - intermediate renames are not neccessary. It could also be in any >> one >> of a number of other formats. > > both of this solutions won't work when the target tree is different > from > MOD. e.g.: > > ORIG/foo.c -> MOD/bar.c (plus modifications) > > but in my target tree, i did: > > ORIG/foo.c -> TARGET/src/foo.c (a simple rename) > > without tags your patch will *never* apply because it won't find the > target file. complex patch operations *need* logical tags. i can't do > anything else than agree with tom on that. There is no need to shout. It really doesn't make your argument stronger. When I use 'mv' to move ORIG/blah.jpeg -> TARGET/queazel.jpeg the tag-based patch will *never* apply. (well, not without manual updating of the tags) You *need* tools to update your tags, in the same way I need tools to update my meta-data. There is no *need* for tags - they have certain advantages and certain disadvantages. You *need* to stop shouting or you'll start to look immature. Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From fog@initd.org Tue Apr 8 04:07:41 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3897ebs017085 for ; Tue, 8 Apr 2003 04:07:41 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 0A4023C394; Tue, 8 Apr 2003 10:53:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id D6B001A2B7; Tue, 8 Apr 2003 11:07:21 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: Robert Collins Cc: changesets@sp.red-bean.com In-Reply-To: <1049792463.879.33.camel@localhost> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> <1049792463.879.33.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XSzkHmCUIAEwQbyQ2Ynj" Organization: init.d Message-Id: <1049792841.1023.88.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 11:07:21 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-XSzkHmCUIAEwQbyQ2Ynj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 11:01, Robert Collins ha scritto: > On Tue, 2003-04-08 at 18:54, Federico Di Gregorio wrote: > > Il mar, 2003-04-08 alle 10:22, Robert Collins ha scritto: > >=20 > > > > > I.e. copying a subtree from one project dir to another. > > > >=20 > > > > {eva|arch|svn|...} mv --recursive orig_dir dest_dir > > >=20 > > > Yuk. Between an eva and an svn project tree? > >=20 > > if tags use a common format you *can* move files between different tree= s > > without too much hassle. if you have a command to extract the tag and a > > command to add a file with a given tag (*or* if we decide to support > > embedded [i like that better than implicit] tags) you just need to: > >=20 > > cp arch-tree/foo eva-tree/foo > > eva add --tag `arch get-tag arch-tree/foo` eva-tree-foo > >=20 > > (and the second line is not even necessary if you use embedded tags.) >=20 > embedded? Do you mean along the lines of the .arch-ids directories? like arch's implicit tags. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Gli esseri umani, a volte, sono destinati, per il solo fatto di esistere, a fare del male a qualcuno. -- Haruki Murakami --=-XSzkHmCUIAEwQbyQ2Ynj Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpFJvcCgrgZGjesRAspsAKCcIVwZUI8iHRpfh0sGgadl+9Db3QCfZW2s OE4De2aUWYFB4WWTPk0duTc= =WNrf -----END PGP SIGNATURE----- --=-XSzkHmCUIAEwQbyQ2Ynj-- From fog@initd.org Tue Apr 8 04:11:40 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389Bdbs017213 for ; Tue, 8 Apr 2003 04:11:39 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id E9DFB3C0EC; Tue, 8 Apr 2003 10:57:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 12B881A2B7; Tue, 8 Apr 2003 11:11:44 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: William Uther Cc: changesets@sp.red-bean.com In-Reply-To: <320B1F92-69A1-11D7-AE74-000393CDF554@cse.unsw.edu.au> References: <320B1F92-69A1-11D7-AE74-000393CDF554@cse.unsw.edu.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LTwicKDh8W65O5Uysgy9" Organization: init.d Message-Id: <1049793103.1023.93.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 11:11:43 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-LTwicKDh8W65O5Uysgy9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 11:05, William Uther ha scritto: > On Tuesday, April 8, 2003, at 06:42 PM, Federico Di Gregorio wrote: >=20 > > Il mar, 2003-04-08 alle 10:45, Tom Lord ha scritto: > > > >> - The tar file should be the tree the patch was designed to be > >> applied to, or, > >> - There needs to be some extra meta-data included with the tar=20 > >> file > >> telling the patch application tools how files were moved between ORIG > >> and the tar file (MOD). That meta-data could be in the form of a=20 > >> list > >> of files that were renamed between ORIG and MOD (with their new=20 > >> names) > >> - intermediate renames are not neccessary. It could also be in any=20 > >> one > >> of a number of other formats.=20 > > > > both of this solutions won't work when the target tree is different=20 > > from > > MOD. e.g.: > > > > ORIG/foo.c -> MOD/bar.c (plus modifications) > > > > but in my target tree, i did: > > > > ORIG/foo.c -> TARGET/src/foo.c (a simple rename) > > > > without tags your patch will *never* apply because it won't find the > > target file. complex patch operations *need* logical tags. i can't do > > anything else than agree with tom on that. >=20 > There is no need to shout. It really doesn't make your argument=20 > stronger. shouting? i use ** for emphasis; imagine me moving my hands (in tipical italian style, publicized by many hollywood movies) and putting an accent on that word. :) >=20 > When I use 'mv' to move >=20 > ORIG/blah.jpeg -> TARGET/queazel.jpeg >=20 > the tag-based patch will *never* apply. (well, not without manual=20 right. > updating of the tags) You *need* tools to update your tags, in the=20 > same way I need tools to update my meta-data. There is no *need* for=20 yes. i was missing the point about your tools. see my other mail where i consider them... > tags - they have certain advantages and certain disadvantages. You=20 > *need* to stop shouting or you'll start to look immature. see above, please. (and lets all think twice before starting to criticize each others writing style.) --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Lasciate che i furetti vengano a me. -- Maria Luisa Benedetta Panzani --=-LTwicKDh8W65O5Uysgy9 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpJPvcCgrgZGjesRApnvAKCkyRoIZRUuSuRWe/ZkxBOITErpkACgr40D JrWbHLa7YK/I0Ju3pkUlzno= =7luv -----END PGP SIGNATURE----- --=-LTwicKDh8W65O5Uysgy9-- From striker@apache.org Tue Apr 8 04:12:22 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389CLbs017250 for ; Tue, 8 Apr 2003 04:12:22 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id 3EDD3B2100 for ; Tue, 8 Apr 2003 11:12:21 +0200 (CEST) From: "Sander Striker" To: Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 11:12:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1049792463.879.33.camel@localhost> Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sanpietro.red-bean.com > [mailto:changesets-admin@sanpietro.red-bean.com]On Behalf Of Robert > Collins > Sent: Tuesday, April 08, 2003 11:01 AM ROTFL... I've subscribed yesterday, received like 40 posts already and we're already going into implementation ideas before there was time to find out if there are different visions/views on the matter. FWIW, I'm low on time this week (at least today and friday), but I'll try to squeeze in some thoughts tomorrow. Please lets try to define what a changeset is, what it should contain at a minimum and how it could be applied in two environments, one with full access to a version control systems repository and one without (ie a sourcetree without any metadata). Sander PS. The above wasn't carefully worded since I'm in a hurry... From rbcollins@cygwin.com Tue Apr 8 04:13:34 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389DXbs017269 for ; Tue, 8 Apr 2003 04:13:33 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192pAU-00037c-00; Tue, 08 Apr 2003 19:13:26 +1000 Subject: Re: Variance Adjusted Changesets From: Robert Collins To: Federico Di Gregorio Cc: changesets@sp.red-bean.com In-Reply-To: <1049792841.1023.88.camel@momo.initd.org> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> <1049792463.879.33.camel@localhost> <1049792841.1023.88.camel@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FnWt1W6inspieNjwefos" Organization: Message-Id: <1049793204.879.35.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 19:13:24 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-FnWt1W6inspieNjwefos Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 19:07, Federico Di Gregorio wrote: > > > cp arch-tree/foo eva-tree/foo > > > eva add --tag `arch get-tag arch-tree/foo` eva-tree-foo > > >=20 > > > (and the second line is not even necessary if you use embedded tags.) > >=20 > > embedded? Do you mean along the lines of the .arch-ids directories? >=20 > like arch's implicit tags. Ok. Note that .arch-ids directories also do not require the second line. Rob --=20 GPG key available at: . --=-FnWt1W6inspieNjwefos Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpK0I5+kQ8LJcoIRAsYWAKCavzBjYPxPl9QIppi2TWqI3dhXlQCeOlDZ yH6Q+QmoTEJ9m1kBVWbnfY4= =k9KG -----END PGP SIGNATURE----- --=-FnWt1W6inspieNjwefos-- From fog@initd.org Tue Apr 8 04:18:01 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389I1bs017399 for ; Tue, 8 Apr 2003 04:18:01 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 8D4253C394; Tue, 8 Apr 2003 11:03:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id A19071A2B7; Tue, 8 Apr 2003 11:16:52 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: Robert Collins Cc: changesets@sp.red-bean.com In-Reply-To: <1049793204.879.35.camel@localhost> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> <1049792463.879.33.camel@localhost> <1049792841.1023.88.camel@momo.initd.org> <1049793204.879.35.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mZD57RwrbUaCZeCxhh9x" Organization: init.d Message-Id: <1049793412.1026.96.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 11:16:52 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-mZD57RwrbUaCZeCxhh9x Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 11:13, Robert Collins ha scritto: > On Tue, 2003-04-08 at 19:07, Federico Di Gregorio wrote: >=20 >=20 > > > > cp arch-tree/foo eva-tree/foo > > > > eva add --tag `arch get-tag arch-tree/foo` eva-tree-foo > > > >=20 > > > > (and the second line is not even necessary if you use embedded tags= .) > > >=20 > > > embedded? Do you mean along the lines of the .arch-ids directories? > >=20 > > like arch's implicit tags. >=20 > Ok. Note that .arch-ids directories also do not require the second line. really? this is a little bit OT, because is arch-specific but i tought arch had a larch add command to create tag files inside .arch-ids... --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org The devil speaks truth much oftener than he's deemed. He has an ignorant audience. -- Byron (suggested by Alice Fontana) --=-mZD57RwrbUaCZeCxhh9x Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpOEvcCgrgZGjesRAt0SAJ9g8++Tdtg4uz7kqB1gCqKZV1eFQQCcDVJH t8BRwKc3u24mciArUnZMxf8= =o12O -----END PGP SIGNATURE----- --=-mZD57RwrbUaCZeCxhh9x-- From lord@emf.net Tue Apr 8 04:21:26 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389LObs017483 for ; Tue, 8 Apr 2003 04:21:25 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id CAA26460; Tue, 8 Apr 2003 02:31:11 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 02:31:11 -0700 (PDT) Message-Id: <200304080931.CAA26460@morrowfield.regexps.com> From: Tom Lord To: fog@initd.org CC: changesets@sanpietro.red-bean.com In-reply-to: <1049793103.1023.93.camel@momo.initd.org> (message from Federico Di Gregorio on 08 Apr 2003 11:11:43 +0200) Subject: Re: Variance Adjusted Changesets References: <320B1F92-69A1-11D7-AE74-000393CDF554@cse.unsw.edu.au> <1049793103.1023.93.camel@momo.initd.org> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: shouting? i use ** for emphasis; imagine me moving my hands (in tipical italian style, publicized by many hollywood movies) and putting an accent on that word. :) [...] see above, please. (and lets all think twice before starting to criticize each others writing style.) Nah.... let's all be like me and get black listed from employment over stuff like this. "Living in amerikkka..." -t From rbcollins@cygwin.com Tue Apr 8 04:22:04 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389M3bs017493 for ; Tue, 8 Apr 2003 04:22:03 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192pIh-0003Ys-00; Tue, 08 Apr 2003 19:21:55 +1000 Subject: Re: Variance Adjusted Changesets From: Robert Collins To: Federico Di Gregorio Cc: changesets@sp.red-bean.com In-Reply-To: <1049793412.1026.96.camel@momo.initd.org> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> <1049792463.879.33.camel@localhost> <1049792841.1023.88.camel@momo.initd.org> <1049793204.879.35.camel@localhost> <1049793412.1026.96.camel@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sC+/ltmS8RG91LKMJO5d" Organization: Message-Id: <1049793715.879.38.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 19:21:55 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-sC+/ltmS8RG91LKMJO5d Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 19:16, Federico Di Gregorio wrote: > > Ok. Note that .arch-ids directories also do not require the second line= . >=20 > really? this is a little bit OT, because is arch-specific but i tought > arch had a larch add command to create tag files inside .arch-ids... It is OT, and I hadn't meant to drag us into specifics, but for the use case I described (moving a *directory* from one tree to another, or even within a tree) the .arch-ids approach preserves tags perfectly. This is *because* the .arch-ids dir is within the moved dir, not external to it. Rob --=20 GPG key available at: . --=-sC+/ltmS8RG91LKMJO5d Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpSzI5+kQ8LJcoIRAoCzAKDMClXNQKtNY0ZQSEQWYBES0h5hzwCgj/ib s81d2Z9JRpeVXvlukAIXKrY= =Lpyf -----END PGP SIGNATURE----- --=-sC+/ltmS8RG91LKMJO5d-- From willu.mailingLists@cse.unsw.edu.au Tue Apr 8 04:29:29 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h389TRbs017594 for ; Tue, 8 Apr 2003 04:29:28 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Tue, 8 Apr 2003 19:29:25 +1000 From: William Uther To: Tom Lord Date: Tue, 8 Apr 2003 19:29:10 +1000 Subject: Re: Variance Adjusted Changesets Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@red-bean.com In-Reply-To: <200304080829.BAA26071@morrowfield.regexps.com> Message-Id: <8D8496C6-69A4-11D7-AE74-000393CDF554@cse.unsw.edu.au> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Tuesday, April 8, 2003, at 06:45 PM, Tom Lord wrote: >> I _think_ your "stuck" in the view of applying changesets in the >> context of repositories .... but changesets should be independent of >> repositories. > > hehe. I _think_ you're "stuck" in the view of designing > changeset formats with arch style file tags .... but changeset > formats should be independent of the tools used to generate and > apply them. :) > > I'm trying to stay open-minded to that possibility -- but so far, tags > (of which the arch mechanisms are just a subset -- they can be > expanded in some details) seem both essential and independent of rev > ctl. Certainly not essential. I have provided an example of an approach without tags. It may have or not have some other properties, but it is still an approach. I dislike it when people use absolutes (like "essential") when they don't mean it. I think you've already admitted that my approach is possible, albeit with a different set of trade-offs in terms of storage and requirements in the patch format. My apologies to Federico for overreacting to his email. Currently I see a trade off between the two approaches. Yours may be slightly more space efficient. It is slightly less tool agnostic. I'm still exploring the space... On Tuesday, April 8, 2003, at 06:29 PM, Tom Lord wrote: > (This is what I was suggesting) > [....] > > When Toom makes his local changes, renaming Baz to Bazaar, his > local editor remembers this file history. > > That's what I think is bogus about your approach. > > Toom didn't rename Baz to Bazaar -- he got a tree from someone else > who renamed Zing to Bazaar and who got their tree from someone else > who renamed Kapow to Zing who got it from someone else ...... who got > it from someone else who renamed Baz to Zowie. > > Now either the tree records the long history of those renames and each > tree has a global name (unbounded storage and the new problem of > global tree names) -- or we go with inventory tags as I've suggested > (bounded storage, no global namespace (at this level) of trees. There is no requirement in my proposal that the entire set of intermediate names Baz -> Zowie -> Kapow -> Zing -> Bazaar be stored. In some cases they may be, but all you really need is the Baz->Bazaar mapping. If you choose to remember more, fine. If not, that's fine too. On Tuesday, April 8, 2003, at 06:45 PM, Tom Lord wrote: > Does the patch apply to that version of that package? > > If so, apply your patch :) > > If not, then things get more complex... > > Were the changes from the source of the patch, ORIG, to the > tree you have, MOD, made using appropriate tools? If so, > those tools would have generated meta-data... > > Well... hmm. Multi-faceted answer. > > 1) Is that meta-data bounded or unbounded in size? Bounded means > using tags, as I've suggested -- unbounded means keeping rename > histories, as you've suggested. I don't immediately see that tags are the only way to get bounded size meta-data. I don't immediately see that deflated histories are unbounded in size. You may be right, but claiming to have the only possible algorithm for doing something is a very strong claim :). If you deflate the histories, and keep only the mapping from ORIG to MOD, then this is not unbounded in size (unless you consider really long file names). However, this does require that you map from ORIG to MOD explicitly. An advantage of tags you haven't mentioned yet is that they're not specific to particular revisions (using svn terminology here because it is easier) - you can represent many different mappings efficiently. I wonder if it is possible to get the revision invariance of tags without requiring them in the patch format? Thoughts? > 2) Using the "implicit" tagging method of arch, I don't need special > tools 99% of the time. I just use `mv(1)'. The system *must* work without implicit tags (and here I mean that this should go in the 'goals' document as a core requirement). A non-trivial chunk of the stuff I have in version control is not text. I cannot insert tags into a proprietary figure format, for example. I don't like the concept of implicit tags being in the format at all, even optionally. One solution would be to copy implicit tags into the format explicitly at patch generation time. That would allow arch to use implicit tags and not require other tools to be aware of them. Implicit tags would remain an implementation detail for some tools. > If you either didn't use the right tools, or don't have the > meta data, then neither your system nor mine will work. And without implicit tags, this comment still stands. > - The tar file should be the tree the patch was designed to be > applied to, or, > - There needs to be some extra meta-data included with the tar file > telling the patch application tools how files were moved between ORIG > and the tar file (MOD). That meta-data could be in the form of a list > of files that were renamed between ORIG and MOD (with their new names) > - intermediate renames are not neccessary. It could also be in any > one > of a number of other formats. > > Ok... that sums up your position well enough that we can refer to it. I think so, at the moment, yes. I'd like to see if there is any middle ground here. Can you get the advantages of tags without requiring them in the patch format? Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From fog@initd.org Tue Apr 8 04:39:42 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389dfbs017807 for ; Tue, 8 Apr 2003 04:39:42 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 9A3323C405; Tue, 8 Apr 2003 11:25:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id C6AD81A338; Tue, 8 Apr 2003 11:39:51 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: Robert Collins Cc: changesets@sp.red-bean.com In-Reply-To: <1049793715.879.38.camel@localhost> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> <1049792463.879.33.camel@localhost> <1049792841.1023.88.camel@momo.initd.org> <1049793204.879.35.camel@localhost> <1049793412.1026.96.camel@momo.initd.org> <1049793715.879.38.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EjfIOa5vkw9Px6UOb7kX" Organization: init.d Message-Id: <1049794791.3095.102.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 11:39:51 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-EjfIOa5vkw9Px6UOb7kX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 11:21, Robert Collins ha scritto: > On Tue, 2003-04-08 at 19:16, Federico Di Gregorio wrote: >=20 >=20 > > > Ok. Note that .arch-ids directories also do not require the second li= ne. > >=20 > > really? this is a little bit OT, because is arch-specific but i tought > > arch had a larch add command to create tag files inside .arch-ids... >=20 > It is OT, and I hadn't meant to drag us into specifics, but for the use > case I described (moving a *directory* from one tree to another, or even > within a tree) the .arch-ids approach preserves tags perfectly. yes, but what happens to the tag of the top-level directory you're moving? mm.. maybe it is inside the .arch-ids inside that directory? i don't remember... --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org 99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me --=-EjfIOa5vkw9Px6UOb7kX Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpjnvcCgrgZGjesRAv9lAJ9aFAnkTRShGItD4HiGFdQwYoaOAACeKqeI 5HM2a1BgzqpQyA7hgqEHzOs= =3AbM -----END PGP SIGNATURE----- --=-EjfIOa5vkw9Px6UOb7kX-- From rbcollins@cygwin.com Tue Apr 8 04:44:05 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389i4bs017916 for ; Tue, 8 Apr 2003 04:44:04 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192pe0-0004Hi-00; Tue, 08 Apr 2003 19:43:56 +1000 Subject: Re: Variance Adjusted Changesets From: Robert Collins To: Federico Di Gregorio Cc: changesets@sp.red-bean.com In-Reply-To: <1049794791.3095.102.camel@momo.initd.org> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <200304080459.VAA25317@morrowfield.regexps.com> <1049787175.1023.18.camel@momo.initd.org> <1049789315.893.29.camel@localhost> <1049789961.1023.45.camel@momo.initd.org> <1049790175.893.31.camel@localhost> <1049792061.1023.81.camel@momo.initd.org> <1049792463.879.33.camel@localhost> <1049792841.1023.88.camel@momo.initd.org> <1049793204.879.35.camel@localhost> <1049793412.1026.96.camel@momo.initd.org> <1049793715.879.38.camel@localhost> <1049794791.3095.102.camel@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MLGXwddHyioOPnKhvoTw" Organization: Message-Id: <1049795035.893.40.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 19:43:55 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-MLGXwddHyioOPnKhvoTw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 19:39, Federico Di Gregorio wrote: > yes, but what happens to the tag of the top-level directory you're > moving? mm.. maybe it is inside the .arch-ids inside that directory?=20 Ack. Rob --=20 GPG key available at: . --=-MLGXwddHyioOPnKhvoTw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kpnbI5+kQ8LJcoIRAvuAAKCj95m+GIsxX2lzCmmoslVnKYj9+gCeNKky +Si135fb2DwqZGncLujKwu4= =SGjg -----END PGP SIGNATURE----- --=-MLGXwddHyioOPnKhvoTw-- From lars.segerlund@comsys.se Tue Apr 8 04:49:21 2003 Received: from kanga.comsys.se (gw.comsys.ideon.se [62.95.120.145]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389nKbs017984 for ; Tue, 8 Apr 2003 04:49:21 -0500 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by kanga.sys.energyx.se (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h389nIgf001814 for ; Tue, 8 Apr 2003 11:49:20 +0200 Message-ID: <3E929B1D.3080306@comsys.se> Date: Tue, 08 Apr 2003 11:49:17 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: changesets@sanpietro.red-bean.com Subject: Re: Variance Adjusted Changesets References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: This I agree with, I find it more relevant to define what were talking about and what we want to accomplish before going into implementation details. If we get this functionality right we might be able to provide some glue between different versioning systems, and quite probably some functionality which they might embed. In order to succeed we might try to work out what approaches are likely not to be considered for use by other projects. So I think a discussion about the targets might be more relevant. Also, in this discussion there would be quite a lot of room for making some testcases, in this way everybody can refer to a common set of cases and a specific case in an discussion. This would require a set of different situations, where code is checked out from a common source and revision, common source but different revisions and of course source with commaon ancestry but from different sources, and finally stuff like the 'three way merge' and other challenges. So let's define what we need and how it can be done berore we run off in different directions ? It's easy to shoot of opinions, but hard to cooperate :-) .. / regards, Lars Segerlund. Sander Striker wrote: >>From: changesets-admin@sanpietro.red-bean.com >>[mailto:changesets-admin@sanpietro.red-bean.com]On Behalf Of Robert >>Collins >>Sent: Tuesday, April 08, 2003 11:01 AM > > > ROTFL... I've subscribed yesterday, received like 40 posts already > and we're already going into implementation ideas before there was > time to find out if there are different visions/views on the matter. > > FWIW, I'm low on time this week (at least today and friday), but > I'll try to squeeze in some thoughts tomorrow. Please lets try > to define what a changeset is, what it should contain at a minimum > and how it could be applied in two environments, one with full access > to a version control systems repository and one without (ie a sourcetree > without any metadata). > > Sander > > PS. The above wasn't carefully worded since I'm in a hurry... > > _______________________________________________ > Changesets mailing list > Changesets@sp.red-bean.com > http://www.red-bean.com/mailman/listinfo/changesets > From lord@emf.net Tue Apr 8 04:52:36 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389qXbs018111 for ; Tue, 8 Apr 2003 04:52:34 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id DAA26645; Tue, 8 Apr 2003 03:02:20 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 03:02:20 -0700 (PDT) Message-Id: <200304081002.DAA26645@morrowfield.regexps.com> From: Tom Lord To: willu.mailingLists@cse.unsw.edu.au CC: changesets@red-bean.com In-reply-to: <8D8496C6-69A4-11D7-AE74-000393CDF554@cse.unsw.edu.au> (message from William Uther on Tue, 8 Apr 2003 19:29:10 +1000) Subject: Re: Variance Adjusted Changesets References: <8D8496C6-69A4-11D7-AE74-000393CDF554@cse.unsw.edu.au> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I dislike it when people use absolutes (like "essential") when they don't mean it. Oh I meant it. I do presume that it's ok to use absolutes when talking about practical approaches. Currently I see a trade off between the two approaches. Yours may be slightly more space efficient. It is slightly less tool agnostic. I'm still exploring the space... Fair enough. There is no requirement in my proposal that the entire set of intermediate names Baz -> Zowie -> Kapow -> Zing -> Bazaar be stored. Which of those intermediate states might the changeset treat as ORIG? In some cases they may be, but all you really need is the Baz->Bazaar Only that one? Are the trees in which Bazaar was called Baz the only permissable ORIGs? I don't immediately see that tags are the only way to get bounded size meta-data. I don't immediately see that deflated histories are unbounded in size. You may be right, but claiming to have the only possible algorithm for doing something is a very strong claim :). Please don't put words in my mouth. > 2) Using the "implicit" tagging method of arch, I don't need special > tools 99% of the time. I just use `mv(1)'. The system *must* work without implicit tags (and here I mean that this should go in the 'goals' document as a core requirement). A non-trivial chunk of the stuff I have in version control is not text. I cannot insert tags into a proprietary figure format, for example. Then use something equal or similar to arch's "explicit" inventory tags, but then you can't use `mv(1)'. I don't like the concept of implicit tags being in the format at all, even optionally. Why? When the data, typically source files, makes them practical -- it's a very convenient approach. > If you either didn't use the right tools, or don't have the > meta data, then neither your system nor mine will work. And without implicit tags, this comment still stands. Yes.... logical file identity, one way or another, requires some new mechanism. For source files, implicit tagging happens to be a very convenient mechanism that disrupts other tools, like `mv(1)', very little. I'd like to see if there is any middle ground here. Can you get the advantages of tags without requiring them in the patch format? I don't see how, unless you require space-unbounded meta-data or a repository connection for every patched tree. -t From lord@emf.net Tue Apr 8 04:55:14 2003 Received: from morrowfield.regexps.com (11Cust146.tnt13.sfo8.da.uu.net [65.234.195.146]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h389tCbs018179 for ; Tue, 8 Apr 2003 04:55:13 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id DAA26692; Tue, 8 Apr 2003 03:04:55 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 03:04:55 -0700 (PDT) Message-Id: <200304081004.DAA26692@morrowfield.regexps.com> From: Tom Lord To: lars.segerlund@comsys.se CC: changesets@sanpietro.red-bean.com In-reply-to: <3E929B1D.3080306@comsys.se> (message from Lars Segerlund on Tue, 08 Apr 2003 11:49:17 +0200) Subject: Re: Variance Adjusted Changesets References: <3E929B1D.3080306@comsys.se> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: So let's define what we need and how it can be done berore we run off in different directions ? It's easy to shoot of opinions, but hard to cooperate :-) .. Logical file identities is a good place to start. >From there, we can actually talk about tree rearrangements and imprecise patching. After that, it's a cake walk. -t From fog@initd.org Tue Apr 8 05:13:40 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38ADebs018567 for ; Tue, 8 Apr 2003 05:13:40 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id E4AF93C0EC; Tue, 8 Apr 2003 11:59:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 1F8FE1A338 for ; Tue, 8 Apr 2003 12:12:16 +0200 (CEST) Subject: Re: Variance Adjusted Changesets From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <3E929B1D.3080306@comsys.se> References: <3E929B1D.3080306@comsys.se> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xmqgGhlGHK2h7rKUeuwF" Organization: init.d Message-Id: <1049796735.3095.131.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 12:12:16 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-xmqgGhlGHK2h7rKUeuwF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 11:49, Lars Segerlund ha scritto: > This I agree with, I find it more relevant to define what were talking=20 > about and what we want to accomplish before going into implementation=20 > details. agreed. > Also, in this discussion there would be quite a lot of room for making=20 > some testcases, in this way everybody can refer to a common set of cases=20 > and a specific case in an discussion. This would require a set of=20 > different situations, where code is checked out from a common source and=20 > revision, common source but different revisions and of course source=20 > with commaon ancestry but from different sources, and finally stuff like=20 > the 'three way merge' and other challenges. >=20 > So let's define what we need and how it can be done berore we run off=20 > in different directions ? It's easy to shoot of opinions, but hard to=20 > cooperate :-) .. ok. here is what i would like to see discussed on this list: 1) Requirement for system-independent patch sets; i.e., a) what we want to put in a patch set? b) do we need logical tags? c) how do we save meta-information related to (a,b)? d) what files should be added to a project tree, if any? 2) how to integrate generic patches in specific SCMS a) do patch sets need to be versioned? b) how to relate such versions to arch|svn|... versions? 3) interoperability tools between different systems i'll try to answer to (1) in this mail: a) i'd like to have: - file metadata changes (mode, owner, group at minimum, but an extenisble mechanism would me much better) - rename & delta operations on files, symlinks, directories b) we at least need logical names (if you don't like the term "tag"); physical paths are not enough to do inexact patching mixing renames & delta operations. what we can explore is where/how to save that information. i still don't exactly about (c,d) but i think that a couple of files (or a dir full of files) with a very well defined format added to the tree is acceptable. i think leaving sources untouched will be very difficult. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-xmqgGhlGHK2h7rKUeuwF Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kqB/vcCgrgZGjesRAs5lAJ9U65EvgIqc59n8UrWQ7lhQzaZTCACfVlrC 2wwmpSOg0FaY2lkxvGhWXkg= =RE8Z -----END PGP SIGNATURE----- --=-xmqgGhlGHK2h7rKUeuwF-- From striker@apache.org Tue Apr 8 05:14:44 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38AEhbs018596 for ; Tue, 8 Apr 2003 05:14:44 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id E032511A32B; Tue, 8 Apr 2003 12:14:42 +0200 (CEST) From: "Sander Striker" To: "Tom Lord" Cc: Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 12:14:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200304081004.DAA26692@morrowfield.regexps.com> Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sanpietro.red-bean.com > [mailto:changesets-admin@sanpietro.red-bean.com]On Behalf Of Tom Lord > Sent: Tuesday, April 08, 2003 12:05 PM > So let's define what we need and how it can be done berore we > run off in different directions ? It's easy to shoot of > opinions, but hard to cooperate :-) .. > > > Logical file identities is a good place to start. I disagree. They aren't required for a minimal changeset. > From there, we can actually talk about tree rearrangements and > imprecise patching. Logical file identities are only needed for just that, imprecise patching. I'm willing to argue that you will never _have_ to patch imprecisely. This is only needed in the scenario where you don't have (read) access to the repository. > After that, it's a cake walk. *grin*, you aren't forgetting about implementation, are you? ;) :) Sander From fog@initd.org Tue Apr 8 05:23:40 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38ANdbs018769 for ; Tue, 8 Apr 2003 05:23:40 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id D1C8F3C0EC; Tue, 8 Apr 2003 12:09:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 2D5511A338 for ; Tue, 8 Apr 2003 12:22:32 +0200 (CEST) Subject: RE: Variance Adjusted Changesets From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3tKztzwWNoIJunNhWmvO" Organization: init.d Message-Id: <1049797351.1026.139.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 12:22:32 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-3tKztzwWNoIJunNhWmvO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 12:14, Sander Striker ha scritto: > > From: changesets-admin@sanpietro.red-bean.com > > [mailto:changesets-admin@sanpietro.red-bean.com]On Behalf Of Tom Lord > > Sent: Tuesday, April 08, 2003 12:05 PM >=20 > > So let's define what we need and how it can be done berore we > > run off in different directions ? It's easy to shoot of > > opinions, but hard to cooperate :-) .. > >=20 > >=20 > > Logical file identities is a good place to start. >=20 > I disagree. They aren't required for a minimal changeset. > =20 > > From there, we can actually talk about tree rearrangements and > > imprecise patching. >=20 > Logical file identities are only needed for just that, imprecise > patching. I'm willing to argue that you will never _have_ to > patch imprecisely. This is only needed in the scenario where > you don't have (read) access to the repository. mm.. i don't understand you here. every time you update your working tree from last commited version you're doing inexact patching. inexact patching is the most common operation when 2 or more developers work on the same branch concurrently. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Those who do not study Lisp are doomed to reimplement it. Poorly. -- from Karl M. Hegbloom .signature --=-3tKztzwWNoIJunNhWmvO Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kqLnvcCgrgZGjesRAoRvAJ9FeJo7MJmzQBFea4Fkf6QBt6lMkQCfTuFn pNSM+YLmuexBOi6ILHVY7EI= =hDUF -----END PGP SIGNATURE----- --=-3tKztzwWNoIJunNhWmvO-- From rbcollins@cygwin.com Tue Apr 8 05:30:35 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38AUXbs018950 for ; Tue, 8 Apr 2003 05:30:34 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192qMy-0007PH-00; Tue, 08 Apr 2003 20:30:24 +1000 Subject: RE: Variance Adjusted Changesets From: Robert Collins To: Sander Striker Cc: Tom Lord , changesets@sanpietro.red-bean.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Zt3f+xpwPPM3bWYeH50O" Organization: Message-Id: <1049797820.878.49.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 20:30:20 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-Zt3f+xpwPPM3bWYeH50O Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 20:14, Sander Striker wrote: > > From there, we can actually talk about tree rearrangements and > > imprecise patching. >=20 > Logical file identities are only needed for just that, imprecise > patching. I'm willing to argue that you will never _have_ to > patch imprecisely. This is only needed in the scenario where > you don't have (read) access to the repository. Err. Given full access to repositories, how does this situation get addressed without logical file identities? Consider the following trees: ORIG / \ A B in B, I rename a file Foo to Foo'. in A a different file rename occurs to the same Foo resulting in Foo''. Now, whichever of A or B is applied to ORIG first (i.e. a checkin to the RCS system occurs) will cause conflicting tree rearrangements. For example, if A gets applied to ORIG, to get those changes in B requires renaming Foo (which doesn't physically exist) to Foo''. Now, local rename history can tell someone with tree B that Foo has been renamed to Foo''. However, I'd argue that file rename history is a form of logical file identity - and thus logical file identification is not needed 'just for imprecise patching'. Rob --=20 GPG key available at: . --=-Zt3f+xpwPPM3bWYeH50O Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kqS8I5+kQ8LJcoIRApciAJ98WKkqdhP0NJTy1DbHurPHH81+gQCdGLVG NskyYZfK3fHcZy4eQReP4xA= =Awh4 -----END PGP SIGNATURE----- --=-Zt3f+xpwPPM3bWYeH50O-- From striker@apache.org Tue Apr 8 05:31:10 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38AV9bs018974 for ; Tue, 8 Apr 2003 05:31:09 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id B07BB93331; Tue, 8 Apr 2003 12:31:08 +0200 (CEST) From: "Sander Striker" To: "Federico Di Gregorio" , Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 12:31:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1049797351.1026.139.camel@momo.initd.org> Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sp.red-bean.com > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Federico Di > Gregorio > Sent: Tuesday, April 08, 2003 12:23 PM [...] >> Logical file identities are only needed for just that, imprecise >> patching. I'm willing to argue that you will never _have_ to >> patch imprecisely. This is only needed in the scenario where >> you don't have (read) access to the repository. > > mm.. i don't understand you here. every time you update your working > tree from last commited version you're doing inexact patching. inexact > patching is the most common operation when 2 or more developers work on > the same branch concurrently. Ok, let me rephrase, you never have to apply the _external_ patch inexactly. I am referring to the human readable things people post to mailinglists. Internally you do something equivalent to a merge yes, and that is inexact, but here you have access to all sources so you won't have to rely on doing inexact patching by having the context untouched. Anyhow, I don't have time to go into this right now, but I will try to find the time to do so later on this week. Sander From striker@apache.org Tue Apr 8 05:34:39 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38AYcbs019008 for ; Tue, 8 Apr 2003 05:34:38 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id 2AF8193331; Tue, 8 Apr 2003 12:34:38 +0200 (CEST) From: "Sander Striker" To: "Robert Collins" Cc: Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 12:34:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1049797820.878.49.camel@localhost> Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Robert Collins [mailto:rbcollins@cygwin.com] > Sent: Tuesday, April 08, 2003 12:30 PM > On Tue, 2003-04-08 at 20:14, Sander Striker wrote: > > > > > From there, we can actually talk about tree rearrangements and > > > imprecise patching. > > > > Logical file identities are only needed for just that, imprecise > > patching. I'm willing to argue that you will never _have_ to > > patch imprecisely. This is only needed in the scenario where > > you don't have (read) access to the repository. > > Err. Given full access to repositories, how does this situation get > addressed without logical file identities? Because you know against what revision of the source tree the patch was made. You can then travel down from that revision to your local revision collecting moves, copies, deletes, additions etc. The logical identity is implicitly defined by its path and its revision. Sander From rbcollins@cygwin.com Tue Apr 8 05:42:03 2003 Received: from lifelesslap.robertcollins.net (CPE-144-137-125-98.nsw.bigpond.net.au [144.137.125.98]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38Ag2bs019174 for ; Tue, 8 Apr 2003 05:42:02 -0500 Received: from localhost ([127.0.0.1] ident=robertc) by lifelesslap.robertcollins.net with esmtp (Exim 3.36 #1 (Debian)) id 192qY8-0007Tl-00; Tue, 08 Apr 2003 20:41:56 +1000 Subject: RE: Variance Adjusted Changesets From: Robert Collins To: Sander Striker Cc: changesets@sanpietro.red-bean.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2uRUvI/4U4vN76LExHaN" Organization: Message-Id: <1049798515.878.51.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 20:41:55 +1000 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-2uRUvI/4U4vN76LExHaN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2003-04-08 at 20:34, Sander Striker wrote: > Because you know against what revision of the source tree the patch > was made. You can then travel down from that revision to your local > revision collecting moves, copies, deletes, additions etc. The > logical identity is implicitly defined by its path and its revision. I'm confused, you seem to be saying that logical identity *does matter*. That was my point, that logical identity is a good starting point. Rob --=20 GPG key available at: . --=-2uRUvI/4U4vN76LExHaN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kqdzI5+kQ8LJcoIRAkQSAKCFtNqfNkG0Ihh/qdQoB506uIN4zQCfZG+y Nc8PITvKXiiXDZc8X5QU76I= =rpeS -----END PGP SIGNATURE----- --=-2uRUvI/4U4vN76LExHaN-- From lars.segerlund@comsys.se Tue Apr 8 06:21:56 2003 Received: from kanga.comsys.se (gw.comsys.ideon.se [62.95.120.145]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38BLsbs019918 for ; Tue, 8 Apr 2003 06:21:55 -0500 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by kanga.sys.energyx.se (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h38BLXgf002405 for ; Tue, 8 Apr 2003 13:21:51 +0200 Message-ID: <3E92B0BD.4040204@comsys.se> Date: Tue, 08 Apr 2003 13:21:33 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: changesets@sanpietro.red-bean.com Subject: Re: Variance Adjusted Changesets References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> In-Reply-To: <1049796735.3095.131.camel@momo.initd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I would like to add poit 0 to the below list. 0. How do we represent a local repository ? Or is this necessary for our purposes ? My thoughts here is that if a user want's to check out from a versioning system with a central repository, we should provide a local one, I think subvesion is the system which has the 'best' model for this of the systems under discussion on this list. So if we first specify what we want to have in our local repository, and keep it flexible enough we can do all of the proposed approaches later. Thus how do we organize this ? I have the suggestion of using berkeley db since it's fun :-) ... or a similar approach, this should make it fast and flexible. Basicly I am thinking of doing a checkout, and then bringing the checked out copy into local revision handling, thus faciliating branching and tagging at the local level. A mechanism to 'switch' branch, tag or context would also be nice. There are three options here which I think is interesting to support, a per system repository with user access, a per user repository and a per 'checked out copy' or project repository model. Any thoughts ? btw. with regards to point 2 and 3 below, there is cvsps ( cvs patch set ) and some other tools for similar functionality for most existing systems. / Lars Segerlund. Federico Di Gregorio wrote: > Il mar, 2003-04-08 alle 11:49, Lars Segerlund ha scritto: > >> This I agree with, I find it more relevant to define what were talking >>about and what we want to accomplish before going into implementation >>details. > > > agreed. > > >> Also, in this discussion there would be quite a lot of room for making >>some testcases, in this way everybody can refer to a common set of cases >> and a specific case in an discussion. This would require a set of >>different situations, where code is checked out from a common source and >>revision, common source but different revisions and of course source >>with commaon ancestry but from different sources, and finally stuff like >>the 'three way merge' and other challenges. >> >> So let's define what we need and how it can be done berore we run off >>in different directions ? It's easy to shoot of opinions, but hard to >>cooperate :-) .. > > > ok. here is what i would like to see discussed on this list: > > 1) Requirement for system-independent patch sets; i.e., > a) what we want to put in a patch set? > b) do we need logical tags? > c) how do we save meta-information related to (a,b)? > d) what files should be added to a project tree, if any? > > 2) how to integrate generic patches in specific SCMS > a) do patch sets need to be versioned? > b) how to relate such versions to arch|svn|... versions? > > 3) interoperability tools between different systems > > i'll try to answer to (1) in this mail: > > a) i'd like to have: > > - file metadata changes (mode, owner, group at minimum, but an > extenisble mechanism would me much better) > > - rename & delta operations on files, symlinks, directories > > b) we at least need logical names (if you don't like the term "tag"); > physical paths are not enough to do inexact patching mixing renames & > delta operations. what we can explore is where/how to save that > information. > > i still don't exactly about (c,d) but i think that a couple of files (or > a dir full of files) with a very well defined format added to the tree > is acceptable. i think leaving sources untouched will be very difficult. > From striker@apache.org Tue Apr 8 06:31:40 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38BVdbs020253 for ; Tue, 8 Apr 2003 06:31:40 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id 1607DD023F for ; Tue, 8 Apr 2003 13:31:39 +0200 (CEST) From: "Sander Striker" To: Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 13:31:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1049798515.878.51.camel@localhost> Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sp.red-bean.com > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Robert Collins > Sent: Tuesday, April 08, 2003 12:42 PM > On Tue, 2003-04-08 at 20:34, Sander Striker wrote: > >> Because you know against what revision of the source tree the patch >> was made. You can then travel down from that revision to your local >> revision collecting moves, copies, deletes, additions etc. The >> logical identity is implicitly defined by its path and its revision. > > I'm confused, you seem to be saying that logical identity *does matter*. > > That was my point, that logical identity is a good starting point. Ok, let me put it this way: Person A sends in a patch P. He mentions this patch was against version x.y.z of the source tree. Person B picks up the patch. If he wants to apply it to his local tree, he can, but it won't be as acurate as applying it to x.y.z and then doing a (history sensitive) merge of the result between his local tree, x.y.z and the (x.y.z + P). The first case, applying to the local tree doesn't require logical identities other than paths. It isn't 100% accurate, but will work for the simple cases (for example when the local tree doesn't have any changes against x.y.z that P has aswell). This particular case is trial and error patching. It might work, it might not. Just like we have nowadays with diff/patch: if both parties are not working against the same revision, there _might_ be a conflict. The second case requires knowledge that the patch was created against x.y.z. Now you have implicit logical file identities, which don't ever need to be exposed. OT: I'm probably going to propose that Subversions patch command[TBD] will try and do the second approach if the optional version information is present in a 'patch', fall back to the first approach (possibly prompting for the version the patch was made against). Back to the issue at hand. I personally don't think that logical file ids are a primary requirement for a changeset format, given the above. Sander From striker@apache.org Tue Apr 8 06:41:41 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38Bffbs020597 for ; Tue, 8 Apr 2003 06:41:41 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id B0F3DD023F for ; Tue, 8 Apr 2003 13:41:40 +0200 (CEST) From: "Sander Striker" To: Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 13:41:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sp.red-bean.com > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Sander Striker > Sent: Tuesday, April 08, 2003 1:32 PM [...] > Person A sends in a patch P. He mentions this patch was against > version x.y.z of the source tree. > > Person B picks up the patch. If he wants to apply it to his local > tree, he can, but it won't be as acurate as applying it to x.y.z > and then doing a (history sensitive) merge of the result between > his local tree, x.y.z and the (x.y.z + P). > > The first case, applying to the local tree doesn't require logical > identities other than paths. It isn't 100% accurate, but will work > for the simple cases (for example when the local tree doesn't have > any changes against x.y.z that P has aswell). This particular case > is trial and error patching. It might work, it might not. Just like > we have nowadays with diff/patch: if both parties are not working > against the same revision, there _might_ be a conflict. Should have said there may be a 'false' conflict. Or it might apply and you 'miss' a conflict. The second approach produces accurate conflicts, if any. Sander From pasky@machine.sinus.cz Tue Apr 8 07:30:09 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h38CU8bs021547 for ; Tue, 8 Apr 2003 07:30:08 -0500 Received: (qmail 28555 invoked by uid 2001); 8 Apr 2003 12:30:06 -0000 Date: Tue, 8 Apr 2003 14:30:06 +0200 From: Petr Baudis To: William Uther Cc: changesets@red-bean.com Subject: Re: Variance Adjusted Changesets Message-ID: <20030408123006.GD3037@pasky.ji.cz> References: <0125649A-696E-11D7-AE74-000393CDF554@cse.unsw.edu.au> <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486AEE82-6997-11D7-AE74-000393CDF554@cse.unsw.edu.au> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Tue, Apr 08, 2003 at 09:54:10AM CEST, I got a letter, where William Uther told me, that... > Let me try this again.... > > I'm going to assume that two people, Quux and Toom, both have a > directory tree called ORIG: > > foo > / \ > Bar Baz > > Where foo is a dir and Bar and Baz are files. > > > Quux changes the directory tree, renaming Bar to Pub and editing Baz. > We will call this new tree MOD-Q. > > Toom also changes his directory tree, renaming Baz to Bazaar and > editing it slightly. We will call this new tree MOD-T. Fine. > ----- Option 1: file tags ----- > > (This is my understanding of what you are suggesting) > > We assign tags to each of the files in ORIG: > > foo: 1 > Bar: 2 > Baz: 3 There was also some discussion about how to generate the id. I've outlined some approach in an earlier mail, but looks like some people weren't subscribed yet. There must be a per-file unique id and the id must be reasonably unique. Let's also assume that you need anyway a method to uniquely mark changesets, to refer to them reliably in a distributed environment. I won't go into detail about how to exactly mark them, let's say that we should include author of the changeset (ie. pasky@ucw.cz), changeset commit time (ie. 1049804425) and some third value variable enough (from pid of the process to changeset checksum). Each file is introduced in some changeset, and we have also unique changeset id available, so we can use it as a base. Multiple files can be introduced in one changeset but none two files in that set may share one name. Thus a file name in the changeset scope is unique, and a changeset id in the global scope is unique as well. Thus a file id constructed from changeset id (of its introduction) and the original file name (at the time of introduction) is unique as well. > The patch file specifies changes in terms of those tags. For example, > if Quux were to "mkPatch ORIG MOD-Q" then you might get the following > output: > > ---- begin patch ---- > Rename 2: foo/Bar -> foo/Pub > Edit 3: make changes to foo/Baz > ---- end patch ---- > > When Toom makes his local changes, renaming Baz to Bazaar, the tag, 3, > is preserved. Thus when Toom applies Quux's patch, Quux's edits to Baz > can be made to Bazaar (assuming no conflicts with Toom's changes to the > same file). > > Note that this makes the tags explicit in the patch format, and hence > requires that all tools using the patch format think about tags in the > same way. They must regard file id (tag) as a way to uniquely identify a file, that hopefully shouldn't be such a big problem. And that is all they need to do, the unique id format they use internally does not need to be specified, it's only important to keep the almost-unique property. Anyway, a current file name the operation is done upon should be always included near the file tag, so that we can still have a possibility to recover (unless file renaming happenned, but you can't help everyone ;-) from a situation when: 1, We try to apply a patch upon non-versioned copy of the file. 2, There was a "blackhole" between the original repository and the current repository, ie. the data were transmitted in a non-versioned way. 3, Something on the way screwed the tag up. > It also requires that any tools Toom uses to make his local changes preserve > tags correctly. Yes. > ----- Option 2: directory tags ----- > > (This is what I was suggesting) > > We assign a tag to the original tree: ORIG. > > The patch file describes changes relative to the root of that tree tag. > For example, if Quux were to "mkPatch ORIG MOD-Q" then you might get > the following output: > > ---- begin patch ---- > Patch tree ORIG. > Rename: foo/Bar -> foo/Pub > Edit: make changes to foo/Baz > ---- end patch ---- > > When Toom makes his local changes, renaming Baz to Bazaar, his local > editor remembers this file history. It could be remembered either > explicitly, as a list of renames, or in the form of local file tags. > > When Toom applies Quux's patch, the patch specifies the original tree > ORIG. Toom's patch applicator can now trace what happened to Baz in > the local copy, and apply the edits to Bazaar (again, assuming no > conflicts with Toom's changes to the same file). > > This requires a global namespace for directory trees. It requires that > Toom's system have some way of keeping track of change history - either > as an explicit history or as file tags. It does NOT require that all > tools using the changeset format think about file tags in the same way. This relies on a fact that you have available the complete history of renames, which can be frequently very impractical. Also, I somehow miss the "ORIG" definition. How do you compose id of a patch tree? It pretty much boils down again to some method for determining of a unique id. > ----- Option 3: file similarity numbering ----- ..snip.. Well, it could be a possibility, but I think it would be an overkill. And what would happen if you massively restructure a file, or rewrite it? Overally, I believe it is not much practical. Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From florin@iucha.net Tue Apr 8 08:34:38 2003 Received: from mail.iucha.net (foobar@iucha.net [209.98.146.184]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38DYbbs023047 for ; Tue, 8 Apr 2003 08:34:38 -0500 Received: by mail.iucha.net (Postfix, from userid 1000) id 719481805D7; Tue, 8 Apr 2003 08:34:36 -0500 (CDT) Date: Tue, 8 Apr 2003 08:34:36 -0500 To: Lars Segerlund Cc: changesets@sanpietro.red-bean.com Subject: Re: Variance Adjusted Changesets Message-ID: <20030408133436.GA11307@iucha.net> References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> <3E92B0BD.4040204@comsys.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <3E92B0BD.4040204@comsys.se> X-message-flag: Outlook: Where do you want [your files] to go today? X-gpg-key: http://iucha.net/florin_iucha.gpg X-gpg-fingerprint: 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 User-Agent: Mutt/1.5.3i From: florin@iucha.net (Florin Iucha) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 08, 2003 at 01:21:33PM +0200, Lars Segerlund wrote: >=20 > I would like to add poit 0 to the below list. >=20 > 0. How do we represent a local repository ? Or is this necessary for=20 > our purposes ? >=20 > My thoughts here is that if a user want's to check out from a=20 > versioning system with a central repository, we should provide a local=20 > one, I think subvesion is the system which has the 'best' model for this= =20 > of the systems under discussion on this list. >=20 > So if we first specify what we want to have in our local repository,=20 > and keep it flexible enough we can do all of the proposed approaches late= r. >=20 > Thus how do we organize this ? >=20 > I have the suggestion of using berkeley db since it's fun :-) ... or a= =20 > similar approach, this should make it fast and flexible. Hmmm. > Basicly I am thinking of doing a checkout, and then bringing the=20 > checked out copy into local revision handling, thus faciliating=20 > branching and tagging at the local level. A mechanism to 'switch'=20 > branch, tag or context would also be nice. >=20 > There are three options here which I think is interesting to support,=20 > a per system repository with user access, a per user repository and a=20 > per 'checked out copy' or project repository model. All the three options can be reduced to one: distributed repositories. Then you'll have master-slave/peer-to-peer/project based/developer owned repositories. You can do arbitrarily merges up and down (or left and right). You can have arbitrarily amounts of history "near" you, but not in your working copy. florin --=20 "NT is to UNIX what a doughnut is to a particle accelerator." --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ks/sNLPgdTuQ3+QRAlXHAJ9T1sXcyl6N30BYnoT8o1AuGsAWGgCfXwmL LiJWgKLYMpCLLDAdFUQ0l8E= =8Rrt -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From striker@apache.org Tue Apr 8 08:51:17 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38DpGbs023593 for ; Tue, 8 Apr 2003 08:51:16 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id 5E432B2100 for ; Tue, 8 Apr 2003 15:51:15 +0200 (CEST) From: "Sander Striker" To: Subject: RE: Variance Adjusted Changesets Date: Tue, 8 Apr 2003 15:51:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030408133436.GA11307@iucha.net> Importance: Normal Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sp.red-bean.com > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Florin Iucha > Sent: Tuesday, April 08, 2003 3:35 PM > On Tue, Apr 08, 2003 at 01:21:33PM +0200, Lars Segerlund wrote: >> >> I would like to add poit 0 to the below list. >> >> 0. How do we represent a local repository ? We don't. >> Or is this necessary for our purposes ? No. It has nothing to do with comming up with a changeset format that every other version control system is able to process. >> My thoughts here is that if a user want's to check out from a >> versioning system with a central repository, we should provide a local >> one, Why? For people working with a central repository they rely on that central repository to be available. No need to duplicate locally other than for optimization (and opening a can of worms when it comes to access control and what not...). >> I think subvesion is the system which has the 'best' model for this >> of the systems under discussion on this list. Wrt having a central repository? >> So if we first specify what we want to have in our local repository, >> and keep it flexible enough we can do all of the proposed approaches later. >> >> Thus how do we organize this ? >> >> I have the suggestion of using berkeley db since it's fun :-) ... or a >> similar approach, this should make it fast and flexible. Yes, fun on NFS... > Hmmm. > >> Basicly I am thinking of doing a checkout, and then bringing the >> checked out copy into local revision handling, thus faciliating >> branching and tagging at the local level. A mechanism to 'switch' >> branch, tag or context would also be nice. >> >> There are three options here which I think is interesting to support, >> a per system repository with user access, a per user repository and a >> per 'checked out copy' or project repository model. > > All the three options can be reduced to one: distributed repositories. Exactly. And that has nothing to do with defining what a changeset should look like. Sander From lars.segerlund@comsys.se Tue Apr 8 08:53:04 2003 Received: from kanga.comsys.se (gw.comsys.ideon.se [62.95.120.145]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38Dr3bs023633 for ; Tue, 8 Apr 2003 08:53:03 -0500 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by kanga.sys.energyx.se (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h38Dr1gf003293 for ; Tue, 8 Apr 2003 15:53:02 +0200 Message-ID: <3E92D43D.10201@comsys.se> Date: Tue, 08 Apr 2003 15:53:01 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: changesets@sanpietro.red-bean.com Subject: Distributed repositories References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> <3E92B0BD.4040204@comsys.se> <20030408133436.GA11307@iucha.net> In-Reply-To: <20030408133436.GA11307@iucha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Thanks, you said it a lot better than me. I think that the real 'pudels kern' is that distributed repositories is missing from a lot of free tools such as cvs, subversion and so on. Thus I believe that this is the first target to strive for, since patchsets are but a complement to distributed repositories, ( It is however essential, and I think necessary for them ). any takers ? Florin Iucha wrote: > On Tue, Apr 08, 2003 at 01:21:33PM +0200, Lars Segerlund wrote: snip ... > > Hmmm. > snip ... > > All the three options can be reduced to one: distributed repositories. > Then you'll have master-slave/peer-to-peer/project based/developer owned > repositories. You can do arbitrarily merges up and down (or left and > right). You can have arbitrarily amounts of history "near" you, but > not in your working copy. > > florin > From pasky@machine.sinus.cz Tue Apr 8 09:50:43 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h38Eofbs025322 for ; Tue, 8 Apr 2003 09:50:42 -0500 Received: (qmail 1827 invoked by uid 2001); 8 Apr 2003 14:50:40 -0000 Date: Tue, 8 Apr 2003 16:50:40 +0200 From: Petr Baudis To: Lars Segerlund Cc: changesets@sanpietro.red-bean.com Subject: Our goals Message-ID: <20030408145039.GF3037@pasky.ji.cz> References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> <3E92B0BD.4040204@comsys.se> <20030408133436.GA11307@iucha.net> <3E92D43D.10201@comsys.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E92D43D.10201@comsys.se> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Tue, Apr 08, 2003 at 03:53:01PM CEST, I got a letter, where Lars Segerlund told me, that... > > Thanks, you said it a lot better than me. > > I think that the real 'pudels kern' is that distributed repositories > is missing from a lot of free tools such as cvs, subversion and so on. > > Thus I believe that this is the first target to strive for, since > patchsets are but a complement to distributed repositories, ( It is > however essential, and I think necessary for them ). What are we trying to define? I understand that it is just sort of a smarter patch, with ability to losslessly carry some extended information, which cannot be represented in the standard patch format. What is the extended information to be provided? In short, I think we can simply say "metadata". Longer reply could be: 1, File attributes: - existence (created/removed, could be possibly bundled with name, name being an empty string) - name - tag (file id, if decided that it is desirable to carry) - type (symlink? directory? *XYZ*?) - mode - ownership (not sure if that would be particularily useful) 2, Change specification: - possible informative specification of division to sub-change(set)s - change author - log messages 3, User-defined metadata: Metadata specific to particular version control system, for its internal use. - revision numbers - access control - whatever else ;-) I think it is important to assume as little about the spatch user capabilities as possible (in the 1, and 2, part). Revision numbers may not be suitable unique identifiers, for example. You should not need _ANY_ version control upon the tree you want to apply spatch on. You can lose some nice capabilities (ie. you have less immunity against file renames by absence of tags tracking), but you can still apply the patch and resolve only reasonably little (relatively) number of conflicts. That is also why file names should be always carried along the tags. This is I think only mostly reformulated and condensated summary of what was already said (or assumed, hopefully). Feel free to nitpick or trash ;-). Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From rwa@alumni.princeton.edu Tue Apr 8 10:12:27 2003 Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38FCQbs025962 for ; Tue, 8 Apr 2003 10:12:26 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout4-ext.prodigy.net (8.12.3 patch/8.12.3) with ESMTP id h38FCNqk089338; Tue, 8 Apr 2003 11:12:24 -0400 Subject: RE: Variance Adjusted Changesets From: Robert Anderson To: Sander Striker Cc: changesets In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 08 Apr 2003 08:37:45 -0700 Message-Id: <1049816266.1405.56.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Tue, 2003-04-08 at 06:51, Sander Striker wrote: > > From: changesets-admin@sp.red-bean.com > > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Florin Iucha > >> My thoughts here is that if a user want's to check out from a > >> versioning system with a central repository, we should provide a local > >> one, > > Why? For people working with a central repository they rely on that > central repository to be available. Only when they've never had a better option available. > No need to duplicate locally > other than for optimization (and opening a can of worms when it > comes to access control and what not...). I strongly disagree with that. Laptop on the plane, anyone? Or maybe you are calling that an "optimization." I would call it functionality. > > All the three options can be reduced to one: distributed repositories. > > Exactly. And that has nothing to do with defining what a changeset should > look like. Granted. Bob From fog@initd.org Tue Apr 8 12:01:43 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38H1hbs029353 for ; Tue, 8 Apr 2003 12:01:43 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 8FB293C0A6; Tue, 8 Apr 2003 18:47:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 1D32F1A338 for ; Tue, 8 Apr 2003 19:00:45 +0200 (CEST) Subject: RE: Variance Adjusted Changesets From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9R3Hcb42ciMY1VKTt2/U" Organization: init.d Message-Id: <1049821244.1227.8.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 19:00:44 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-9R3Hcb42ciMY1VKTt2/U Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 15:51, Sander Striker ha scritto: > > From: changesets-admin@sp.red-bean.com > > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Florin Iucha > > Sent: Tuesday, April 08, 2003 3:35 PM >=20 > > On Tue, Apr 08, 2003 at 01:21:33PM +0200, Lars Segerlund wrote: > >>=20 > >> I would like to add poit 0 to the below list. > >>=20 > >> 0. How do we represent a local repository ? >=20 > We don't. agreed. we are here to find a good and tool-agnostic patch set format, not to impelement a complete scms system. repository is, imho, out of the scope of this list. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-9R3Hcb42ciMY1VKTt2/U Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kwA8vcCgrgZGjesRAgb/AJwOYSQbaPNDAwEeVUswgUU8DdydNwCg0tor eayu3omvEkbhvbcrbhXWW0E= =0dET -----END PGP SIGNATURE----- --=-9R3Hcb42ciMY1VKTt2/U-- From fog@initd.org Tue Apr 8 12:07:40 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38H7dbs029566 for ; Tue, 8 Apr 2003 12:07:39 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 930DC3C0A6; Tue, 8 Apr 2003 18:53:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id AEA151A338 for ; Tue, 8 Apr 2003 19:06:53 +0200 (CEST) Subject: Re: Our goals From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <20030408145039.GF3037@pasky.ji.cz> References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> <3E92B0BD.4040204@comsys.se> <20030408133436.GA11307@iucha.net> <3E92D43D.10201@comsys.se> <20030408145039.GF3037@pasky.ji.cz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Aj3AgFzbsAfS4c8d3h/o" Organization: init.d Message-Id: <1049821613.1105.14.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 08 Apr 2003 19:06:53 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-Aj3AgFzbsAfS4c8d3h/o Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2003-04-08 alle 16:50, Petr Baudis ha scritto: [3 goals snipped] i completely agree on the stated goals.=20 > I think it is important to assume as little about the spatch user capabil= ities > as possible (in the 1, and 2, part). Revision numbers may not be suitable > unique identifiers, for example. You should not need _ANY_ version contro= l upon > the tree you want to apply spatch on. You can lose some nice capabilities= (ie. > you have less immunity against file renames by absence of tags tracking),= but > you can still apply the patch and resolve only reasonably little (relativ= ely) > number of conflicts. That is also why file names should be always carried= along > the tags. perfect, imho. (btw eva metapatch already work that way, first tags, then paths, then complains.) talking about patch format i push toward a MIME-like envelope containing headers (path, tag, patch id, metadata, etc) that can be extended by specific tools and a "payload" (the body) containing patch delta. if anyone is interested i can send to this list a spatch between last night eva snapshot and today work (generated by "eva metapatch diff"), MIME encoded, that can be applied by cat-ing it to "eva metapatch patch".) it shows how MIME encoded patches can be safetly exanged by email, be human readable and easy to apply. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org "Yes, your honour, I have RSA encryption code tattood on my penis. Shall I show the jury?" -- --=-Aj3AgFzbsAfS4c8d3h/o Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+kwGtvcCgrgZGjesRAmZNAJ9CobocVvfX43UksdrZ8UmYV1SM7QCfVMOJ jBY7Pe69TcnRQUvV6+YJFnA= =GNKq -----END PGP SIGNATURE----- --=-Aj3AgFzbsAfS4c8d3h/o-- From lord@emf.net Tue Apr 8 14:40:41 2003 Received: from morrowfield.regexps.com (11Cust97.tnt13.sfo8.da.uu.net [65.234.195.97]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38Jebbs001432 for ; Tue, 8 Apr 2003 14:40:38 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id MAA28306; Tue, 8 Apr 2003 12:50:32 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 12:50:32 -0700 (PDT) Message-Id: <200304081950.MAA28306@morrowfield.regexps.com> From: Tom Lord To: changesets@sanpietro.red-bean.com Subject: svn questions & towards a spec Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I'm going to make the _assumption_, for now, that we need some notion of logical file identity which, for simplicity, I'll call by its arch name of "inventory tag". This isn't yet a draft spec ... but I think you'll see that parts of it are moving in that direction. As core svn developers come on line, I wonder if we shouldn't consider a semi-formal RFCish process for organizing the discussion. In the meantime, though, I'll just forge ahead a bit. The questions are how do we define inventory tags, and what mechanisms do we use to implement them? On the topic of mechanisms: arch has some, but here we'd like to find some mechanisms that work for other systems as well, and svn is the "other system" of most direct interest. In order to define "inventory tag", let's start by defining "inventory". Conceptually, an inventory is just a recursive directory list ... but there are issues to think through. We can treat "inventory" as a function. It takes a single argument, which is a source tree, and returns "some" value: inventory(TREE) => ??? I think it's reasonable to say that the value returned is a list of strings: names of all the source files and directories TREE, expressed as relative path names. If my source tree looks like this: % cd TREE % ls INSTALL README src % ls src hello.c then the inventory might be: inventory(TREE) => INSTALL README src src/hello.c There are some subtleties, naturally. * Windows v. UNIX path separator Filename syntax is not constant across all target platforms. Relative filenames for the same tree would look different on Windows than on UNIX. But we want changesets to be portable _between_ those two platforms. My understanding is that the relevant difference between Windows and UNIX for inventory is going to be the path separator (backward slash on Windows, forward slash on unix). I tentatively think there is no reason why Windows device prefixes would matter to us. I see three alternatives: (a) always use / as separator in inventories, regardless of platform. (b) always use \ as separator (c) permit either, but tools which process inventory lists must recognize that both / and \ are equivalent pathname separators Roughly, (a) and (b) are "canonicalize on generation" and (c) is "canonicalize on reading". My recommendation: I think that (b) would be a poor choice for at least two reasons: the awkward interaction of \ with quoting and escapes in many contexts; unix users would find it complete absurd. / does not have quoting problems, and I would guess that it's use would not confuse, surprise, or offend many windows users. (I'm not a windows user. Isn't it the case that many tools on windows already accept / as a path separator?) (c) is initially attractive on the "be tolerant in what you recieve" principle -- but I think it would ultimately prove to be a poor choice. When we define other syntaxes in which inventory names can occur, the possibility of \ as path separator interferes badly with using \ as an escape or quoting character in those syntaxes. (c) has an additional severe drawback. It presumes that inventory lists are always and only processed by tools which know they are inventory lists. For example, in the general case, a simple tool like `cmp' could not be relied on to compare two files that happened to include inventory lists in their contents. Finally, (c) raises the question: can \ and / be mixed in the same inventory list? By process of elimination, I'm inclined towards (a). * Filename Character Set I think we can reasonably anticipate that changeset tools and generic tools used to manipulate changesets and source trees will have needs such as sorting and comparing inventory names. When we define syntaxes that include inventory names as an element, those syntaxes will have to deal with issues such as the delineation of inventory names. So that raises a huge array of questions: can the names contain whitespace or control characters? can they contain \? What character sets and encodings may a filename use? If more than one character set or encoding is possible, then will syntaxes that include inventory name elements that specify which character set and encoding is in use? My recommendation: I think that these questions are basically a swamp. We could spend huge amounts of effort on them, for very little practical return. I propose that we take a very simple approach. (a) Filename components are strings of bytes which changeset tools should compare and collate as strings of bytes. (User interface tools are, of course, free to present a different interpretation in their displays and input processing.) (b) Changeset tools are not required to handle filename components containing \. Syntaxes defined in terms of inventory names may assume that inventory names do not contain \. (c) Changeset tools are not required to handle filename components containing bytes in the closed range 000 ... 040. Syntaxes defined in terms of inventory names may assume that those names do not contain bytes in that range. (d) There are no additional restrictions on the bytes in filename components. * Which Files are in the Inventory? Not all files in a tree are in the inventory. For example, on unix systems, files having names "." and ".." are clearly not part of the inventory. It is desirable to exclude other files from inventories as well. For example, if I have a source tree, and in that source tree I also have ".o" files that are intermediate results from an earlier build, _usually_ I will not want changeset tools to consider those to be "added files" -- and a natural way to accomplish that is simply to exclude those files from the inventory. I'm not going to make a specific recommendation at this time about how to decide which files are in the inventory. There are some design choices here that will be easier to discuss later, after we've talked about inventory tags. ________________________________ Ok, hopefully that's enough to get started for "inventory", what about "inventory tag"? Notationally, we can consider a function `inventory_tag' which accepts two arguments: a source tree and the name of a file in a source tree, and returns one value: the "logical name" for that file: inventory_tag(TREE, INVENTORY_NAME) => "logical file id" but what is the "logical file id"? I propose that logical file ids are strings of ASCII characters in the closed range 041...176, excluding 134 (backslash). (Brief rational: That's all graphical ASCII characters other than backslash -- a convenient definition for defining other syntaxes that include inventory tags. As we'll see later, users and/or programmers have to be able to generate inventory tags and the tags they generate must have a low probability of collision with tags generated by other users/tools running elsewhere -- defining tags as an arbitrary string makes that fairly easy by a variety of techniques.) So: inventory_tag(TREE, INVENTORY_NAME) => A_STRING That function must satisfy a critical invariant: inventory_tag(T, A) == inventory_tag(T, B) if and only if A == B In other words, no two files in given tree may have the same tag. The obvious question is: how is inventory_tag implemented? What is the actual mechanism for recording inventory tags? That, _finally_, is the design issue I'd like to work on with svn developers. So I'm not going to propose specific mechanisms yet, other than to point to the mechanisms in arch and the experience we have with them as a starting point. Some notes about tagging mechanisms: * portability If two (conceptually) related trees are stored in two revision control archives, the inventory tags must be the same in both archives. If a related tree is available outside of _any_ revision control system, the inventory tags must be included with that tree. If an uncontrolled tree is imported into a revision control system, the tags must be imported along with it. * probable uniqueness If two users are working separately on related trees, and each adds (different) new files, they must provide tags for those new files -- it is important that the tags they create are unlikely to collide. * invariance Of course, the inventory tag of a file must not change as the file is modified. Broadly speaking, I see only three practical possibilities: (a) inventory tags are stored inside of files themselves Clearly, this solution is not general. It can only be used for some files and not others. I can not be used to tag directories or symbolic links. Yet experience has shown that, when it does apply, this can be a very convenient option for users because it ensures that when a file is moved, it's tag always moves with it. A design issue to consider here is _how_ internal tags can be recognized (b) inventory tags are stored outside of files Clearly this is a general solution, though it is a restrictive one -- because when a file is renamed or deleted, the external record of its tag must somehow be updated along with it. In my experience, it works out well to store tag data for non-directories in a hidden subdirectory of their directory; and to store tag data for directories in a hidden direcctory of the directory itself. Thus, in a tree: src/ src/hello.c tags for both the directory `src' and the file `hello.c' would be stored in the directory `src/.inventory-tags': src/ src/.inventory-tags src/.inventory-tags/dir-tag src/.inventory-tags/tag.hello.c src/hello.c The advantage of this arrangement is that if `src' is renamed or deleted, it's tag and the tags of all files it contains are automatically kept up-to-date. However, that said, there's lots and lots of other ways store tags externally. One thing I wonder is whether, in svn, there is already a suitable working copy data struture that would "happen to be" suitable for use as an inventory tag. Of course, if there is a candidate data structure, it should be evaluated in terms of the requirements listed above: portability, probable uniqueness, and invariance. (c) use inventory names as inventory tags Again, not a general solution, but sometimes both convenient and appropriate. Files tagged by this method change their logical identity if they are renamed -- but for files that are unlikley to move, this is a very convenient option. The availability of this tagging method also ensures that the changeset tools can operate usefully on trees which do not contain any inventory tag information. I recommend an approach similar to that in arch: a mixing and matching various tagging mechanisms, and a parameter recorded in the source tree that describes which mechanisms are in play. I see one possibility that, to my knowledge, is impractical: (d) file "signatures" or "fingerprints" as tag It sure would be nice if an implementation of `inventory_tag' could somehow _guess_ the tag for a file just by examining the tree -- with no explicit record of a tag needed at all. For example, the tag of a .c file might be the concatenated names of the symbols it exports. Unfortunately, such fingerprinting seems to me to be both hoplessly fragile, and too computationally expensive. -t From lord@emf.net Tue Apr 8 14:57:13 2003 Received: from morrowfield.regexps.com (11Cust97.tnt13.sfo8.da.uu.net [65.234.195.97]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38JvCbs001931 for ; Tue, 8 Apr 2003 14:57:12 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id NAA28489; Tue, 8 Apr 2003 13:07:00 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 13:07:00 -0700 (PDT) Message-Id: <200304082007.NAA28489@morrowfield.regexps.com> From: Tom Lord To: rbcollins@cygwin.com CC: striker@apache.org, changesets@sanpietro.red-bean.com In-reply-to: <1049797820.878.49.camel@localhost> (message from Robert Collins on 08 Apr 2003 20:30:20 +1000) Subject: Re: Variance Adjusted Changesets References: <1049797820.878.49.camel@localhost> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > Logical file identities are only needed for just that, > imprecise patching. I'm willing to argue that you will never > _have_ to patch imprecisely. This is only needed in the > scenario where you don't have (read) access to the > repository. That's an important scenario. -t From lord@emf.net Tue Apr 8 17:05:48 2003 Received: from morrowfield.regexps.com (11Cust97.tnt13.sfo8.da.uu.net [65.234.195.97]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h38M5jbs005830 for ; Tue, 8 Apr 2003 17:05:46 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA28899; Tue, 8 Apr 2003 15:15:21 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 15:15:21 -0700 (PDT) Message-Id: <200304082215.PAA28899@morrowfield.regexps.com> From: Tom Lord To: changesets@sanpietro.red-bean.com, dev@subversion.tigris.org cc: striker@apache.org, kfogel@collab.net Subject: isn't variance adjusted patching horribly dangerous? Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: I've been reading: http://svn.collab.net/repos/svn/trunk/www/variance-adjusted-patching.html There are times when variance adjusted patching would certainly do "the right thing" --- and if you know you have such a situation, well, heck it's a fine tool to add to the toolbox. But in general, it seems quite dangerous precisely because it accomplishes its goal of eliminating conflicts that would otherwise arise from contextual changes. Perhaps I've misunderstood how it works, so let me illustrate what I'm thinking of: Consider, for example, a common ancestor that starts with: T:8 == B:1 ---------- last = x; val = 2 * x; foo (val); On the trunk: T:19 (unchanged from T:8) ---- last = x; val = 2 * x; foo (val); T:20 (second line changed from T:19) ---- last = x; val = 2 * (counter += x); foo (val); And on the branch: B:15 (first line changed from B:1) ---- last = x, counter += x; val = 2 * x; foo (val); In this case, both the trunk and branch programmers added a needed increment of `counter', but they did it in different ways, on nearby but different lines. The programmer wants to apply T:19-T:20 to B:15. Between T:19 and T:20, only one line changed here (the assignment to val). The context diff will be something like: *** T:19 --- T:20 ***** last = x; ! val = 2 * x; foo (val); ----- last = x; ! val = 2 * (counter += x); foo (val); That will be adjusted to account for the changes between T:8 and T:19 (there are none), and then for the changes from B:1 to B:15. After that adjustment (for an "in-range editted line"), the patch will look like this: *** T:19 --- T:20 ***** last = x, counter += x; ! val = 2 * x; foo (val); ----- last = x, counter += x; ! val = 2 * (counter += x); foo (val); which will apply without conflict to B:15, yielding: B:16 ---- last = x, counter += x; val = 2 * (counter += x); foo (val); which (because of the duplicated assignments to counter) is likely to be the wrong result. Now, to be fair -- even regular textual patching, without the variance algorithm, can introduce surprising bugs. Patching is inherently dangerous that way. But one of the ways we traditionally reduce that risk is by using context diffs -- and variance adjusted patching appears to be a mechanism precisely designed to undo the benefits of that safety measure. The example above illustrates a case where ordinary patching would do the right thing, generate a conflict and help a programmer to notice the bug, but variance adjusted patching will silently hide the bug. A less aggressive form of variance adjustment would seem to me to be safer: and that would be just to adjust the line offsets of hunks (not their contents) in response to out-range additions and deletions. That would defeat the window-size limitation of the patching tool Referring to http://svn.collab.net/repos/svn/trunk/www/variance-adjusted-patching.html that would be cases 1 and 2 of the two 7-case adjustment algorithms (The text starting with "To adjust P, we first walk over the diff T:8-T:19,"). Yet even _that_ kind of adjustment presents new dangers, and I don't think I'd want it to be the default. -t From lord@emf.net Tue Apr 8 21:28:41 2003 Received: from morrowfield.regexps.com (11Cust97.tnt13.sfo8.da.uu.net [65.234.195.97]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h392Scbs013655 for ; Tue, 8 Apr 2003 21:28:39 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id TAA29739; Tue, 8 Apr 2003 19:38:28 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Tue, 8 Apr 2003 19:38:28 -0700 (PDT) Message-Id: <200304090238.TAA29739@morrowfield.regexps.com> From: Tom Lord To: mass@akuma.org CC: changesets@red-bean.com In-reply-to: <3E92474D.4060009@akuma.org> (message from David Waite on Mon, 07 Apr 2003 21:51:41 -0600) Subject: Re: Goals References: <3E92474D.4060009@akuma.org> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: 1) Well-defined way of specifying the base (ORIG set) on which the patch is defined. This includes the possibility of specifying URL(s) for the location of the base (ORIG set) Not necessarily URLs exclusively -- but some definitive way to say what ORIG was. And not just ORIG, but MOD too. But neither should be mandatory. (Why not URLs only? Because P2P systems (such as arch) don't require that a URL exists, but ORIG and MOD still have global names. (Maybe URLs are really general enough to work for P2P systems -- I'm not sure.) Why MOD too? Well, why should ORIG be special? Why not mandatory? Because they might not be on-line.) 2) [????] You left out (2). :-) 3) I don't care if it is compatible with patch, because Ok. I don't totally follow some of the reasons you gave but came to a similar conclusion. 4) Changesets should be heirarchial - they should be able to contain multiple changesets, as well as individual 'changes' to either content (files, metadata) or structure (create, move, delete, copy). That is, multiple distinct changes should not need to be collapsed into one before serialization into this format. At first I thought: "Why not just send N separate changesets?" -- but, no, when we move from semantics to syntax, a compound format makes a lot of sense. For one thing, it's a format that "changeset-utils" can make good use of. For another thing, it's handy when you're sending a big set of changes to Linus (for example) to say "Ok, here's the big FOO changes -- but I've broken it up into bite-sized pieces" -- and on Linus' end, the changeset-utils can do reasonable things with that. 5) I haven't messed around with a system using changesets enough to know if a dependancy graph is desired between changesets, or if a linear order is sufficient. In either case, changes contained directly within a changeset should be order-independant (i.e. The only way to have multiple content modifications or structural modifications against a single file within a changeset is to have them indirectly included by sub-changesets) Changesets are naturally related by two partial orders (dependency graphs). One graph is just the textual/structural graph (e.g. two successive changes modify the same lines of a file). The other graph is the "logical" graph (e.g., change B, even if it applies cleanly, won't work unless change A is applied first.) I don't entirely follow (5) -- but I'll tentatively take it to mean that changesets should include an optional mechanism to record the logical graph (as declared by a programmer) and should contain a non-optional mechanism to state the ordering of overlapping sub-changes. 6) It should be possible to represent a file within the managed space of a repository by a unique name in order to apply content changes in the lack of dependant structure changes. It looks like arch already has such a feature. Yup. 7) Changesets themselves should be trackable with a unique name/identifier. I suggest that we make the definition of that namespace a separate thing -- a separate standard -- but that yes, the changeset format should make it possible to record that name in the changeset itself. 8) The requirements for function delta envisioned above should not be part of the changeset format if possible - the changesets should be generic across systems with different merging strategies. Which requirements? Do you mean the fundamental equation: delta(ORIG,MOD)[ORIG] == MOD ? I think that's pretty important and is generic. I do see the need to create changesets which are able to describe the resolution to merge conflicts (but unfortunately I'm not mathmatically adept currently to 'prove' this to be possible). That's a vague statement. It refers to a complicated area. Let's postpone that until we get to the topic of what `dopatch' does. 9) It should be possible for me to invert a changeset, i.e. revert the changes. Certainly. And edit it in other ways. We can add a new function to go with delta, called `invch', and introduce an additional fundamental equation: invch(delta(ORIG,MOD)) == delta(MOD,ORIG) and on the basis of the two fundamental equations we could (trivially) prove, for example, that: invch(delta(ORIG,MOD))[MOD] == ORIG 10) It should be possible to only partially apply a changeset. Right. As the definition emerges, we should pay attention to the practicalities of defining editors that "cut out" just parts of a larger changeset. -t From mass@akuma.org Wed Apr 9 01:56:15 2003 Received: from mail.aspect.net (adsl-65-69-210-161.dsl.hstntx.swbell.net [65.69.210.161]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h396uEbs020133 for ; Wed, 9 Apr 2003 01:56:14 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.aspect.net (Postfix) with ESMTP id 7AA061FB03; Wed, 9 Apr 2003 01:56:13 -0500 (CDT) Received: from mail.aspect.net ([127.0.0.1]) by localhost (pavia.aspect.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32406-03; Wed, 9 Apr 2003 01:56:09 -0500 (CDT) Received: from akuma.org (12-253-230-167.client.attbi.com [12.253.230.167]) by mail.aspect.net (Postfix) with ESMTP id B1FD41FAFC; Wed, 9 Apr 2003 01:56:07 -0500 (CDT) Message-ID: <3E93C406.3070008@akuma.org> Date: Wed, 09 Apr 2003 00:56:06 -0600 From: David Waite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lord@emf.net Cc: changesets@red-bean.com Subject: Re: Goals References: <3E92474D.4060009@akuma.org> <200304090238.TAA29739@morrowfield.regexps.com> In-Reply-To: <200304090238.TAA29739@morrowfield.regexps.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030314-p1 (Debian) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom Lord wrote: > 1) Well-defined way of specifying the base (ORIG set) on which > the patch is defined. This includes the possibility of > specifying URL(s) for the location of the base (ORIG set) > >Not necessarily URLs exclusively -- but some definitive way to say >what ORIG was. And not just ORIG, but MOD too. But neither should >be mandatory. > >(Why not URLs only? Because P2P systems (such as arch) don't require >that a URL exists, but ORIG and MOD still have global names. (Maybe >URLs are really general enough to work for P2P systems -- I'm not sure.) > >Why MOD too? Well, why should ORIG be special? > >Why not mandatory? Because they might not be on-line.) > There are two different concepts here - a unique identifier used for distinguishing a particular ORIG fileset or MOD changeset, and a URL for locating the 'home' of that fileset or changeset. It is possible that these could be the same thing in some environments. > 2) [????] > >You left out (2). :-) > I still don't remember what (2) was, which means it was probably fluff ;-) > 3) I don't care if it is compatible with patch, because > >Ok. I don't totally follow some of the reasons you gave but came to a >similar conclusion. > Basically, a unified/context diff isn't always the best format for representing files, specifically if they are not human-presentable text (some xml formats, binary). If ORIG is available, NEW is generatable from it. Once you have a local copy of the two files, diffs can then be run against that using whatever custom or personally preferred mechanism desired. This isn't saying that ORIG has to be the fileset that the changeset is applied to, just that ORIG has to be available. If it is a goal that the changeset could be applied against a different fileset without knowing ORIG, then some context will need to be sent along with the changeset - either the subset of ORIG changed by MOD included verbatim, or a diff representation that holds partial context (such as traditional context-format diff). If it is a goal that the changeset be representable using as much human-readable text as possible and/or that a minimal amount of work is needed for a subset of the changeset to be applied using 'patch', then I see both context-format diff and some binary diff being requirements. > 4) Changesets should be heirarchial - they should be able to > contain multiple changesets, as well as individual > 'changes' to either content (files, metadata) or structure > (create, move, delete, copy). That is, multiple distinct > changes should not need to be collapsed into one before > serialization into this format. > >At first I thought: "Why not just send N separate changesets?" -- but, >no, when we move from semantics to syntax, a compound format makes a >lot of sense. For one thing, it's a format that "changeset-utils" >can make good use of. For another thing, it's handy when you're >sending a big set of changes to Linus (for example) to say "Ok, here's >the big FOO changes -- but I've broken it up into bite-sized pieces" >-- and on Linus' end, the changeset-utils can do reasonable things >with that. > Exactly. It is also useful if you have a local branch which you are working off of, such as the traditional 'notebook-on-an-airplane' example for offline replication. Not only would the changes be represented, but the intermediate history can be preserved if the particular repository supports it. > 5) I haven't messed around with a system using changesets > enough to know if a dependancy graph is desired between > changesets, or if a linear order is sufficient. In either > case, changes contained directly within a changeset should > be order-independant (i.e. The only way to have multiple > content modifications or structural modifications against a > single file within a changeset is to have them indirectly > included by sub-changesets) > >Changesets are naturally related by two partial orders (dependency >graphs). One graph is just the textual/structural graph (e.g. two >successive changes modify the same lines of a file). The other graph >is the "logical" graph (e.g., change B, even if it applies cleanly, >won't work unless change A is applied first.) > >I don't entirely follow (5) -- but I'll tentatively take it to mean >that changesets should include an optional mechanism to record the >logical graph (as declared by a programmer) and should contain a >non-optional mechanism to state the ordering of overlapping >sub-changes. > This could very easily take the place of (2), since I'm saying at least two things :-) Assuming (and very much hoping) that the graph is directed acyclic, an order can be determined in which to apply changes. Indeed, chronological order is the most probable ideal for writing out the sub-changeset. The question: whether the optional mechanism to describe the dependancy graph is a goal. Without the dependancy graph described, it is assumed that the graph winds up being a straight line through each changeset in order. The other portion is describing a bit of the logical structure: a changeset contains either child changesets or changes, where changes express either a single structural or content change - creation of a file, modification of a file, moving of a directory. It would probably be simpler to describe the structure holding child changesets and the structure holding changes with different names :-) The idea here is that there should not be dependancy within a set of changes, while there will be dependancies within a set of changesets (whether defined or not.) > 8) The requirements for function delta envisioned above should > not be part of the changeset format if possible - the > changesets should be generic across systems with different > merging strategies. > >Which requirements? Do you mean the fundamental equation: > > delta(ORIG,MOD)[ORIG] == MOD > >? I think that's pretty important and is generic. > More that the fundamental equation is only partially defined by the changeset - the output and handling of delta(ORIG, MOD)[NOTORIG] shouldn't be part of the changeset format. > I do see the need to create changesets > which are able to describe the resolution to merge > conflicts (but unfortunately I'm not mathmatically adept > currently to 'prove' this to be possible). > >That's a vague statement. It refers to a complicated area. >Let's postpone that until we get to the topic of what `dopatch' does. > I did mean that more as a topic of discussion. Say that a changeset MOD1 is created between ORIG and NEW, the alterations needed to apply the changes within the changeset MOD against NOTORIG results in MOD2. Can MOD2 be partially described in terms of MOD1? It isn't a discussion to get into, at least yet :-) -David Waite From lars.segerlund@comsys.se Wed Apr 9 05:52:53 2003 Received: from kanga.comsys.se (gw.comsys.ideon.se [62.95.120.145]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39Aqpbs025047 for ; Wed, 9 Apr 2003 05:52:53 -0500 Received: from comsys.se (zeta.sys.energyx.se [192.168.0.39]) (authenticated (0 bits)) by kanga.sys.energyx.se (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id h39Aqmgf015155 for ; Wed, 9 Apr 2003 12:52:50 +0200 Message-ID: <3E93FB7F.6090506@comsys.se> Date: Wed, 09 Apr 2003 12:52:47 +0200 From: Lars Segerlund User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: changesets@red-bean.com Subject: Gathering the theory .. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Perhaps it's best if we can start off by gathering the theory around changesets in a common doc ? I had a very good read yesterday from darcs documentation, and there are some points about darcs that are really nice, such as that the order of patches doesn't matter it should still give the same final result and so on. Currently I'm compiling darcs and looking at the source in order to learn something, and instead of everyone doing this perhaps we really could contribute with some example and code around some different cases relating to change sets ? There is soo much confusion about this subject, ( of which I gladly admit I am a victim ), so if we could clear the clouds for everyone this would be great. I might even volunteer to edit such a doc, but I don't feel I know the subject and issues well enough just yet to start it off. / regards, Lars Segerlund. From mishad_work@hotmail.com Wed Apr 9 06:43:35 2003 Received: from hotmail.com (f102.pav1.hotmail.com [64.4.31.102]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39BhYbs026309 for ; Wed, 9 Apr 2003 06:43:35 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Apr 2003 04:43:29 -0700 Received: from 193.195.151.234 by pv1fd.pav1.hotmail.msn.com with HTTP; Wed, 09 Apr 2003 11:43:29 GMT X-Originating-IP: [193.195.151.234] X-Originating-Email: [mishad_work@hotmail.com] From: "Misha Dorman" To: changesets@sp.red-bean.com Cc: misha.dorman@iplbath.com Subject: Re: "Variance Adjusted Patching", Context, and File Identities Date: Wed, 09 Apr 2003 12:43:29 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Apr 2003 11:43:29.0531 (UTC) FILETIME=[3D7E0CB0:01C2FE8D] Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: It appears that there are three main applications for changesets: a) (the general case) outwith any history-maintaining SCM system, applying delta(ORIG,MOD) "fuzzily" to NEW i.e. fuzzypatch(NEW,delta(ORIG,MOD)) ("general inexact patching") b) (a specific/trivial case) as (a) but applying delta(ORIG,MOD) "exactly" to ORIG i.e. exactpatch(ORIG,delta(ORIG,MOD))=MOD ("exact patching") c) (a different case) as part of a history-maintiaining SCM system, applying mergepatch(delta(ORIG,MOD),delta(ORIG,NEW)) to NEW ("variance adjusted patching") (a) requires context (for file content changes) to identify where the change should be made and file identities (in some form) to identify to which file the change should be made. unified/context diff and patch (with a non-zero max offset) are the prototypes for delta and fuzzypatch here. (b) does not require context or file identities (more precisely, the line numbers and filenames in diff-ed output are sufficient context) (c) does not require context or file identities (as has been explained, it can use the history provided by the SCM tool). It might be helpful to consider the file identity metadata as akin to the context in a context diff -- it makes the patch/changeset easier to apply to non-ORIG trees. Note that (c) is not necessary, since the general case (a) can be used instead in most cases. Note also that fuzzypatch from (a) can be factored to make use of mergepatch from (c): fuzzypatch(NEW,delta(ORIG,MOD)) = mergepatch(derivepatch(NEW,delta(ORIG,MOD),delta(ORIG,MOD)) where derivepatch(NEW,delta(ORIG,MOD)) "reverse engineers" what is different between ORIG and NEW (e.g. what patch(1) does internally when working out where to apply each hunk). It is, of course, the derivepatch() part of fuzzypatch() which uses context and file identities. Q: what is the relative importance of these three scenarios? [Aside: PRCS uses the mergepatch approach for file-content changes but a fuzzypatch-like approach (using file identities aka file families) to determine the files affected by the patch. CVS does something similar, except it uses file names as trivial file identities :-). BK's world leading merge technology is (c), I think, possibly in an incremental fashion (i.e. merge to INTERMED1 then INTERMED2 ... then INTERMED then finally to NEW; c.f. larch replay vs larch update) -- certainly bk smerge works only on their SCCS files, not on plain trees/patches.] Tom also referred to the danger of patching without context, whereby conflicts might be missed. Context is serving two purposes here -- both to identify where a change is to be applied (in a non-ORIG tree), and to provide some protection against conflicting changes in nearby sets of lines. The lines of context mean "don't apply me [automatically] if any of these lines have changed" (or "be wary of applying me ..."). Q: how much context is appropriate to protect against automatically applying conflicting patches? The "right amount" of context depends on: a) the nature of the patch b) the sensibilities of the patch author (diff -c) c) the sensibilities of the patch applier (patch -F) Getting the amount of "safety" context right is part of making a good changeset (albeit quite a subtle part). Q: how much context is appropriate to accurately locate changeset hunks? The right amount of context to include for hunk-site location purposes will be a tradeoff of utility against patchsize, and is not necessarily the same as the right amount of context for safety purposes. Thus it might be useful to separate the two forms of context. Also, note that an SCM tool using only context-free or safety-context-only (b)- and (c)-style changesets could provide a patch including (additional) location-context (and thus an (a)-style changeset) on request. Final thought: I haven't thought through the impacts of the "keep conflicts in the tree" aka "support conflict-resolution patches" aka "lets share the work of resolving these 100-odd conflicts" idea. Is it safe to just park that idea for a while? Or do we need to analyse it up front? Cheers Misha Dorman _________________________________________________________________ Get Hotmail on your mobile phone http://www.msn.co.uk/mobile From pavel@bug.ucw.cz Wed Apr 9 09:34:13 2003 Received: from Elf.ucw.cz ([195.39.17.254]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39EXtbs030321 for ; Wed, 9 Apr 2003 09:34:10 -0500 Received: from bug.ucw.cz (amd.ucw.cz [10.0.0.6]) by Elf.ucw.cz (Postfix) with ESMTP id 67425C3459; Wed, 9 Apr 2003 16:33:22 +0200 (CEST) Received: (from pavel@localhost) by bug.ucw.cz (8.8.8/8.8.5) id QAA11718; Wed, 9 Apr 2003 16:30:11 +0200 Date: Wed, 9 Apr 2003 16:30:11 +0200 From: Pavel Machek To: Tom Lord Cc: changesets@red-bean.com Subject: Re: Towards Basic Definitions (notation, mostly) Message-ID: <20030409143011.GA11563@elf.ucw.cz> References: <200304080045.RAA24636@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304080045.RAA24636@morrowfield.regexps.com> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.3i Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! > Even with these informal definitions, and not quite stating the > definition of equality between source trees, we have an important > invariant (call it the "fundamental equation"): > > > delta(ORIG, MOD)[ORIG] == MOD > > which means that if you apply the changeset between ORIG and MOD to a > tree equal to ORIG, you get a tree equal to MOD. > > The "inexact patching problem" concerns what happens when you apply a > changeset to a tree that is not equal to ORIG: > > > delta(ORIG, MOD)[NOT_ORIG] == ??? > > > To define changesets for real, we have to fill out these definitions. > What's a source tree? What happens when a changeset is applied > to NOT_ORIG? Well, I believe that applying to non-original tree should be left implementation defined. I.e. define changesets so that it works on patching original files, and leave it to the implementor of the patch what happens if you patch not-orig tree. Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] From striker@apache.org Wed Apr 9 10:05:46 2003 Received: from striker.xs4all.nl (striker.xs4all.nl [213.84.19.217]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39F5jbs031311 for ; Wed, 9 Apr 2003 10:05:46 -0500 Received: from cheetah (cheetah.striker.nl [192.168.0.10]) by striker.xs4all.nl (Postfix) with SMTP id 218F5FC2DF; Wed, 9 Apr 2003 17:05:44 +0200 (CEST) From: "Sander Striker" To: "Pavel Machek" , "Tom Lord" Cc: Subject: RE: Towards Basic Definitions (notation, mostly) Date: Wed, 9 Apr 2003 17:05:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030409143011.GA11563@elf.ucw.cz> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: changesets-admin@sp.red-bean.com > [mailto:changesets-admin@sp.red-bean.com]On Behalf Of Pavel Machek > Sent: Wednesday, April 09, 2003 4:30 PM [...] >> To define changesets for real, we have to fill out these definitions. >> What's a source tree? What happens when a changeset is applied >> to NOT_ORIG? > > Well, I believe that applying to non-original tree should be left > implementation defined. I.e. define changesets so that it works on > patching original files, and leave it to the implementor of the patch > what happens if you patch not-orig tree. +1. Sander From lord@emf.net Wed Apr 9 11:50:47 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39Goibs002030 for ; Wed, 9 Apr 2003 11:50:45 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id KAA02391; Wed, 9 Apr 2003 10:00:34 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 10:00:34 -0700 (PDT) Message-Id: <200304091700.KAA02391@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: pavel@ucw.cz, striker@apache.org In-reply-to: Subject: Re: Towards Basic Definitions (notation, mostly) References: Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom: >> To define changesets for real, we have to fill out these >> definitions. What's a source tree? What happens when a >> changeset is applied to NOT_ORIG? Pavel: > Well, I believe that applying to non-original tree should be > left implementation defined. I.e. define changesets so that > it works on patching original files, and leave it to the > implementor of the patch what happens if you patch not-orig > tree. Sander: +1. I don't think it's quite that simple. Yes, it may very well turn out to be best to leave _some_ details up to implementations, but certainly not _all_. Some reasons why: 1) Applying changesets to trees which are not identical to ORIG is the _common case_ (other than in the internals of a revision control system). Applying changesets to ORIG happens when people download a changset instead of full text to upgrade their copy of a release. It happens when the next changeset a maintainer pulls "off the queue" happens to have the maintainer's wc as ORIG. But more usually, maintainers are pulling patches off a queue and applying them to trees which have already been modified relative to the ORIG of the patch. (I hear Sander considering making a reply about "variance adjusted patching" -- I'll say more about how v.a.p. fits into the changeset world in a later post today.) 2) Cherry-picking (which does not require a common ancestor , v.a.p. fans) is pretty much always a case of inexact patching. If I publish a changeset to be cherry-picked, I should have some idea how it will impact other people's trees. If I review a changeset someone else has published, I should have some idea how it will impat my tree. Those two ideas about tree impact should be the same -- so, for example, I (the picker) can write back to you (the publisher) and we can have a simple conversation about the best way to refactor the changeset. An important special case of cherry-picking is the application of changeset for an emergency bug fix (e.g. a security issue) to a possibly un-controlled source tree, quite possibly not equal to the ORIG of the patch, and quite possibly without access to any master repository for the tree. Inexact (i.e. non-orig) patching should be well-enough defined to give guidance to both the publisher and applier of such an emergency changeset. 3) Applying a changeset to non-orig tree can be a very useful and reliable code transformation technique _if the results are reliable_. As an example of that use of changesets as code transformations, I'll point to "release branch sanitizing" -- a use case I've experienced. In that use case, I start with a "devo" branch development line, where I do day-to-day work. In my case, the tree of the devo branch was actually a component of five separately released projects. The devo line didn't contain the files for just one of those projects, and the tree arrangement wasn't right for any of the five projects. Instead, the devo line contained the union of all files from all five projects, and a tree arrangement that was convenient for development, but wrong for releases. The first time I released any of the five projects, I started a "candidate-foo" ("release candidate for foo") branch from devo, sanitized the tree (removed files, rearranged the tree) by hand, and committed that to the candidate branch. Thereafter, I could at any time merge later changes from the devo branch into the candidate branch -- in essense applying an inexact changset -- and the devo head would be "re-sanitized" appropriately. (And, no, v.a.p. would not be the right tool for this job -- if the sanitizing patch tweaked a CONTENTS file or README, for example, that's the kind of case where v.a.p. can easily wind up silently hiding a conflict that really does need human attention.) 4) It's too early to say "That looks hard, let's just throw up are hands and give up on it.". It isn't _that_ hard. 5) I don't claim that the accumulated experience of diff/patch is the One True Way -- but it is a huge amount of successful experience in a closely related area. As I recall, `diff' is not speced to be deterministic -- but the inexact patching heuristics of `patch' are carefully defined. The spec of patch is very useful when building tools and systems that use patch: it let's you know when it can be used to obtain reliable results in non-orig situations, and when it can't. -t From lord@emf.net Wed Apr 9 12:11:33 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39HBVbs002880 for ; Wed, 9 Apr 2003 12:11:32 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id KAA02428; Wed, 9 Apr 2003 10:21:34 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 10:21:34 -0700 (PDT) Message-Id: <200304091721.KAA02428@morrowfield.regexps.com> From: Tom Lord To: changesets@sanpietro.red-bean.com CC: misha.dorman@iplbath.com In-reply-to: (mishad_work@hotmail.com) Subject: Re: "Variance Adjusted Patching", Context, and File Identities References: Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Misha Dorman: It appears that there are three main applications for changesets: a) [...] fuzzypatch(NEW,delta(ORIG,MOD)) ("general inexact patching") b) [...] exactpatch(ORIG,delta(ORIG,MOD))=MOD ("exact patching") c) [...] applying mergepatch(delta(ORIG,MOD),delta(ORIG,NEW)) to NEW ("variance adjusted patching") (I think your mergepatch notation isn't quite right but I'll talk about that in a later message about v.a.p. -- briefly, there are _four_ trees involved in v.a.p., not three.) Note that (c) is not necessary, since the general case (a) can be used instead in most cases. Yes but v.a.p. gives an interestingly different result and a variation on v.a.p. (v.v.a.p.?) can be more interesting still. Note also that fuzzypatch from (a) can be factored to make use of mergepatch from (c): fuzzypatch(NEW,delta(ORIG,MOD)) = mergepatch(derivepatch(NEW,delta(ORIG,MOD),delta(ORIG,MOD)) Again: your notation is misleading you. v.a.p. (mergepatch) takes four trees, not three. fuzzypatch always takes three. I don't think there's any natural way to define fuzzypatch in terms of mergepatch, but later on I'll talk about defining mergepatch in terms of fuzzypatch_prime and some other tools. Hmm. Actually, you could probably make a mergepatch5 that takes _five_ trees, and define both mergepatch4 and fuzzypatch in terms of that -- but I don't immediately see any practical benefit to that. It would raise the question of "inexact variance adjustment". (c) [v.a.p.] does not require context It makes good use of context lines. or file identities (as has been explained, it can use the history provided by the SCM tool). Our goals here include not relying on any revision control tool. Q: what is the relative importance of these three scenarios? I'm willing to say that they are all equally important because I don't see any obstacle at all to supporting all three in the changeset format. Q: how much context is appropriate to protect against automatically applying conflicting patches? Q: how much context is appropriate to accurately locate changeset hunks? As you note, there's no perfect answer -- just a lot of accumulated experience with defaults. Final thought: I haven't thought through the impacts of the "keep conflicts in the tree" aka "support conflict-resolution patches" aka "lets share the work of resolving these 100-odd conflicts" idea. Is it safe to just park that idea for a while? Or do we need to analyse it up front? I'm not sure -- having not solved that problem yet (or spent much time on it). My intuition is that we can work out first how to compute a changeset, then abstractly how to apply it, then start worrying about representing conflicts "in the tree", and then go back and make any necessary changes to how changesets are computed and applied to deal with conflicts stored in the tree. -t From pasky@machine.sinus.cz Wed Apr 9 12:20:35 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h39HKWbs003221 for ; Wed, 9 Apr 2003 12:20:33 -0500 Received: (qmail 26117 invoked by uid 2001); 9 Apr 2003 17:20:30 -0000 Date: Wed, 9 Apr 2003 19:20:30 +0200 From: Petr Baudis To: Pavel Machek Cc: changesets@red-bean.com Subject: Re: Towards Basic Definitions (notation, mostly) Message-ID: <20030409172030.GR3037@pasky.ji.cz> References: <200304080045.RAA24636@morrowfield.regexps.com> <20030409143011.GA11563@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030409143011.GA11563@elf.ucw.cz> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Wed, Apr 09, 2003 at 04:30:11PM CEST, I got a letter, where Pavel Machek told me, that... ..snip.. > > To define changesets for real, we have to fill out these definitions. > > What's a source tree? What happens when a changeset is applied > > to NOT_ORIG? > > Well, I believe that applying to non-original tree should be left > implementation defined. I.e. define changesets so that it works on > patching original files, and leave it to the implementor of the patch > what happens if you patch not-orig tree. +1 A possible exception coming on my mind is when some type of information needs to be justified as necessary for (reasonably easy) fuzzy patching. I mean the file ids discussion in particular, then it is useful to describe the merging algorythm which does (not) make use of that information. -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From lord@emf.net Wed Apr 9 12:42:17 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39HgFbs003991 for ; Wed, 9 Apr 2003 12:42:15 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id KAA02480; Wed, 9 Apr 2003 10:52:02 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 10:52:02 -0700 (PDT) Message-Id: <200304091752.KAA02480@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: mass@akuma.org In-reply-to: <3E93C406.3070008@akuma.org> (message from David Waite on Wed, 09 Apr 2003 00:56:06 -0600) Subject: Re: Goals References: <3E92474D.4060009@akuma.org> <200304090238.TAA29739@morrowfield.regexps.com> <3E93C406.3070008@akuma.org> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Ok.... some new and refined goals come out of: David Waite (replies taken slightly out of order): > the output and handling of > delta(ORIG, MOD)[NOTORIG] > shouldn't be part of the changeset format. If you think of us as working towards writing formal specs, then I'd say we're talking about: (a) a spec for what the `diff' replacement does (b) a spec for the output format of `diff' (c) a spec for what the `patch' replacement does and probably also additional things like: (d) a spec for what the `v.a.p.' tools do, in terms of of (a), (b), and (c). (e) a spec for what a `compose_changesets' tool does etc. I realize that that sounds like possible "goals bloat". Only (a), (b), and (c) are necessary for revctl system interop (not quite sufficient, but necessary). Contemplating (d), (e) and so forth early can help us do a better job on (a)..(c) and, given (a)..(c), those other tasks should be pretty easy. > [....] [On recording ORIG and MOD identifiers in changesets.] > There are two different concepts here - a unique identifier used for > distinguishing a particular ORIG fileset or MOD changeset, and > a URL for locating the 'home' of that fileset or changeset. Yup. Those "unique identifiers" are, imo, going to be critical for interoperable distributed revision control. I think defining what they might be is larger in scope than changesets, and that the changeset format itself need not know anything specific about them. So we should have a format that allows those ids to be recorded, but not get too hung up on what they mean at this stage. > Basically, a unified/context diff isn't always the best format > for representing files, [...] (some xml formats, binary) [...] > [....] > If it is a goal that the changeset be representable using as > much human-readable text as possible and/or that a minimal > amount of work is needed for a subset of the changeset to be > applied using 'patch', then I see both context-format diff and > some binary diff being requirements. Just in general, we should perhaps aim for extensibility in the file diff and file patch functions. That's tricky because we have no apriori way to recognize which diff tools to apply to what files. `diff' itself has the "binary file detection" hack, but I wouldn't mind something more precise and more general than that. One idea is to make that "diff type" attribute of files a part of the inventory tag for the file. When a user or tool creates a new inventory tag, recording the diff type of a file can be part of that process. > Assuming (and very much hoping) that the graph is directed > acyclic, an order can be determined in which to apply > changes. Indeed, chronological order is the most probable > ideal for writing out the sub-changeset. The question: whether > the optional mechanism to describe the dependancy graph is a > goal. Without the dependancy graph described, it is assumed > that the graph winds up being a straight line through each > changeset in order. If I have a totally ordered ("straight line") set of changes, an external tool can look at that and find the less-restrictive DAG of actual textual dependencies -- the DAG is implicit in the combined total ordering plus sub-changeset elements like hunk offsets. I don't see a need to more explicitly surface the textual DAG in the changeset format -- indeed it seems undesirable to require changeset-generation tools to _have_ to do that computation when it can just as easily be done by changeset-receiving tools, only some of which need the DAG anyway. > The other portion is describing a bit of the logical structure: a > changeset contains either child changesets or changes, where changes > express either a single structural or content change - creation of a > file, modification of a file, moving of a directory. It would > probably be simpler to describe the structure holding child > changesets and the structure holding changes with different > names :-) I sense that you want "primitive" changesets in this arrangement to not do more than, say, rename a single file. I think that restriction is undesirable. Rather, primitive changesets should permit arbitrary rearrangements of sets of files. Consider the simple case of swapping the location of two files. With arbitrary rearrangements, that's a single changeset that says something like: "after this change, A is called B and B is called A". With single-rename primitives, you'd need three changes: "(1) A is called TMP; (2) B is called A; (3) TMP is called B." -t From lord@emf.net Wed Apr 9 13:00:41 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39I0dbs004620 for ; Wed, 9 Apr 2003 13:00:40 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id LAA02649; Wed, 9 Apr 2003 11:10:20 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 11:10:20 -0700 (PDT) Message-Id: <200304091810.LAA02649@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: lars.segerlund@comsys.se In-reply-to: <3E93FB7F.6090506@comsys.se> (message from Lars Segerlund on Wed, 09 Apr 2003 12:52:47 +0200) Subject: Re: Gathering the theory .. References: <3E93FB7F.6090506@comsys.se> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Lars Segerlund > There is soo much confusion about this subject, ( of which I gladly > admit I am a victim ), so if we could clear the clouds for everyone this > would be great. +1. Of course, we're hampered here by the various ways in which the effort is resource starved. I can't commit to anything that takes longer than my remaining $130 will take me in life. The svn core guys entered the discussion while saying they can't give it much attention right now. And I fear the subtext of agendas that might easily work against "clearing the clouds" in informal mailing list traffic. We don't have a clear charter yet for what we plan to do. Kfogel's "Goals" is one starting point. My posts about inventory tags another. But both of those are too low level. What documents and code are our goals? What are they for? What process will we adopt to satisfy those goals? Those would be good questions to start with on a better day. -t p.s.: thanks for the pointer to "darcs" -- I hadn't seen that yet. From lord@emf.net Wed Apr 9 13:42:03 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39Ig0bs006293 for ; Wed, 9 Apr 2003 13:42:01 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id LAA02769; Wed, 9 Apr 2003 11:52:00 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 11:52:00 -0700 (PDT) Message-Id: <200304091852.LAA02769@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com cc: striker@apache.org Subject: changesets and variance adjusted patching Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: For those who haven't read kfogel's document, let me try to sum up v.a.p. briefly: We have four trees. Let's call these ANCESTOR, ORIG, MOD, TARGET. Conceptually, ORIG, MOD, and TARGET are all derived from ANCESTOR ... ORIG and MOD on one branch, TARGET on another ... MOD is derived from ORIG: ANCESTOR / \ / \ / TARGET ORIG | | MOD We want to merge some changes from the left branch into the right. Specifically, we want to apply the changeset: delta(ORIG, MOD) to TARGET. But there's a difficulty. TARGET may have diverged quite far from ORIG and anticipate getting many annoying conflicts if we just apply that change directly: delta(ORIG, MOD)[TARGET] ==> "many annoying conflicts" However, there are two other changesets of interest in this graph. These are: delta(ANCESTOR, ORIG) delta(ANCESTOR, TARGET) The information in those changesets can help us modify the delta(ORIG,MOD) changeset in such a way that it applies with fewer conflicts (or more accurately located conflicts) to TARGET. For example, let's suppose that delta(ORIG,MOD) includes a hunk that modifess line 100 of file foo.c. And delta(ANCESTOR,ORIG) deletes 50 lines from foo.c at line 10. If we wanted to apply delta(ORIG,MOD) to ancestor, we might want to adjust that hunk for line 100, and turn it into a hunk for line 150. And let's suppose that delta(ANCESTOR,TARGET) _adds_ 80 lines at line 20 of foo.c. Then to apply our changeset to target, we might want to further adjust that hunk so that it refers to line 230 (100 + 50 + 80). Beyond just adjusting hunk line numbers, we might make changes to context lines or even ORIG lines in the patch. Kfogels write-up contains an informal but detailed explanation of one possible "adjustments" algorithm. We could define notation for that "adjustments" algorithm -- considering it to be a function that takes two changesets and returns a third: adjust(CS1, CS2) => CS3 where that means "adjust CS1 to be applied to a tree which differs from the ORIG of CS1 by CS2". And then define the variance adjustment algorithm this way: variance_adjust(ANC, ORIG, MOD, TGT) := adjust (adjust (delta (ORIG, MOD), delta (ORIG, ANC)), delta (ANC, TGT)) [Note: I'm assuming that the ORIG-to-ANC and ANC-to-TGT adjustments are the same operation with different parameters -- but I admit I haven't double checked that. Perhaps there are two, slightly differing `adjust' operations.] One point of mentioning this formalism is to point out that it all reduces to changesets and operations on them. variance_adjust isn't a merge operations -- it's a way to compute a changeset (which can then be used for one form of merging). The changeset returned by variance_adjust may be regarded as independently interesting. For example, one might want to take that changeset, and then inexactly apply to yet a fifth tree. In other words, there is no reason to think that variance adjusted patching really eliminates the need for inexact patching or in any other way fundamentally changes the task of defining a changeset format. Rather, v.a.p. is something to define on top of changesets, in a fairly straightforward way. And, yes, yes, I do still maintain that v.a.p. is dangerous and not a good default for merging techniques -- but that's mostly an orthogonal issue here. I will mention that v.a.p., as currently defined, has both weakness and strengths. The weaknesses are the dangers I've already mentioned. The strength is that it can do better than patch's hunk window and context-matching algorithm at figuring out where in a heavily modified text a hunk refers to. So I'd like to see a variation on v.a.p. that eliminates the weakness while preserving the strength. Specifically, when `adjust' makes a change to a hunk that would cause the hunk to apply cleanly whereas previously it would not, that hunk should be specially marked as a "soft conflict". When a soft conflict hunk is applied, it should be treated as a conflict (e.g., generate a .rej or conflict markers) -- but it could also usefully include in that conflict record what the outcome is as suggested by ordinary v.a.p. Finally: that variation on v.a.p. brings us back to changset design question: should the changeset format have a way to indicate "soft conflicts", and if so, what should that mechanism be? How will patch-tools treat soft conflicts? -t From pavel@atrey.karlin.mff.cuni.cz Wed Apr 9 15:11:41 2003 Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39KBebs009612 for ; Wed, 9 Apr 2003 15:11:40 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 7C1014FD35; Wed, 9 Apr 2003 22:11:33 +0200 (CEST) Date: Wed, 9 Apr 2003 22:11:33 +0200 From: Pavel Machek To: Tom Lord Cc: changesets@red-bean.com, pavel@ucw.cz, striker@apache.org Subject: Re: Towards Basic Definitions (notation, mostly) Message-ID: <20030409201133.GA10713@atrey.karlin.mff.cuni.cz> References: <200304091700.KAA02391@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304091700.KAA02391@morrowfield.regexps.com> User-Agent: Mutt/1.3.28i Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > >> changeset is applied to NOT_ORIG? > > Pavel: > > > Well, I believe that applying to non-original tree should be > > left implementation defined. I.e. define changesets so that > > it works on patching original files, and leave it to the > > implementor of the patch what happens if you patch not-orig > > tree. > > Sander: > > +1. > > > I don't think it's quite that simple. > > Yes, it may very well turn out to be best to leave _some_ details up > to implementations, but certainly not _all_. > > Some reasons why: > > 1) Applying changesets to trees which are not identical to ORIG > is the _common case_ (other than in the internals of a revision > control system). Actually , I do not think so. Only developers apply to NOT_ORIG; users still use patch but only apply to ORIG. I guess users still outnumber developers by quite a lot. Anyway; yes I agree it is important for s-patch to support applying to NOT_ORIG; but I do not believe we have to describe exact algorithms how to do it. Of course it should be deterministic etc, but I believe that we should define spatch format first, and then create few (possibly quite different) impelemntations of spatch binary. For example for some revision-control systems you might want spatch that aborts when you try to apply over NOT_ORIG, you'll want spatch that does "something inteligent" when applying over NOT_ORIG, etc. These are different goals, they will need different spatch programs, but I believe it is possible to keep common spatch-file-format for all of them. Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. From lord@emf.net Wed Apr 9 16:01:33 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39L1Ubs011313 for ; Wed, 9 Apr 2003 16:01:31 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id OAA03390; Wed, 9 Apr 2003 14:11:11 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 14:11:11 -0700 (PDT) Message-Id: <200304092111.OAA03390@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: pavel@ucw.cz, striker@apache.org In-reply-to: <20030409201133.GA10713@atrey.karlin.mff.cuni.cz> (message from Pavel Machek on Wed, 9 Apr 2003 22:11:33 +0200) Subject: Re: Towards Basic Definitions (notation, mostly) References: <200304091700.KAA02391@morrowfield.regexps.com> <20030409201133.GA10713@atrey.karlin.mff.cuni.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Anyway; yes I agree it is important for s-patch to support applying to NOT_ORIG; but I do not believe we have to describe exact algorithms how to do it. Of course it should be deterministic etc, but I believe that we should define spatch format first, and then create few (possibly quite different) impelemntations of spatch binary. For example for some revision-control systems you might want spatch that aborts when you try to apply over NOT_ORIG, you'll want spatch that does "something inteligent" when applying over NOT_ORIG, etc. Ok... looking quickly at the Posix spec for patch: they spec a minimal behavior for inexact patching; that minimal behavior is parameterized in a few interesting ways; implementations are permitted to do more. Then looking at `patch(1)' on my system, it in fact does a lot more, and has a lot of additional parameters. That kind of spec: just a bare minimum of what's supposed to happen (absent overriding parameters), plus the option for particular tools to do whatever they like in addition to that, would satisfy me. Here's another example of where it matters: patchutils. Suppose I want to to write a tool that attempts to compose two patches that don't necessarily share the same orig tree. Such a tool can't always work, but sometimes it can do something useful. The patch output by this tool doesn't have a real ORIG tree -- only a hypothetical one. In the general case, it is always applied inexactly. A spec for the minimal behavior of a patch tool makes it possible to write a generic patch combiner, rather than a patch combiner that only supports one particular implementation of patch. -t From pasky@machine.sinus.cz Wed Apr 9 16:55:42 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h39Ltfbs013011 for ; Wed, 9 Apr 2003 16:55:41 -0500 Received: (qmail 3171 invoked by uid 2001); 9 Apr 2003 21:55:39 -0000 Date: Wed, 9 Apr 2003 23:55:39 +0200 From: Petr Baudis To: Tom Lord Cc: changesets@red-bean.com, striker@apache.org Subject: Re: changesets and variance adjusted patching Message-ID: <20030409215539.GU3037@pasky.ji.cz> References: <200304091852.LAA02769@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304091852.LAA02769@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Wed, Apr 09, 2003 at 08:52:00PM CEST, I got a letter, where Tom Lord told me, that... ..snip.. > Finally: that variation on v.a.p. brings us back to changset design > question: should the changeset format have a way to indicate "soft > conflicts", and if so, what should that mechanism be? How will > patch-tools treat soft conflicts? That could be obviously an area where graphical patching/merging tools would excel, "normal" patch tools should at least provide a way to: * Disable soft conflicts, like there would be no conflicts at all * Enforce soft conflicts, like there would be ... er, hard conflicts * Notify user about soft conflicts (at least in the way of "Hunk #5 generated soft conflict at 1234 (2 conflicting lines in context)") * Output the adjusted patch instead of applying it * List the differences (in adjusted hunks) between the original and modified context Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From lord@emf.net Wed Apr 9 17:21:07 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39ML4bs013786 for ; Wed, 9 Apr 2003 17:21:05 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA03713; Wed, 9 Apr 2003 15:30:51 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 15:30:51 -0700 (PDT) Message-Id: <200304092230.PAA03713@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: pasky@xs26.net, striker@apache.org In-reply-to: <20030409215539.GU3037@pasky.ji.cz> (message from Petr Baudis on Wed, 9 Apr 2003 23:55:39 +0200) Subject: Re: changesets and variance adjusted patching References: <200304091852.LAA02769@morrowfield.regexps.com> <20030409215539.GU3037@pasky.ji.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: me: >> Finally: that variation on v.a.p. brings us back to changset >> design question: should the changeset format have a way to >> indicate "soft conflicts", and if so, what should that >> mechanism be? How will patch-tools treat soft conflicts? pasky: > That could be obviously an area where graphical > patching/merging tools would excel, "normal" patch tools > should at least provide a way to: Why should graphical and "normal" patching be so unrelated? For modularity, and interoperability, I'd like graphical patching to be layered over batch patching. That means that the output batch patching should be machine parsable. In traditional Posix patch, the -D (--ifdef in GNU) option comes pretty close, with .rej files for recording conflicts. But those mechanisms need to be generalized for whole-tree patching and could stand to be improved in some other ways as well. Standardizing those output formats, well enough for people to write generic graphical patch tools, is yet another reason why some aspects of inexact patching ought to be speced as part of the changeset definition process. > [normal patching should be able to] Output the adjusted > patch instead of applying it. Outputting the variance adjusted patch ought to be the default for variance adjustment tools. Applying it without explicitly generating it is just a performance optimization -- one that is probably not all that important. "Simpler and fast enough" is almost always better than "Complicated as hell, but slightly faster." -t From pavel@atrey.karlin.mff.cuni.cz Wed Apr 9 17:41:10 2003 Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39MfAbs014447 for ; Wed, 9 Apr 2003 17:41:10 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 946484FCEE; Thu, 10 Apr 2003 00:41:08 +0200 (CEST) Date: Thu, 10 Apr 2003 00:41:08 +0200 From: Pavel Machek To: Tom Lord Cc: changesets@red-bean.com, pavel@ucw.cz, striker@apache.org Subject: Re: Towards Basic Definitions (notation, mostly) Message-ID: <20030409224108.GA20996@atrey.karlin.mff.cuni.cz> References: <200304091700.KAA02391@morrowfield.regexps.com> <20030409201133.GA10713@atrey.karlin.mff.cuni.cz> <200304092111.OAA03390@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304092111.OAA03390@morrowfield.regexps.com> User-Agent: Mutt/1.3.28i Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! > Anyway; yes I agree it is important for s-patch to support > applying to NOT_ORIG; but I do not believe we have to > describe exact algorithms how to do it. Of course it > should be deterministic etc, but I believe that we should > define spatch format first, and then create few (possibly > quite different) impelemntations of spatch binary. > > For example for some revision-control systems you might > want spatch that aborts when you try to apply over > NOT_ORIG, you'll want spatch that does "something > inteligent" when applying over NOT_ORIG, etc. > > Ok... looking quickly at the Posix spec for patch: they spec a minimal > behavior for inexact patching; that minimal behavior is parameterized > in a few interesting ways; implementations are permitted to do more. > > Then looking at `patch(1)' on my system, it in fact does a lot more, > and has a lot of additional parameters. > > That kind of spec: just a bare minimum of what's supposed to happen > (absent overriding parameters), plus the option for particular tools > to do whatever they like in addition to that, would satisfy me. Okay, that seems reasonable. Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. From pavel@atrey.karlin.mff.cuni.cz Wed Apr 9 17:48:43 2003 Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39Mmgbs014730 for ; Wed, 9 Apr 2003 17:48:43 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 182B54FCEE; Thu, 10 Apr 2003 00:48:42 +0200 (CEST) Date: Thu, 10 Apr 2003 00:48:42 +0200 From: Pavel Machek To: changesets@red-bean.com Subject: Using changesets to backup repository? Message-ID: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! I do not know if I'm asking too much from smart patch, but .... It would be nice to be able to export whole arch/svn/bk/whatever repository as a changeset, then import it into svn/arch/whatever and make that happen with no data loss. Process could be extremely ineffective; my point is that it would be nice if it was possible. [If changesets are human readable (and I think they should be) that would have nice implications for understanding what is going on, and for backups] Do you think it is possible to achive such goal? q Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. From lord@emf.net Wed Apr 9 18:36:14 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h39NaBbs015903 for ; Wed, 9 Apr 2003 18:36:12 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id QAA03994; Wed, 9 Apr 2003 16:45:52 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 16:45:52 -0700 (PDT) Message-Id: <200304092345.QAA03994@morrowfield.regexps.com> From: Tom Lord To: pavel@ucw.cz CC: changesets@red-bean.com In-reply-to: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> (message from Pavel Machek on Thu, 10 Apr 2003 00:48:42 +0200) Subject: Re: Using changesets to backup repository? References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Pavel Machek > > I do not know if I'm asking too much from smart patch, but .... It > would be nice to be able to export whole arch/svn/bk/whatever > repository as a changeset, then import it into svn/arch/whatever and > make that happen with no data loss. > > Process could be extremely ineffective; my point is that it would be > nice if it was possible. [If changesets are human readable (and I > think they should be) that would have nice implications for > understanding what is going on, and for backups] > > Do you think it is possible to achive such goal? That's more or less the point of this entire exercise. I think it's "sort of, but quite usefully" possible to do what you suggest, and with quibbles (which I'll omit) over the exact word choices in your description. Let me leave bk out of it for the moment. To use svn, you have to impose some structure over the raw capabilities. For example, the current recommendation is along the lines of creating a directory structure with "/trunk", "/branches", "/releases". Given that directory structure, you then use the branches and trunk and so forth according to certain recommended patterns. `arch' provides better "usage patterns" and a richer structure. >From the arch perspective, you can regard svn as a storage system that happens to make different trade-offs than larch's. Instead of "/trunk" ... you'd have a slightly different directory structure. And you'd have some conventions for the structure of source trees. And finally, some layered commands (basically an implementation of arch) on top of the lower-level svn commands. The svn usage patterns suggested by `arch' would, indeed, allow mirroring and distributed branching and so forth among a mix of svn and arch repositories. Not quite "with no loss of svn data", but "with no loss of important svn data". At the same time, it isn't just "arch with svn as back-end". The trade-offs that the svn storage manager makes mean that it's client can, in theory, do more than is required of a generic arch client. An arch-on-svn implementation can, possibly, have some interesting capabilities that would be harder in other implementations of arch (and vice versa). The two projects are, in some sense, potentially quite complementary. To what extent can this idea be extended to BK? I don't know. I try to remain willfully ignorant of some details of BK rather than risk raising even the hint of the question of litigation. (My hunch, btw, is that Larry M. doesn't much want to get into litigation either, but that he also has corporate responsibilities that mean he can't rule it out -- by _not_ making BK an object of detailed study, at least not at this stage of things, I'm actually, in some sense, cooperating with him :-) -t From willu@cse.unsw.edu.au Wed Apr 9 21:53:53 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3A2rnbs021327 for ; Wed, 9 Apr 2003 21:53:51 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Thu, 10 Apr 2003 12:53:37 +1000 From: William Uther To: Tom Lord Date: Thu, 10 Apr 2003 12:53:18 +1000 Subject: Re: changesets and variance adjusted patching Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@red-bean.com In-Reply-To: <200304091852.LAA02769@morrowfield.regexps.com> Message-Id: <9561CA08-6AFF-11D7-AEBD-000393CDF554@cse.unsw.edu.au> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom, I think your 'four trees needed for VAP' claim needs modification. On Thursday, April 10, 2003, at 04:52 AM, Tom Lord wrote: > For those who haven't read kfogel's document, let me try to sum up > v.a.p. briefly: > > We have four trees. Let's call these ANCESTOR, ORIG, MOD, TARGET. > > Conceptually, ORIG, MOD, and TARGET are all derived from ANCESTOR > ... ORIG and MOD on one branch, TARGET on another ... MOD is derived > from ORIG: > > > ANCESTOR > / \ > / \ > / TARGET > ORIG > | > | > MOD > > We want to merge some changes from the left branch into the right. > Specifically, we want to apply the changeset: > > > delta(ORIG, MOD) > > to TARGET. I really prefer to think in terms of one tree and two deltas. You need: ORIG, delta(ORIG, MOD) and delta(ORIG, TARGET) Often, instead of delta(ORIG, TARGET), you will have delta(ANCESTOR, ORIG), delta(ANCESTOR, TARGET). If you have reversible deltas then this is not a problem. If you do not have reversible deltas then you need ANCESTOR. However, those are implementation details behind finding delta(ORIG, TARGET). If you have that delta then you don't need anything else. > We could define notation for that "adjustments" algorithm -- > considering it to be a function that takes two changesets and returns > a third: > > > adjust(CS1, CS2) => CS3 > > where that means "adjust CS1 to be applied to a tree which differs > from the ORIG of CS1 by CS2". > > And then define the variance adjustment algorithm this way: > > > variance_adjust(ANC, ORIG, MOD, TGT) > > := adjust (adjust (delta (ORIG, MOD), delta (ORIG, ANC)), > delta (ANC, TGT)) I'd define it this way: variance_adjust(ORIG, MOD, TGT) := adjust (delta (ORIG, MOD), delta (ORIG, TGT)) Which becomes a little vacuous. The 'adjust' algorithm IS the vap algorithm. Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From lord@emf.net Wed Apr 9 22:11:54 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3A3Bqbs021812 for ; Wed, 9 Apr 2003 22:11:53 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id UAA04783; Wed, 9 Apr 2003 20:21:37 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 20:21:37 -0700 (PDT) Message-Id: <200304100321.UAA04783@morrowfield.regexps.com> From: Tom Lord To: willu@cse.unsw.edu.au CC: changesets@red-bean.com In-reply-to: <9561CA08-6AFF-11D7-AEBD-000393CDF554@cse.unsw.edu.au> (message from William Uther on Thu, 10 Apr 2003 12:53:18 +1000) Subject: Re: changesets and variance adjusted patching References: <9561CA08-6AFF-11D7-AEBD-000393CDF554@cse.unsw.edu.au> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: willu@cse.unsw.edu.au: > > [me:] > > > > And then define the variance adjustment algorithm this way: > > > > > > variance_adjust(ANC, ORIG, MOD, TGT) > > > > := adjust (adjust (delta (ORIG, MOD), delta (ORIG, ANC)), > > delta (ANC, TGT)) > > I'd define it this way: > > variance_adjust(ORIG, MOD, TGT) := adjust (delta (ORIG, MOD), delta > (ORIG, TGT)) > > Which becomes a little vacuous. The 'adjust' algorithm IS the vap > algorithm. First, it's worth noting that our two different definitions of variance_adjust will give different results in the general case. Mine reflects the definition in kfogel's docs -- yours is something different. Second, I agree that the adjust algorithm and variations on it are the essense -- the "do one thing well" core -- of diff4/v.a.p. Given a tool that does that, there are countless variations on kfogel's write-up, all giving potentially-interesting different results, and all expressable as function compositions of delta and adjust*. "diff48", anyone? -t From willu@cse.unsw.edu.au Thu Apr 10 01:08:14 2003 Received: from tone.orchestra.cse.unsw.EDU.AU (root@tone.orchestra.cse.unsw.EDU.AU [129.94.242.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3A68Cbs026429 for ; Thu, 10 Apr 2003 01:08:13 -0500 Received: From cse.unsw.edu.au ([129.94.174.16] == bunny.cse.unsw.EDU.AU) (for ) (for ) By tone With Smtp ; Thu, 10 Apr 2003 16:08:04 +1000 From: William Uther To: Tom Lord Date: Thu, 10 Apr 2003 16:07:51 +1000 Subject: Re: changesets and variance adjusted patching Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: changesets@red-bean.com In-Reply-To: <200304100321.UAA04783@morrowfield.regexps.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Thursday, April 10, 2003, at 01:21 PM, Tom Lord wrote: > > First, it's worth noting that our two different definitions of > variance_adjust will give different results in the general case. Mine > reflects the definition in kfogel's docs -- yours is something > different. I don't think so. Can you give an example of that? I actually gave an example of a binary version of the VAP algorithm on the svn-dev list a while back. It used VAP at the byte level, instead of at the line level. It was similar to your suggested VAP algorithm in that you could adjust the 'soft-conflict' zone around the changes. I can't find a reference to it - the svn list archives are hopeless. > Second, I agree that the adjust algorithm and variations on it are the > essense -- the "do one thing well" core -- of diff4/v.a.p. Given a > tool that does that, there are countless variations on kfogel's > write-up, all giving potentially-interesting different results, and > all expressable as function compositions of delta and adjust*. > "diff48", anyone? Ahh - I guess part of the issue here is that 'adjust' is not amazingly well defined. kfogel's document talks about text. We'd have to change that to handle trees. I'm assuming that most of these variations fall into the noise. Stay well, Will :-} -- Dr William Uther National ICT Australia Phone: +61 2 9385 6926 School of Computer Science and Engineering Email: willu@cse.unsw.edu.au University of New South Wales Jabber: willu@jabber.cse.unsw.edu.au Sydney, Australia From lord@emf.net Thu Apr 10 01:36:13 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3A6aAbs027253 for ; Thu, 10 Apr 2003 01:36:11 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id XAA05526; Wed, 9 Apr 2003 23:46:14 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Wed, 9 Apr 2003 23:46:14 -0700 (PDT) Message-Id: <200304100646.XAA05526@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: willu@cse.unsw.edu.au In-reply-to: (message from William Uther on Thu, 10 Apr 2003 16:07:51 +1000) Subject: Re: changesets and variance adjusted patching References: Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Thursday, April 10, 2003, at 01:21 PM, Tom Lord wrote: > > First, it's worth noting that our two different definitions of > variance_adjust will give different results in the general case. Mine > reflects the definition in kfogel's docs -- yours is something > different. willu: I don't think so. Can you give an example of that? I'm kinda sorta approaching sleepiness at the moment ... so i'll tell you how to figure out an example for yourself and give you the general principles. And if that doesn't do it for you, we can (perhaps) take it up again tomorrow. The basic issue is that diff-generated patches are not algebraic. They're kinda-sorta-algebraic, but not really. Let's suppose we have a function: compase_patches(P1, P2) => P3 satisfying (in the obvious way), that: compose_patches( delta (A, B), delta (B, C) ) [A] => C ("The compose of patches from A to B and from B to C, applied to A, gives C") That's fine -- but what we don't have is: # false, in the general case # compose_patches( delta (A, B), delta (B, C) ) == delta (A, C) In other words, there are multiple changesets, CS, such that: CS [A] == C and, in the general case, deriving a CS from a compose of A->B and B->C will yield a different result than just taking the diff A->C. As a consequence of that, and kfogel's (implicit) definition of adjust: # false, in the general case # adjust(delta (B, C), adjust( delta(A, B), Z)) == adjust (delta (A, C), Z) To generate a concrete example, in terms of ANCESTOR, ORIG, MOD, TARGET -- imagine a case where the changes in ANCESTOR...ORIG delete lots of lines, and ANCESTOR...TARGET add lots of lines in the same range. If the number of lines added/deleted is large enough, then you'll get your example -- or for versions of diff that sacrifice performance for minimal changes, if the lines added/deleted are tricky enough. Ahh - I guess part of the issue here is that 'adjust' is not amazingly well defined. kfogel's document talks about text. We'd have to change that to handle trees. I'm assuming that most of these variations fall into the noise. For text files -- as a function defined on ordinary context diffs -- kfogel's informal definition looks to me to be perfectly well defined; it's just that it's a very problematic definition to consider using in practice. This is actually why the idea of diff48 makes a little bit of sense. Supposing we have a version tree: ancestor / \ t:1 b:1 / \ t:2 b:2 / \ t:3 b:3 / t:4 In general, the changeset: adjust (delta (ancestor, b:3), adjust (delta (t:3, ancestor), delta (t:3, t:4))) != adjust (delta (ancestor, b:3), adjust (delta (t:1, ancestor), adjust (delta (t:3, t:1), delta (t:3, t:4)))) != adjust (delta (ancestor, b:3), adjust (delta (t:1, ancestor), adjust (delta (t:2, t:1), adjust (delta (t:3, t:2), delta (t:3, t:4))))) etc. and the longer formulas there may very well yield a more "reasonable" output. -t From mass@akuma.org Thu Apr 10 01:52:22 2003 Received: from mail.aspect.net (adsl-65-69-210-161.dsl.hstntx.swbell.net [65.69.210.161]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3A6qMbs027703 for ; Thu, 10 Apr 2003 01:52:22 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.aspect.net (Postfix) with ESMTP id BA13C1FF12; Thu, 10 Apr 2003 01:52:21 -0500 (CDT) Received: from mail.aspect.net ([127.0.0.1]) by localhost (pavia.aspect.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21291-01; Thu, 10 Apr 2003 01:51:58 -0500 (CDT) Received: from akuma.org (12-253-230-167.client.attbi.com [12.253.230.167]) by mail.aspect.net (Postfix) with ESMTP id 90EBC1788B; Thu, 10 Apr 2003 01:51:57 -0500 (CDT) Message-ID: <3E95148A.5030800@akuma.org> Date: Thu, 10 Apr 2003 00:51:54 -0600 From: David Waite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lord Cc: changesets@red-bean.com Subject: Re: Goals References: <3E92474D.4060009@akuma.org> <200304090238.TAA29739@morrowfield.regexps.com> <3E93C406.3070008@akuma.org> <200304091752.KAA02480@morrowfield.regexps.com> In-Reply-To: <200304091752.KAA02480@morrowfield.regexps.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030314-p1 (Debian) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom Lord wrote: >Ok.... some new and refined goals come out of: > > David Waite (replies taken slightly out of order): > > > > the output and handling of > > > delta(ORIG, MOD)[NOTORIG] > > > shouldn't be part of the changeset format. > >If you think of us as working towards writing formal specs, then I'd >say we're talking about: > >(a) a spec for what the `diff' replacement does >(b) a spec for the output format of `diff' >(c) a spec for what the `patch' replacement does > >and probably also additional things like: > >(d) a spec for what the `v.a.p.' tools do, in terms of > of (a), (b), and (c). > >(e) a spec for what a `compose_changesets' tool does > >etc. > >I realize that that sounds like possible "goals bloat". Only (a), >(b), and (c) are necessary for revctl system interop (not quite >sufficient, but necessary). Contemplating (d), (e) and so forth >early can help us do a better job on (a)..(c) and, given (a)..(c), >those other tasks should be pretty easy. > I agree that any specification needs at least one reference implementation before it really can be said to be 'ready' for consumption. My only point above is that the spec for the 'patch' replacement (c) should not include or require (d), since algorithms for the delta(ORIG, MOD)[NOTORIG] case may be content-type specific. What is the difference between the 'diff' replacement and the 'compose_changesets' tool? > > [....] > > [On recording ORIG and MOD identifiers in changesets.] > > > There are two different concepts here - a unique identifier used for > > distinguishing a particular ORIG fileset or MOD changeset, and > > a URL for locating the 'home' of that fileset or changeset. > >Yup. > >Those "unique identifiers" are, imo, going to be critical for >interoperable distributed revision control. I think defining what >they might be is larger in scope than changesets, and that the >changeset format itself need not know anything specific about them. > >So we should have a format that allows those ids to be recorded, but >not get too hung up on what they mean at this stage. > I agree. Lets assume for now that based on whatever the contents are those recorded ids, the environment which is processing the changeset can interpret them correctly. > > Basically, a unified/context diff isn't always the best format > > for representing files, [...] (some xml formats, binary) [...] > > > [....] > > > If it is a goal that the changeset be representable using as > > much human-readable text as possible and/or that a minimal > > amount of work is needed for a subset of the changeset to be > > applied using 'patch', then I see both context-format diff and > > some binary diff being requirements. > > >Just in general, we should perhaps aim for extensibility in the file >diff and file patch functions. > >That's tricky because we have no apriori way to recognize which diff >tools to apply to what files. `diff' itself has the "binary file >detection" hack, but I wouldn't mind something more precise and more >general than that. > >One idea is to make that "diff type" attribute of files a part of the >inventory tag for the file. When a user or tool creates a new >inventory tag, recording the diff type of a file can be part of that >process. > My requirements are based on ORIG being known to those applying the changeset. As long as my 'patch' replacement can understand the representation of a file content change, I can generate the NEW being inferred by the changeset, and then use whatever local algorithm I want to analyse and apply the differences. Thus, I am more concerned that the content change formats be defined and limited (for interoperability). Without the guarantee that the recipient of MOD can retrieve ORIG, some manner of context needs to be in the changeset itself. One possible solution is to include the subset of ORIG corresponding to files referenced in MOD. Another is the traditional diff-with-context - but that will only work on a subset of possible data formats. There is no total solution for representing the context of a content change within a changeset for all filetypes. > > Assuming (and very much hoping) that the graph is directed > > acyclic, an order can be determined in which to apply > > changes. Indeed, chronological order is the most probable > > ideal for writing out the sub-changeset. The question: whether > > the optional mechanism to describe the dependancy graph is a > > goal. Without the dependancy graph described, it is assumed > > that the graph winds up being a straight line through each > > changeset in order. > >If I have a totally ordered ("straight line") set of changes, an >external tool can look at that and find the less-restrictive DAG of >actual textual dependencies -- the DAG is implicit in the combined >total ordering plus sub-changeset elements like hunk offsets. > >I don't see a need to more explicitly surface the textual DAG in the >changeset format -- indeed it seems undesirable to require >changeset-generation tools to _have_ to do that computation when it >can just as easily be done by changeset-receiving tools, only some of >which need the DAG anyway. > Is the problem that I said that the graph should be assumed to be a straight line, when really nothing should be assumed? I'm sure we both agree that a changeset generation tool should not have to generate a DAG, just that it may be already known and important to serialize into the changeset. > > The other portion is describing a bit of the logical structure: a > > changeset contains either child changesets or changes, where changes > > express either a single structural or content change - creation of a > > file, modification of a file, moving of a directory. It would > > probably be simpler to describe the structure holding child > > changesets and the structure holding changes with different > > names :-) > >I sense that you want "primitive" changesets in this arrangement to >not do more than, say, rename a single file. > >I think that restriction is undesirable. Rather, primitive >changesets should permit arbitrary rearrangements of sets of files. > >Consider the simple case of swapping the location of two files. >With arbitrary rearrangements, that's a single changeset that says >something like: "after this change, A is called B and B is called A". > >With single-rename primitives, you'd need three changes: "(1) A is >called TMP; (2) B is called A; (3) TMP is called B." > Actually, that would still be order-dependant. Lets say one (very inefficient) algorithm for applying the changeset to file set ORIG in directory ./ORIG is to create a directory ./NEW and to recreate the files within set ORIG in that dir. The lack of a file content change means the file contents were not altered; the lack of a tree change indicates the file did not move. In this sort of setup, it is easy to see that a pair of (filename A -> B', filename B -> A') changes can be represented, and that no particular order is needed to evaluate these changes. Assuming the patch replacement tool works in-place, it will have to know that there will be a filename conflict and use an intermediate temporary file during the move. (Using 'set of changes' to keep from getting confused about the possibility of grouped changesets, ) I'm more concerned about having a single set of changes which alters the same file multiple times, or changes the name of file A to B and then C. The primitive changes should be grouped so that there isn't an intradependancy. Now, one case that could conflict is moving A to B, and creating a new A in the same set of changes. One solution for this is to have a 'create' primitive represent both a tree change and content change; both a 'patch' representing the full new file without name, and a move to its real name. Same deal with a deletion. -David Waite From lord@emf.net Thu Apr 10 02:36:45 2003 Received: from morrowfield.regexps.com (11Cust180.tnt13.sfo8.da.uu.net [65.234.195.180]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3A7agbs028742 for ; Thu, 10 Apr 2003 02:36:43 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id AAA05705; Thu, 10 Apr 2003 00:46:43 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Thu, 10 Apr 2003 00:46:43 -0700 (PDT) Message-Id: <200304100746.AAA05705@morrowfield.regexps.com> From: Tom Lord To: mass@akuma.org CC: changesets@red-bean.com In-reply-to: <3E95148A.5030800@akuma.org> (message from David Waite on Thu, 10 Apr 2003 00:51:54 -0600) Subject: Re: Goals References: <3E92474D.4060009@akuma.org> <200304090238.TAA29739@morrowfield.regexps.com> <3E93C406.3070008@akuma.org> <200304091752.KAA02480@morrowfield.regexps.com> <3E95148A.5030800@akuma.org> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: David Waite > >[me:] > >I don't see a need to more explicitly surface the textual DAG in the > >changeset format -- indeed it seems undesirable to require > >changeset-generation tools to _have_ to do that computation when it > >can just as easily be done by changeset-receiving tools, only some of > >which need the DAG anyway. > > > Is the problem that I said that the graph should be assumed to be a > straight line, when really nothing should be assumed? I'm sure we both > agree that a changeset generation tool should not have to generate a > DAG, just that it may be already known and important to serialize into > the changeset. There's no problem. A "composite" or "recursive" changeset is likely to imply a total order of its components. For example, if serialized as a text stream -- the order of components in that stream is a total order. Textually, there is a partial order among components. Overlapping hunks of text patches in two components must be applied in some definate order --- but which order? A or B, or B or A? All I meant is that a natural view is that if the textual partial order requires A,B, then in the total order A Actually, that would still be order-dependant. Lets say one (very > inefficient) algorithm for applying the changeset to file set ORIG in > directory ./ORIG is to create a directory ./NEW and to recreate the > files within set ORIG in that dir. The lack of a file content change > means the file contents were not altered; the lack of a tree change > indicates the file did not move. In this sort of setup, it is easy to > see that a pair of (filename A -> B', filename B -> A') changes can be > represented, and that no particular order is needed to evaluate these > changes. Assuming the patch replacement tool works in-place, it will > have to know that there will be a filename conflict and use an > intermediate temporary file during the move. Then we're (approximately) talking about isomorphic solutions in different terms. You seem to want to introduce some notion of "primitive changeset" that I think is needlessly primitive. > (Using 'set of changes' to keep from getting confused about the > possibility of grouped changesets, ) I'm more concerned about having a > single set of changes which alters the same file multiple times, or > changes the name of file A to B and then C. The primitive changes should > be grouped so that there isn't an intradependancy. > > Now, one case that could conflict is moving A to B, and creating a new A > in the same set of changes. One solution for this is to have a 'create' > primitive represent both a tree change and content change; both a > 'patch' representing the full new file without name, and a move to its > real name. Same deal with a deletion. The arch changeset format handles such problems quite well, using a solution quite unlike what you describe. As I mentioned a little while ago, I'm getting sleepy -- if you're feeling like digging in to the issue, you could do worse than grab the arch source code and start reading src/arch/patch-sets. -t From fog@initd.org Thu Apr 10 14:03:37 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3AJ3abs015321 for ; Thu, 10 Apr 2003 14:03:37 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id D14CF3C081; Thu, 10 Apr 2003 20:48:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id E4D281A2B8 for ; Thu, 10 Apr 2003 21:02:42 +0200 (CEST) Subject: Re: Goals From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <200304091752.KAA02480@morrowfield.regexps.com> References: <3E92474D.4060009@akuma.org> <200304090238.TAA29739@morrowfield.regexps.com> <3E93C406.3070008@akuma.org> <200304091752.KAA02480@morrowfield.regexps.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wTaNapTfC3HDYNPbEf7A" Organization: init.d Message-Id: <1050001362.891.4.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 10 Apr 2003 21:02:42 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-wTaNapTfC3HDYNPbEf7A Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mer, 2003-04-09 alle 19:52, Tom Lord ha scritto: > Consider the simple case of swapping the location of two files. > With arbitrary rearrangements, that's a single changeset that says > something like: "after this change, A is called B and B is called A". >=20 > With single-rename primitives, you'd need three changes: "(1) A is > called TMP; (2) B is called A; (3) TMP is called B." nah. the changeset just need to say: A -> B B -> A this is enough information for spatch to understand it should swap the files. --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org All programmers are optimists. -- Frederick P. Brooks, Jr. --=-wTaNapTfC3HDYNPbEf7A Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+lb/SvcCgrgZGjesRAj9GAJ0WYgqwPf0g3MY5rft1boulsqms2ACdGIau 8ohd+Sc5pY1I9ZSWhKXV0Mk= =0RIo -----END PGP SIGNATURE----- --=-wTaNapTfC3HDYNPbEf7A-- From pavel@atrey.karlin.mff.cuni.cz Thu Apr 10 14:35:52 2003 Received: from atrey.karlin.mff.cuni.cz (postfix@atrey.karlin.mff.cuni.cz [195.113.31.123]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3AJZpbs016309 for ; Thu, 10 Apr 2003 14:35:52 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id B5C304FD6D; Thu, 10 Apr 2003 21:35:49 +0200 (CEST) Date: Thu, 10 Apr 2003 21:35:49 +0200 From: Pavel Machek To: Tom Lord Cc: pavel@ucw.cz, changesets@red-bean.com Subject: Re: Using changesets to backup repository? Message-ID: <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304092345.QAA03994@morrowfield.regexps.com> User-Agent: Mutt/1.3.28i Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! > > From: Pavel Machek > > > > I do not know if I'm asking too much from smart patch, but .... It > > would be nice to be able to export whole arch/svn/bk/whatever > > repository as a changeset, then import it into svn/arch/whatever and > > make that happen with no data loss. > > > > Process could be extremely ineffective; my point is that it would be > > nice if it was possible. [If changesets are human readable (and I > > think they should be) that would have nice implications for > > understanding what is going on, and for backups] > > > > Do you think it is possible to achive such goal? > > That's more or less the point of this entire exercise. Good. [It might make things quite complicated, through, because that means that one "changesets" may carry 3 independend branches, and whole 4-th branch along with info how it was merged into branch #3. I guess it is a bit more complicated than patch-NG, then.] Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. From pavel@bug.ucw.cz Thu Apr 10 17:13:35 2003 Received: from Elf.ucw.cz (postfix@[195.39.17.254]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3AMDEbs021125 for ; Thu, 10 Apr 2003 17:13:33 -0500 Received: from bug.ucw.cz (bug.ucw.cz [10.0.0.3]) by Elf.ucw.cz (Postfix) with ESMTP id 37880C345A; Thu, 10 Apr 2003 00:11:17 +0200 (CEST) Received: (from pavel@localhost) by bug.ucw.cz (8.8.8/8.8.5) id AAA00362; Thu, 10 Apr 2003 00:11:11 +0200 Date: Thu, 10 Apr 2003 00:11:10 +0200 From: Pavel Machek To: Tom Lord Cc: changesets@sanpietro.red-bean.com Subject: Re: svn questions & towards a spec Message-ID: <20030409221110.GB346@elf.ucw.cz> References: <200304081950.MAA28306@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304081950.MAA28306@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-Warning: Reading this can be dangerous to your mental health. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! > * Windows v. UNIX path separator ... > (c) has an additional severe drawback. It presumes that > inventory lists are always and only processed by tools which > know they are inventory lists. For example, in the general > case, a simple tool like `cmp' could not be relied on to > compare two files that happened to include inventory lists > in their contents. > > Finally, (c) raises the question: can \ and / be > mixed in the same inventory list? > > By process of elimination, I'm inclined towards (a). Seems reasonable. [Windows might introduce another problems: you can't have both Makefile and makefile in one directory on Windows.] > * Filename Character Set ... > (a) Filename components are strings of bytes > which changeset tools should compare and > collate as strings of bytes. (User interface > tools are, of course, free to present a > different interpretation in their displays > and input processing.) At minimum, it needs to say that 000 is end-of-filename. It might be god to say that filenames are encoded in utf-8. > (d) file "signatures" or "fingerprints" as tag > > It sure would be nice if an implementation of `inventory_tag' > could somehow _guess_ the tag for a file just by examining > the tree -- with no explicit record of a tag needed at all. > > For example, the tag of a .c file might be the concatenated > names of the symbols it exports. > > Unfortunately, such fingerprinting seems to me to be both > hoplessly fragile, and too computationally expensive. Well, if you need something like signature(file) -> max-200-bytes yes, it is going to be fragile. But if you can base it on is_same_file(file1, file2) -> true/false I guess it could be made reasonably robust. It still does not look like good idea, through. Pavel -- When do you have heart between your knees? From pavel@bug.ucw.cz Thu Apr 10 17:13:35 2003 Received: from Elf.ucw.cz (postfix@[195.39.17.254]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3AMDFbs021129 for ; Thu, 10 Apr 2003 17:13:33 -0500 Received: from bug.ucw.cz (bug.ucw.cz [10.0.0.3]) by Elf.ucw.cz (Postfix) with ESMTP id 86C38C3459; Thu, 10 Apr 2003 00:06:36 +0200 (CEST) Received: (from pavel@localhost) by bug.ucw.cz (8.8.8/8.8.5) id AAA00354; Thu, 10 Apr 2003 00:06:28 +0200 Date: Thu, 10 Apr 2003 00:06:26 +0200 From: Pavel Machek To: Federico Di Gregorio Cc: changesets@sp.red-bean.com Subject: Re: Our goals Message-ID: <20030409220626.GA346@elf.ucw.cz> References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> <3E92B0BD.4040204@comsys.se> <20030408133436.GA11307@iucha.net> <3E92D43D.10201@comsys.se> <20030408145039.GF3037@pasky.ji.cz> <1049821613.1105.14.camel@momo.initd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1049821613.1105.14.camel@momo.initd.org> User-Agent: Mutt/1.4i X-Warning: Reading this can be dangerous to your mental health. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! > [3 goals snipped] > > i completely agree on the stated goals. > > > I think it is important to assume as little about the spatch user capabilities > > as possible (in the 1, and 2, part). Revision numbers may not be suitable > > unique identifiers, for example. You should not need _ANY_ version control upon > > the tree you want to apply spatch on. You can lose some nice capabilities (ie. > > you have less immunity against file renames by absence of tags tracking), but > > you can still apply the patch and resolve only reasonably little (relatively) > > number of conflicts. That is also why file names should be always carried along > > the tags. > > perfect, imho. (btw eva metapatch already work that way, first tags, > then paths, then complains.) > > talking about patch format i push toward a MIME-like envelope containing > headers (path, tag, patch id, metadata, etc) that can be extended by > specific tools and a "payload" (the body) containing patch delta. > > if anyone is interested i can send to this list a spatch between last > night eva snapshot and today work (generated by "eva metapatch diff"), > MIME encoded, that can be applied by cat-ing it to "eva metapatch > patch".) it shows how MIME encoded patches can be safetly exanged by > email, be human readable and easy to apply. Please do so. Pavel -- When do you have heart between your knees? From fog@initd.org Fri Apr 11 02:55:36 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3B7tYbs004282 for ; Fri, 11 Apr 2003 02:55:35 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id A55C63C07D; Fri, 11 Apr 2003 09:40:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 9F6C21A335; Fri, 11 Apr 2003 09:54:29 +0200 (CEST) Subject: Re: Our goals From: Federico Di Gregorio To: Pavel Machek Cc: changesets@sp.red-bean.com In-Reply-To: <20030409220626.GA346@elf.ucw.cz> References: <3E929B1D.3080306@comsys.se> <1049796735.3095.131.camel@momo.initd.org> <3E92B0BD.4040204@comsys.se> <20030408133436.GA11307@iucha.net> <3E92D43D.10201@comsys.se> <20030408145039.GF3037@pasky.ji.cz> <1049821613.1105.14.camel@momo.initd.org> <20030409220626.GA346@elf.ucw.cz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L77VAhcNq5paXTbVaH9s" Organization: init.d Message-Id: <1050047669.902.8.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 11 Apr 2003 09:54:29 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-L77VAhcNq5paXTbVaH9s Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il gio, 2003-04-10 alle 00:06, Pavel Machek ha scritto: > > if anyone is interested i can send to this list a spatch between last > > night eva snapshot and today work (generated by "eva metapatch diff"), > > MIME encoded, that can be applied by cat-ing it to "eva metapatch > > patch".) it shows how MIME encoded patches can be safetly exanged by > > email, be human readable and easy to apply. >=20 > Please do so. ok. my next mail will be generated by: emp diff --to changesets@sp.red-bean.com ../eva-20030408 . where is a file list of 2-3 item, just to keep the patch small.. ciao, federico =20 --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org One key. One input. One enter. All right. -- An american consultant (then the system crashed and took down the *entire* network) --=-L77VAhcNq5paXTbVaH9s Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+lnS1vcCgrgZGjesRAuTZAKDR7RsFdwa4HYV2ZH+rDwWq+kQecgCcDBWp 7kGCx/HzkL8fghDDuwGDvxw= =gwK5 -----END PGP SIGNATURE----- --=-L77VAhcNq5paXTbVaH9s-- From fog@initd.org Fri Apr 11 03:23:36 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3B8NZbs005089 for ; Fri, 11 Apr 2003 03:23:35 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id C79D33C0AE; Fri, 11 Apr 2003 10:08:54 +0200 (CEST) Received: from momo.initd.org (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id A0ABF1A335 for ; Fri, 11 Apr 2003 10:22:39 +0200 (CEST) Content-Type: multipart/mixed; boundary="===============42461812962915002==" MIME-Version: 1.0 From: fog@initd.org To: changesets@red-bean.com Subject: patch set: eva-20030406.tar.gz vs eva Message-Id: <20030411082239.A0ABF1A335@momo.initd.org> Date: Fri, 11 Apr 2003 10:22:39 +0200 (CEST) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --===============42461812962915002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Creator: Federico Di Gregorio Date: Fri, 11 Apr 2003 08:22:39 +0000 Summary: example of s-patch generated by eva New-files: eva/commands/metapatch/changes.py Modified-files: ChangeLog NEWS eva/inventory/inventory.py This is a MIME encoded patch generated by the command: emp diff --to changesets@red-bean.com eva-20040406.tar.gz eva (plus a list of files to send just a little patch to the list and not the whole work of 2-3 days of hacking.) eva metapatch (emp) diff command is able to compare a tar or zip archive with the working directory and generate a patch set as a single MIME ancoded file or as a set (flat directory, zip or tar archive) of single patches. "emp patch" can apply any patch set generated by diff so you can, for example, directly pipe the MIME email containing the patches from your MUA into it. :) patch sets are generated by comparing the files (slow) or by using logical names, keept in separate file (manifest) and a "tags cache". for more information about eva, download last snapshot from: http://initd.org/pub/software/eva/ hope you liked this example, federico --===============42461812962915002== Content-Type: multipart/meta-patch; boundary="===============9733206800935863==" MIME-Version: 1.0 X-Metapatch-From: *nowhere* X-Metapatch-To: eva/commands/metapatch/changes.py X-Metapatch-Tag: FSn/changes.py/1509.1050048146.392.3146 X-Metapatch-Format: application/diff X-Metapatch-Name: 0000.eva-patch.2225.1050049359.479.6348 --===============9733206800935863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-disposition: attachment; filename="eva/commands/metapatch/changes.py.diff" --- *nowhere* 1970-01-01 00:00:00 +0000 +++ eva/commands/metapatch/changes.py 2003-04-06 20:45:52 +0000 @@ -0,0 +1,93 @@ +# -*- Mode: python -*- +# +# commands/emp/changes.py - see what has changed in the tree +# +# Copyright (C) 2002-2003 Federico Di Gregorio , +# Copyright (C) 2002 Jack Moffitt +# +# This file is part of eva. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by the +# Free Software Foundation; either version 2, or (at your option) any later +# version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTIBILITY +# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# for more details. + +from optparse import OptionParser +from os.path import join + +from eva.output import output + +from eva.inventory.inventory import * +from eva.inventory.manifest import Manifest + +from eva.common import options +from eva.common.fs import findpath +from eva.command import PythonCommand, EvaCommandError + + +def _changes(user, args): + """Parse options and then display changes.""" + opts, args = options.parse_with_common_args(parser, args[1:], user.log) + + out = output.Output() + + ## option parsing and sanity checks ## + if len(args) != 0: + raise EvaCommandError("wrong number of arguments") + + # FIXME: right now we simply force manifest operations to not recurse + opts.dont_recurse = True + + ## step 1: find the manifest + default_manifest = join('{eva}', 'manifest') + parent, manifest = findpath(default_manifest) + + if not manifest: + user.log.error('There is no manifest file.') + return 1 + + mft = Manifest(user, manifest) + inv = Inventory(user, parent) + inv.inventory(recurse_nested=False) + deleted, added, modified = inv.update_manifest(mft) + + if deleted: + out.writeln("Deleted files:") + for e in deleted: + out.writeln(e.canonical) + out.writeln('') + + if added: + out.writeln("Added files:") + for e in added: + out.writeln(e.canonical) + out.writeln('') + + + if modified: + out.writeln("Modified files:") + for e, old in modified: + if old: + out.writeln("%s -> %s" % (old.canonical, e.canonical)) + else: + out.writeln(e.canonical) + out.writeln('') + + return 0 + + + +name = 'changes' +aliases = [] +description = 'Show what has changed in the tree' +command = PythonCommand(name, description, aliases, _changes) + +## option parser ## + +parser = OptionParser(usage="changes [options]") +options.add_common_options(parser) --===============9733206800935863==-- --===============42461812962915002== Content-Type: multipart/meta-patch; boundary="===============72539203743420688==" MIME-Version: 1.0 X-Metapatch-From: ChangeLog X-Metapatch-To: ChangeLog X-Metapatch-Tag: FSn/ChangeLog/2225.1050048908.891.4975 X-Metapatch-Format: application/diff X-Metapatch-Name: 0001.eva-patch.2225.1050049359.502.4695 --===============72539203743420688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-disposition: attachment; filename="ChangeLog.diff" --- ChangeLog 2003-04-05 23:38:59 +0000 +++ ChangeLog 2003-04-07 23:29:10 +0000 @@ -1,5 +1,26 @@ +2003-04-08 Federico Di Gregorio + + * README: added ML and IRC reference. + +2003-04-06 Jack Moffitt + + * eva/commands/metapatch/changes.py: implemented 'emp changes' + command to view changes in the current tree. + 2003-04-06 Federico Di Gregorio + * eva/format/report.py (Report.read): now does try to fix body + formatting but just treat it as a single big string with embedded + newlines. (Report.generate): truncate buffer at 0 before + generating to avoid double-generation. + + * eva/commands/metapatch/diff.py: a little euristic to locate + manifest and use it by default if availavle; added --no-amnifest + option. + + * eva/patch/patchset.py (PatchSet.prepare_set): filters modified + to use right entries when given manifest. + * eva/commands/emp/patch.py: only generated patch application report is patch set does not applies perfectly well. --===============72539203743420688==-- --===============42461812962915002== Content-Type: multipart/meta-patch; boundary="===============2122024376877476==" MIME-Version: 1.0 X-Metapatch-From: NEWS X-Metapatch-To: NEWS X-Metapatch-Tag: FSn/NEWS/2225.1050048908.897.24889 X-Metapatch-Format: application/diff X-Metapatch-Name: 0002.eva-patch.2225.1050049359.524.23787 --===============2122024376877476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-disposition: attachment; filename="NEWS.diff" --- NEWS 2003-04-04 22:20:33 +0000 +++ NEWS 2003-04-06 10:47:38 +0000 @@ -1,10 +1,12 @@ -Snapshot 20030405 +Snapshot 20030406 ----------------- * "emp diff" now takes some extra parameters (--message, --keywords, --summary) used to generate a better patch generation report and launches the editor if summary is not provided. +* "emp patch" can now take MIME encoded patches from stdin. + Snapshot 20030403 ----------------- --===============2122024376877476==-- --===============42461812962915002== Content-Type: multipart/meta-patch; boundary="===============74813336744308534==" MIME-Version: 1.0 X-Metapatch-From: eva/inventory/inventory.py X-Metapatch-To: eva/inventory/inventory.py X-Metapatch-Tag: FSn/inventory.py/2225.1050048908.824.2758 X-Metapatch-Format: application/diff X-Metapatch-Name: 0003.eva-patch.2225.1050049359.545.29284 --===============74813336744308534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-disposition: attachment; filename="eva/inventory/inventory.py.diff" --- eva/inventory/inventory.py 2003-04-05 18:34:06 +0000 +++ eva/inventory/inventory.py 2003-04-06 23:43:11 +0000 @@ -31,7 +31,7 @@ from os import listdir, lstat, sep, makedirs from os.path import isdir, isfile, islink, join, abspath, \ - basename, dirname, exists, normpath + basename, dirname, exists, normpath, sep from stat import * import sha, re @@ -529,12 +529,37 @@ ## basic entries management ## + def _findpath(self, stack, inv): + """Recursive method for `findpath`.""" + name = stack.pop(0) + for e in inv._entries: + if e.name == name: + if stack: + if e.isdir(): + return self._findpath(stack, e.inv) + else: + return e + + def findpath(self, path): + """Locate entry at `path` in sub-inventories. + + This method goes down the inventory tree and return the entry + corresponding to `path` or None if path is not a valid path. + """ + stack = filter(lambda x: x, path.split(sep)) + entry = self._findpath(stack, self) + return entry + + def findparent(self, entry): + """Return parent of given entry or None.""" + return self.findpath(dirname(entry.canonical)) + def make_entry(self, path, tags=None, regexps=None, fk=None): """Make a new entry. - This method is particularbecause can be used to make non-standard + This method is particular because can be used to make non-standard entries by passing it a complete path. Used when just an `entry`is - required and a full `inventory()` callwould be too much. + required and a full `inventory()` call would be too much. """ if regexps is None: regexps = self._read_kinds(self.kinds_file(), self._regexps) @@ -543,14 +568,27 @@ return Entry(join(self.abspath, path), self.top, tags, regexps, fk=fk) + def checkentry(self, entry): + """Check if `entry`is compatible with this inventory.""" + sc = self.makecanonical("") + ec = dirname(entry.canonical) + if sc != ec: + e = "wrong parent:\n inventory: %s\n entry: %s" + raise EvaInventoryError(e & (sc, ec)) + def add(self, entry): - """Ad an `entry` to this inventory.""" - self._entries.append(entry) - self._entries.sort() + """Add an `entry` to this inventory.""" + self.checkentry(entry) + if entry not in self._entries: + self._entries.append(entry) + print "added:", entry def remove(self, entry): """Remove an `entry` from this directory.""" - self._entries.remove(entry) + self.checkentry(entry) + if entry not in self._entries: + self._entries.remove(entry) + print "removed:", entry def rename(self, entry, name): """Rename `entry` to make it ready for addition to self.""" @@ -562,6 +600,17 @@ regexps = self._read_kinds(self.kinds_file(), self._regexps) entry.retag(path, regexps, me, fk) + def reparent(self, entry): + """Find the natural parent of `entry` and then add to it.""" + if entry in self._entries: + self._entries.remove(entry) + inv = self.findpath(dirname(entry.canonical)) + if not inv: + e = "can't reparent entry; no parent:\n " + raise EvaError(e + entry.canonical) + inv.rename(entry, entry.name) + inv.add(entry) + ## quasi-commands ## def inventory(self, fk=None, recurse_nested=True, dont_recurse=False): --===============74813336744308534==-- --===============42461812962915002==-- From fog@initd.org Fri Apr 11 03:29:34 2003 Received: from firenze.linux.it ([195.110.124.18]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3B8TYbs005227 for ; Fri, 11 Apr 2003 03:29:34 -0500 Received: by firenze.linux.it (Postfix, from userid 10) id 3D9C83C0AE; Fri, 11 Apr 2003 10:14:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by momo.initd.org (Postfix) with ESMTP id 96D791A335 for ; Fri, 11 Apr 2003 10:28:03 +0200 (CEST) Subject: Re: patch set: eva-20030406.tar.gz vs eva From: Federico Di Gregorio To: changesets@sp.red-bean.com In-Reply-To: <20030411082239.A0ABF1A335@momo.initd.org> References: <20030411082239.A0ABF1A335@momo.initd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PtIJnANbdSfLb1ocM46K" Organization: init.d Message-Id: <1050049683.902.19.camel@momo.initd.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 11 Apr 2003 10:28:03 +0200 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: --=-PtIJnANbdSfLb1ocM46K Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il ven, 2003-04-11 alle 10:22, fog@initd.org ha scritto: > Creator: Federico Di Gregorio > Date: Fri, 11 Apr 2003 08:22:39 +0000 > Summary: example of s-patch generated by eva > New-files: eva/commands/metapatch/changes.py > Modified-files: ChangeLog NEWS eva/inventory/inventory.py >=20 > This is a MIME encoded patch generated by the command: >=20 > emp diff=20 > --to changesets@red-bean.com eva-20040406.tar.gz eva [...] erm.. obviously the wrapping algorithm for the patch generation report still has some little problems (it should not wrapat all the body of the text but it does, sigh.) anyway, hope you liked the example, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer fog@debian.org INIT.D Developer fog@initd.org We are all dust, Saqi, so play the lute We are all wind, Saqi, so bring wine. -- Omar Khayam --=-PtIJnANbdSfLb1ocM46K Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+lnyTvcCgrgZGjesRAvn1AKCGjQHSpAwMzho55NRaXRvPywRnigCfRsa3 uxwo42w8dcW3HU3Cks5s5cw= =hUWu -----END PGP SIGNATURE----- --=-PtIJnANbdSfLb1ocM46K-- From pasky@machine.sinus.cz Sat Apr 12 05:47:33 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3CAlWbs011530 for ; Sat, 12 Apr 2003 05:47:33 -0500 Received: (qmail 24454 invoked by uid 2001); 12 Apr 2003 10:47:17 -0000 Date: Sat, 12 Apr 2003 12:47:17 +0200 From: Petr Baudis To: Tom Lord Cc: changesets@red-bean.com, striker@apache.org Subject: Re: changesets and variance adjusted patching Message-ID: <20030412104717.GF3037@pasky.ji.cz> References: <200304091852.LAA02769@morrowfield.regexps.com> <20030409215539.GU3037@pasky.ji.cz> <200304092230.PAA03713@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304092230.PAA03713@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Thu, Apr 10, 2003 at 12:30:51AM CEST, I got a letter, where Tom Lord told me, that... > > > me: > > >> Finally: that variation on v.a.p. brings us back to changset > >> design question: should the changeset format have a way to > >> indicate "soft conflicts", and if so, what should that > >> mechanism be? How will patch-tools treat soft conflicts? > > pasky: > > > That could be obviously an area where graphical > > patching/merging tools would excel, "normal" patch tools > > should at least provide a way to: > > Why should graphical and "normal" patching be so unrelated? They don't have to. I just wanted to say that graphical tools can provide visible superset of functionality here. > For modularity, and interoperability, I'd like graphical patching to > be layered over batch patching. That means that the output batch > patching should be machine parsable. Sure. > In traditional Posix patch, the -D (--ifdef in GNU) option comes > pretty close, with .rej files for recording conflicts. Unified diff is IMHO parsable well enough ;). > But those mechanisms need to be generalized for whole-tree patching > and could stand to be improved in some other ways as well. > > Standardizing those output formats, well enough for people to write > generic graphical patch tools, is yet another reason why some aspects > of inexact patching ought to be speced as part of the changeset > definition process. ... > > [normal patching should be able to] Output the adjusted > > patch instead of applying it. > > Outputting the variance adjusted patch ought to be the default for > variance adjustment tools. Applying it without explicitly generating > it is just a performance optimization -- one that is probably not all > that important. Sure, whatever. > "Simpler and fast enough" is almost always better than "Complicated as > hell, but slightly faster." Well, spatch -P -p0 ; Sat, 12 Apr 2003 06:53:11 -0500 Received: (qmail 26394 invoked by uid 2001); 12 Apr 2003 11:53:09 -0000 Date: Sat, 12 Apr 2003 13:53:09 +0200 From: Petr Baudis To: Pavel Machek Cc: Tom Lord , changesets@red-bean.com Subject: spatch hiearchy Message-ID: <20030412115309.GG3037@pasky.ji.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Thu, Apr 10, 2003 at 09:35:49PM CEST, I got a letter, where Pavel Machek told me, that... > > > From: Pavel Machek > > > > > > I do not know if I'm asking too much from smart patch, but .... It > > > would be nice to be able to export whole arch/svn/bk/whatever > > > repository as a changeset, then import it into svn/arch/whatever and > > > make that happen with no data loss. > > > > > > Process could be extremely ineffective; my point is that it would be > > > nice if it was possible. [If changesets are human readable (and I > > > think they should be) that would have nice implications for > > > understanding what is going on, and for backups] > > > > > > Do you think it is possible to achive such goal? > > > > That's more or less the point of this entire exercise. > > Good. [It might make things quite complicated, through, because that > means that one "changesets" may carry 3 independend branches, and > whole 4-th branch along with info how it was merged into branch #3. I > guess it is a bit more complicated than patch-NG, then.] Huh. I guess there is maybe a terminology problem here. I'd hiearchize it as: +--------------------------------------------------------------------+ | application | | | | (This may be a SCM, simple 'spatch' tool (not aware of any | | file revisions, branches etc) and so on.) | | | +--------------------------------------------------------------------+ | spatch | +----------------------+----------------------+----------------------+ | changeset1 | changeset2 | changeset3 | +----------+-----------+----------+-----------+----------+-----------+ | change1 | change2 | change1 | change2 | change1 | change2 | + - - - - -+- - - - - -+ - - - - -+- - - - - -+ - - - - -+- - - - - -+ | file1 | file3 | file1 | file1 | file3 | file4 | +----------+-----------+----------+-----------+----------+-----------+ A changeset can consist of few ordered changes, each concerning one file (repository scope changes being represented by some special metafile). Several changes in repository can affect one file. So, a "change" is similiar to one current patch ++++, ---- block. Anything inside of changeset should be probably history-independant, the history should be tracked only at the level of changesets or higher. Thus, only from changesets upwards revisions and branches matter. And now this is an interesting problem. If it should be indeed possible to export a repository to set of spatches, we need a way to represent branching there. But how? Here's one possible approach: we can identify each branch point by a changeset id (except in exotic systems like darcs, you would represent branches differently above the spatch level there though). And we already know of changeset ids --- from our POV they are some arbitrary strings with a property of being reasonably unique. So, we can say "this belongs to a branch forked from changeset XYZ", in addition we can even attach a symbolic name of the branch (we must not rely on it being unique, though). Merging varies so widely across SCMs that I'm not sure how to represent it in an unified way. In the worst case, we could do with a changeset representing the whole huge diff between merged branches (or changeset-per-changeset) plus some metainformation about what was merged (ie. list of changeset ids). A rich playground for user metadata namespaces ;). > Horseback riding is like software... > ...vgf orggre jura vgf serr. :-) Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From lord@emf.net Sat Apr 12 11:34:02 2003 Received: from morrowfield.regexps.com (1Cust195.tnt13.sfo8.da.uu.net [65.234.195.195]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CGXxbs018768 for ; Sat, 12 Apr 2003 11:34:00 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id JAA00261; Sat, 12 Apr 2003 09:44:35 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sat, 12 Apr 2003 09:44:35 -0700 (PDT) Message-Id: <200304121644.JAA00261@morrowfield.regexps.com> From: Tom Lord To: changesets@red-bean.com CC: pavel@ucw.cz In-reply-to: <20030412115309.GG3037@pasky.ji.cz> (message from Petr Baudis on Sat, 12 Apr 2003 13:53:09 +0200) Subject: the problem, so far, with this list (Re: spatch hiearchy) References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Petr Baudis I'm going to pick on your reply, but you're hardly alone as the target of my complaint -- I'm finding that the core svn developers have the same kind of "ignore prior art; NIH; it's not worth a few hours of my time to try to understand what already exists in arch" problem. > Huh. I guess there is maybe a terminology problem here. I'd > hiearchize it as: > > [ascii art omitted] > > A changeset can consist of few ordered changes, each concerning one file > (repository scope changes being represented by some special > metafile). [....] > > [....] > > If it should be indeed possible to export a repository to set of > spatches, we need a way to represent branching there. But how? > > [....] Please slow down. Initially, we need nothing more or less than whole-tree changesets. That is we need a tool, let's call it `mkpatch', which is like `diff', except that it compares two trees where there might have been renames instead of comparing two files or a tree of non-renamed files. The output of `mkpatch' is a changeset. A changeset is half the input to another tool, let's call it `dopatch', which applies that changeset to a tree which might or might not be the same as the ORIG tree given to `mkpatch'. That's _all_. We can worry about higher level structures after we have a working-draft of a spec for mkpatch/dopatch. In the arch-1.0pre17 source tree (do you have a copy?), you can find functional prototypes of the mkpatch/dopatch algorithms, and some documentation for the changeset format that implementation uses. If you haven't already, get a copy of arch, play around with it, explore the tutorial for a few hours. Play around with arch inventories (the command `larch inventory') and then changesets (`larch mkpatch', `larch what-changed', `larch dopatch'). Look at some changesets while looking at src/arch/patch-sets/PATCHES and src/arch/patch-sets/DOPATCH. Have a look at src/arch/manual/=retired/patches.doc and src/arch/manual/=retired/patch-set-format.doc. All the commands in arch have help messages (e.g. `larch inventory --help'). There are some _details_ in that implementation that I think we'd want to change for this effort to make a more formal, less arch-specific standard. For example, the arch changeset format is a directory tree containing multiple files (or a tar file of such a tree) -- we presumably want a flat format that is easier for people to read or email than a tar file. Another example: arch's mkpatch has certain mechanisms for handling inventory tags -- we probably want to generalize or refine those mechanisms a bit. So please start there. Try to learn what arch already has in this area. Demonstrate that you understand it, at least a bit. And then we can talk first about how to change the details I mentioned above, and after that, how to build higher-level structures on top of that, including those mechanisms that will let various version control systems use these changesets in interesting ways. In other words, please try to meet me half-way -- I've already done a hell of a lot of implementation and documentation in this area, and the arch community has developed a non-trivial amount of experience using those materials. > Merging varies so widely across SCMs that I'm not sure how to > represent it in an unified way. Well, I'm pretty damn sure how to do it but it's out of scope of the changeset spec. It's a problem to address _after_ we have a working draft spec of just basic changeset functionality. -t From kfogel@newton.ch.collab.net Sat Apr 12 14:30:03 2003 Received: from newton.ch.collab.net (newton.ch.collab.net [216.127.237.130]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CJU3bt022960 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 12 Apr 2003 14:30:03 -0500 Received: (from kfogel@localhost) by newton.ch.collab.net (8.11.6/8.11.6) id h3CIg2t41952; Sat, 12 Apr 2003 13:42:02 -0500 (CDT) (envelope-from kfogel@newton.ch.collab.net) To: Tom Lord Cc: changesets@red-bean.com, pavel@ucw.cz Subject: Re: the problem, so far, with this list (Re: spatch hiearchy) References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <200304121644.JAA00261@morrowfield.regexps.com> From: kfogel@collab.net Reply-To: kfogel@collab.net X-Windows: big enough to hurt. Date: 12 Apr 2003 13:41:48 -0500 In-Reply-To: <200304121644.JAA00261@morrowfield.regexps.com> Message-ID: <85ptnrtv6b.fsf@newton.ch.collab.net> Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom Lord writes: > I'm going to pick on your reply, but you're hardly alone as the target > of my complaint -- I'm finding that the core svn developers have the > same kind of "ignore prior art; NIH; it's not worth a few hours of my > time to try to understand what already exists in arch" problem. (Should stuff like this even be responded to? I don't know...) Tom, I've spent many more than a few hours trying to understand this "prior art"; meanwhile, you haven't made much effort to repackage it in a form that would be easily digestible for SVN developers. When people ask for details on what you mean, you basically point them at Arch and the Arch documentation and design papers. Well, that stuff is frankly pretty prolix and (apparently) targeted at people who already think like you do. I've read it, and I still don't know exactly how to apply it to Subversion, nor exactly what you would have us do. You're not under any obligation to frame things in the way that's easiest for us to understand, and the same is true in the reverse direction. But you alone seem to regard communications problems as asymmetrical -- it's always other people's fault, never your own. That's hard to deal with; the only solution I know of is to opt out. From rwa@alumni.princeton.edu Sat Apr 12 15:17:19 2003 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CKHIbs024161 for ; Sat, 12 Apr 2003 15:17:19 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout2-ext.prodigy.net (8.12.9/8.12.3) with ESMTP id h3CKHHoc077182 for ; Sat, 12 Apr 2003 16:17:17 -0400 Subject: Re: spatch hiearchy From: Robert Anderson To: changesets In-Reply-To: <20030412115309.GG3037@pasky.ji.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 12 Apr 2003 13:44:04 -0700 Message-Id: <1050180246.15959.56.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Sat, 2003-04-12 at 04:53, Petr Baudis wrote: > Dear diary, on Thu, Apr 10, 2003 at 09:35:49PM CEST, I got a letter, > where Pavel Machek told me, that... > > > > From: Pavel Machek > > > > > > > > I do not know if I'm asking too much from smart patch, but .... It > > > > would be nice to be able to export whole arch/svn/bk/whatever > > > > repository as a changeset, then import it into svn/arch/whatever and > > > > make that happen with no data loss. > > > > > > > > Process could be extremely ineffective; my point is that it would be > > > > nice if it was possible. [If changesets are human readable (and I > > > > think they should be) that would have nice implications for > > > > understanding what is going on, and for backups] > > > > > > > > Do you think it is possible to achive such goal? > > > > > > That's more or less the point of this entire exercise. > > > > Good. [It might make things quite complicated, through, because that > > means that one "changesets" may carry 3 independend branches, and > > whole 4-th branch along with info how it was merged into branch #3. I > > guess it is a bit more complicated than patch-NG, then.] > > Huh. I guess there is maybe a terminology problem here. I'd hiearchize it as: > > +--------------------------------------------------------------------+ > | application | > | | > | (This may be a SCM, simple 'spatch' tool (not aware of any | > | file revisions, branches etc) and so on.) | > | | > +--------------------------------------------------------------------+ > | spatch | > +----------------------+----------------------+----------------------+ > | changeset1 | changeset2 | changeset3 | > +----------+-----------+----------+-----------+----------+-----------+ > | change1 | change2 | change1 | change2 | change1 | change2 | > + - - - - -+- - - - - -+ - - - - -+- - - - - -+ - - - - -+- - - - - -+ > | file1 | file3 | file1 | file1 | file3 | file4 | > +----------+-----------+----------+-----------+----------+-----------+ > > > A changeset can consist of few ordered changes, each concerning one file > (repository scope changes being represented by some special metafile). Several > changes in repository can affect one file. So, a "change" is similiar to one > current patch ++++, ---- block. > > Anything inside of changeset should be probably history-independant, the > history should be tracked only at the level of changesets or higher. Thus, only > from changesets upwards revisions and branches matter. And now this is an > interesting problem. Trying to restate what I _think_ Tom was getting at: I think you were on the right track with "or higher." I can see no reason to include within the idea of a "changeset" anything about "history" or "branches" or "repositories" - all of which seem to be coming up repeatedly. If we're designing an entire SCM system, then you need to talk about those things. But this is a "changesets" list, and it is not clear why people are talking about those things here. If you have some idea of why it is essential to include any of those concepts in the construction of a standard for the creation and application of changesets, please explain it. Otherwise, all discussion of "history" and "branches" and "repositories" will be considered off-topic from now on. Bob From lord@emf.net Sat Apr 12 15:31:05 2003 Received: from morrowfield.regexps.com (1Cust195.tnt13.sfo8.da.uu.net [65.234.195.195]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CKV2bs024447 for ; Sat, 12 Apr 2003 15:31:03 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id NAA00877; Sat, 12 Apr 2003 13:41:33 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sat, 12 Apr 2003 13:41:33 -0700 (PDT) Message-Id: <200304122041.NAA00877@morrowfield.regexps.com> From: Tom Lord To: kfogel@collab.net CC: changesets@red-bean.com In-reply-to: <85ptnrtv6b.fsf@newton.ch.collab.net> (kfogel@collab.net) Subject: Re: the problem, so far, with this list (Re: spatch hiearchy) References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <200304121644.JAA00261@morrowfield.regexps.com> <85ptnrtv6b.fsf@newton.ch.collab.net> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: kfogel: > (Should stuff like this even be responded to? I don't > know...) Yes, please, because it's an ernest effort to debug what seems to be a really ridiculous failure of communication. > Tom, I've spent many more than a few hours trying to > understand this "prior art"; Well, that's news to me. I don't recall you asking a single question. I don't recall you asking for some help getting oriented in the code and docs to better optimize the use of your time. But that's great news. Where did you get "stuck"? > meanwhile, you haven't made much effort to repackage it in a > form that would be easily digestible for SVN developers. > When people ask for details on what you mean, you basically > point them at Arch and the Arch documentation and design > papers. Well, that stuff is frankly pretty prolix and > (apparently) targeted at people who already think like you > do. I've read it, and I still don't know exactly how to > apply it to Subversion, nor exactly what you would have us > do. "Prolix", eh? Ok. Let's see if we can induce an "aha!" in you or at least figure out where you're stuck: 1) Do you understand the arch concepts of a project tree, inventory, and inventory tags? Do you understand how and why these three concepts are not tied to any particular revision control technology? That they are just conventions for organizing a source tree? 2) Building on that, do you at least roughly understand the arch concept of a whole-tree changeset? That is, given two project trees, we can compare them to yield a changeset. This, again, is not specific to any particular revision control technology. Do you understand how inventory tags relate to whole-tree changesets? 3) Based on (1) and (2), we can consider an ordinary development line as starting with a base revision of a project tree, then consisting of a sequence of revisions in that line, each being (logically) related to its predecessor by a whole-tree changeset. Later on we'll introduce development lines with more complicated structure -- but this is a good conceptual starting point. These sequential changesets are roughly the units of an "atomic commit" in svn. This (rough) notion of development line is, again, not specific to any one revision control system. 4) Let's do something, initially just for kicks (i.e. I'm not going to try to justify _why_ it's this way in this message -- but we can take it up separately). Specifically: let's define a global namespace for development lines and the revisions with in them. In arch, that's the "arch global namespace". Schematically, it's currently structured as: /------ or in arch words as: /------ with: /---- being the name of a development line and: /------ the name of a revision within a development line. Such a global name might be the name of a base revision, or the name of a revision related to a base revision by a sequence of changesets. The detailed structure of arch's namespace is controversial. It has flaws. It needs to be tweaked. But it's existence has proved invaluable and, in a corrected form, it should exist, again as a revision control system independent mechanism. 5) Finally, are you aware of the arch concept of a "patch log"? Every base revision and changeset in development lines includes a log entry file. Every project tree includes a sub-tree of log entry files -- one for the base revision of that tree, and one for every changeset that has been applied to that tree in recent and relevant history. When a change is applied to a tree, the log for that change is file-added to the patch log. The global namespace of revisions is used to name patch log files. The patch log files themselves contain "meta-data" about the nature of the change, and some of that meta-data is expressed in terms of the global namespace. You might want to look at some patch log files to see this meta-data. Patch logs are, again, a revision control system independent concept. The meta-data in patch logs is the "history" of "history sensitive merging". We can take up separately how arch merge commands like `replay', `update', and `star-merge' use that meta-data. What those merge commands do is independent of any particular revision control system. If they can get the relevent changesets, or equivalently, the trees those changesets correspond to, then the merge operators can be implemented. 6) Now, what am I suggesting for svn? I'm suggesting that we add a light layer over the core capabilities of svn. This light layer would give svn: smart merging, distribution, better change auditing, interop with arch, and more. Roughly speaking, this light layer would store arch-ish project trees in svn, patch-logs, inventory data and all -- then use that data to add the features mentioned in the preceding paragraph. I would like to designate a subset of the repository as being "mapped into" the corrected global namespace of (4). That is, a revision: /------ might appear in a svn repository as: //////* That "*" includes the complete source of that revision. It includes the patch-log for that revision. By brute force, if I `get' two successive such revisions, I can compute the changeset in between them. More plausibly, that "*" also includes a copy of that changeset, pre-computed. Generic (rev ctl system independent) implementations of all the nifty merge operators and much else besides can operate on revisions stored in svn as easily as revisions stored in an arch native archive. We have a pretty good implementation layering for that purpose and know how to perfect it -- we can take that up separately, too, if you like. Would _every_ svn revision have to fit into that namespace? No, not at all. Instead, I see adding revisions to that namespace as a layered command, comperable to BK's commit (are you familiar with the checkin/commit distinction in BK?). But those revisions that _do_ fit into that namespace: they're very, very useful. They're granularity corresponds nicely to the granularity of scalable project management. The namespace itself and the way it's reflected in patch logs makes distributed branching a cake-walk. Revisions in that namespace make an ideal rendezvous point for smart merging between branches. > You're not under any obligation to frame things in the way > that's easiest for us to understand, and the same is true in > the reverse direction. But you alone seem to regard > communications problems as asymmetrical -- it's always other > people's fault, never your own. Well, I've spent a lot of time looking looking at svn docs, source, and notes. I've asked questions about the occaisional issue that was relevant but unclear from those materials. Sure, sometimes I say "node" instead of "node revision", but overall, I think I've demonstrated my effort here. When I asked you recently about what you knew about arch the answer was "basically nothing" and in the subsequent conversation, even very, very basic elements like the patch-log seemed to be something you'd never heard of (which meant that we never got around to talking about any of the interesting issues). Meanwhile, I've witnessed arch users pick up to a useful degree on the abstractions very quickly. Days even. Damn straight it's asymmetric (no comment on "fault") -- but the _interesting_ question is, is it fixable? -t From rwa@alumni.princeton.edu Sat Apr 12 15:49:02 2003 Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CKn1bs024916 for ; Sat, 12 Apr 2003 15:49:02 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout1-ext.prodigy.net (8.12.9/8.12.3) with ESMTP id h3CKn0YD090688 for ; Sat, 12 Apr 2003 16:49:00 -0400 Subject: spatch? From: Robert Anderson Cc: changesets In-Reply-To: <1050180246.15959.56.camel@lan1> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <1050180246.15959.56.camel@lan1> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 12 Apr 2003 14:15:48 -0700 Message-Id: <1050182149.15939.74.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Can someone explain the term "spatch"? I searched the archives and it seems to come out of nowhere, undefined. Thanks, Bob From rwa@alumni.princeton.edu Sat Apr 12 15:49:24 2003 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CKnObs024921 for ; Sat, 12 Apr 2003 15:49:24 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout2-ext.prodigy.net (8.12.9/8.12.3) with ESMTP id h3CKnMoc336124 for ; Sat, 12 Apr 2003 16:49:23 -0400 Subject: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] From: Robert Anderson To: changesets Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 12 Apr 2003 14:16:11 -0700 Message-Id: <1050182172.15939.76.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: -----Forwarded Message----- From: Robert Anderson To: Tom Lord Subject: Re: the problem, so far, with this list (Re: spatch hiearchy) Date: 12 Apr 2003 14:13:38 -0700 On Sat, 2003-04-12 at 13:41, Tom Lord wrote: > > > > kfogel: > > > (Should stuff like this even be responded to? I don't > > know...) > > Yes, please, because it's an ernest effort to debug what seems to be a > really ridiculous failure of communication. > > > Tom, I've spent many more than a few hours trying to > > understand this "prior art"; > > Well, that's news to me. I don't recall you asking a single question. > I don't recall you asking for some help getting oriented in the code Tom, frankly I think asking people to learn anything about changesets or the way arch works by reading the arch source code is completely absurd. At the finest levels of detail that's appropriate, but not for general grokking of a big picture. Point people to docs, but for god's sake, pointing people at the arch source code as a first pointer, or as a pointer at all for big picture ideas, is not going to help anybody, and will probably hurt everybody. > and docs to better optimize the use of your time. > > But that's great news. Where did you get "stuck"? > > > meanwhile, you haven't made much effort to repackage it in a > > form that would be easily digestible for SVN developers. > > When people ask for details on what you mean, you basically > > point them at Arch and the Arch documentation and design > > papers. Well, that stuff is frankly pretty prolix and > > (apparently) targeted at people who already think like you > > do. I've read it, and I still don't know exactly how to > > apply it to Subversion, nor exactly what you would have us > > do. > > "Prolix", eh? Ok. Let's see if we can induce an "aha!" in you or at > least figure out where you're stuck: > > 1) Do you understand the arch concepts of a project tree, inventory, > and inventory tags? Do you understand how and why these three > concepts are not tied to any particular revision control > technology? That they are just conventions for organizing a source > tree? To start, isn't the concept of "inventory" superfluous? I don't see why you can't reduce the problem, without loss of generality, to the case of everything in the tree being (arch's notion of) "source" - and leave transforming (in effect) to/from an "only source" state to some other layer. > 2) Building on that, do you at least roughly understand the arch > concept of a whole-tree changeset? That is, given two project > trees, we can compare them to yield a changeset. This, again, is > not specific to any particular revision control technology. > > Do you understand how inventory tags relate to whole-tree > changesets? > > > 3) Based on (1) and (2), we can consider an ordinary development line > as starting with a base revision of a project tree, then consisting > of a sequence of revisions in that line, each being (logically) > related to its predecessor by a whole-tree changeset. Later on > we'll introduce development lines with more complicated structure > -- but this is a good conceptual starting point. > > These sequential changesets are roughly the units of an "atomic > commit" in svn. This (rough) notion of development line is, > again, not specific to any one revision control system. > > 4) Let's do something, initially just for kicks (i.e. I'm not going to > try to justify _why_ it's this way in this message -- but we can > take it up separately). Specifically: let's define a global > namespace for development lines and the revisions with in them. > > In arch, that's the "arch global namespace". Schematically, it's > currently structured as: > > /------ > > or in arch words as: > > /------ > > with: > > /---- > > being the name of a development line and: > > /------ > > the name of a revision within a development line. > > Such a global name might be the name of a base revision, or the > name of a revision related to a base revision by a sequence of > changesets. > > The detailed structure of arch's namespace is controversial. It > has flaws. It needs to be tweaked. But it's existence has proved > invaluable and, in a corrected form, it should exist, again as a > revision control system independent mechanism. > > 5) Finally, are you aware of the arch concept of a "patch log"? Every > base revision and changeset in development lines includes a log > entry file. Every project tree includes a sub-tree of log entry > files -- one for the base revision of that tree, and one for every > changeset that has been applied to that tree in recent and relevant > history. When a change is applied to a tree, the log for that > change is file-added to the patch log. > > The global namespace of revisions is used to name patch log files. > The patch log files themselves contain "meta-data" about the nature > of the change, and some of that meta-data is expressed in terms of > the global namespace. You might want to look at some patch log > files to see this meta-data. > > Patch logs are, again, a revision control system independent > concept. > > The meta-data in patch logs is the "history" of "history sensitive > merging". We can take up separately how arch merge commands like > `replay', `update', and `star-merge' use that meta-data. > > What those merge commands do is independent of any particular > revision control system. If they can get the relevent changesets, > or equivalently, the trees those changesets correspond to, then the > merge operators can be implemented. Isn't all of this off-topic with respect to changesets? Bob From pasky@machine.sinus.cz Sat Apr 12 15:59:41 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3CKxZbs025242 for ; Sat, 12 Apr 2003 15:59:41 -0500 Received: (qmail 16844 invoked by uid 2001); 12 Apr 2003 20:59:29 -0000 Date: Sat, 12 Apr 2003 22:59:29 +0200 From: Petr Baudis To: Robert Anderson Cc: changesets Subject: Re: spatch hiearchy Message-ID: <20030412205929.GL3037@pasky.ji.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <1050180246.15959.56.camel@lan1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050180246.15959.56.camel@lan1> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Sat, Apr 12, 2003 at 10:44:04PM CEST, I got a letter, where Robert Anderson told me, that... > On Sat, 2003-04-12 at 04:53, Petr Baudis wrote: > > Dear diary, on Thu, Apr 10, 2003 at 09:35:49PM CEST, I got a letter, > > where Pavel Machek told me, that... > > > > > From: Pavel Machek > > > > > > > > > > I do not know if I'm asking too much from smart patch, but .... It > > > > > would be nice to be able to export whole arch/svn/bk/whatever > > > > > repository as a changeset, then import it into svn/arch/whatever and > > > > > make that happen with no data loss. > > > > > > > > > > Process could be extremely ineffective; my point is that it would be > > > > > nice if it was possible. [If changesets are human readable (and I > > > > > think they should be) that would have nice implications for > > > > > understanding what is going on, and for backups] > > > > > > > > > > Do you think it is possible to achive such goal? > > > > > > > > That's more or less the point of this entire exercise. > > > > > > Good. [It might make things quite complicated, through, because that > > > means that one "changesets" may carry 3 independend branches, and > > > whole 4-th branch along with info how it was merged into branch #3. I > > > guess it is a bit more complicated than patch-NG, then.] > > > > Huh. I guess there is maybe a terminology problem here. I'd hiearchize it as: > > > > +--------------------------------------------------------------------+ > > | application | > > | | > > | (This may be a SCM, simple 'spatch' tool (not aware of any | > > | file revisions, branches etc) and so on.) | > > | | > > +--------------------------------------------------------------------+ > > | spatch | > > +----------------------+----------------------+----------------------+ > > | changeset1 | changeset2 | changeset3 | > > +----------+-----------+----------+-----------+----------+-----------+ > > | change1 | change2 | change1 | change2 | change1 | change2 | > > + - - - - -+- - - - - -+ - - - - -+- - - - - -+ - - - - -+- - - - - -+ > > | file1 | file3 | file1 | file1 | file3 | file4 | > > +----------+-----------+----------+-----------+----------+-----------+ > > > > > > A changeset can consist of few ordered changes, each concerning one file > > (repository scope changes being represented by some special metafile). Several > > changes in repository can affect one file. So, a "change" is similiar to one > > current patch ++++, ---- block. > > > > Anything inside of changeset should be probably history-independant, the > > history should be tracked only at the level of changesets or higher. Thus, only > > from changesets upwards revisions and branches matter. And now this is an > > interesting problem. > > Trying to restate what I _think_ Tom was getting at: > > I think you were on the right track with "or higher." > > I can see no reason to include within the idea of a "changeset" anything > about "history" or "branches" or "repositories" - all of which seem to > be coming up repeatedly. If we're designing an entire SCM system, then > you need to talk about those things. But this is a "changesets" list, > and it is not clear why people are talking about those things here. > > If you have some idea of why it is essential to include any of those > concepts in the construction of a standard for the creation and > application of changesets, please explain it. Otherwise, all discussion > of "history" and "branches" and "repositories" will be considered > off-topic from now on. Understood and agreed, I got a little carried away. It is indeed better to organize the history relations on a higher level. I hope the diagram above will be still of at least some use. Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From pasky@machine.sinus.cz Sat Apr 12 16:01:38 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3CL1bbs025341 for ; Sat, 12 Apr 2003 16:01:38 -0500 Received: (qmail 16947 invoked by uid 2001); 12 Apr 2003 21:01:36 -0000 Date: Sat, 12 Apr 2003 23:01:36 +0200 From: Petr Baudis To: Robert Anderson Cc: changesets Subject: Re: spatch? Message-ID: <20030412210136.GM3037@pasky.ji.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <1050180246.15959.56.camel@lan1> <1050182149.15939.74.camel@lan1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050182149.15939.74.camel@lan1> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Sat, Apr 12, 2003 at 11:15:48PM CEST, I got a letter, where Robert Anderson told me, that... > Can someone explain the term "spatch"? I searched the archives and it > seems to come out of nowhere, undefined. I've used it in my first mail on this list (quite early one, <20030407234439.GA3037@pasky.ji.cz> in case you'd be interested): .. (I will use spatch (smart patch) as the shortcut alias for "new patch format" below.) .. I just wanted some short and compact word representing the object of our desires. Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From pavel@bug.ucw.cz Sat Apr 12 16:06:03 2003 Received: from Elf.ucw.cz ([195.39.17.254]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CL4ebs025415 for ; Sat, 12 Apr 2003 16:05:29 -0500 Received: from bug.ucw.cz (bug.ucw.cz [10.0.0.3]) by Elf.ucw.cz (Postfix) with ESMTP id 6798DC3463; Sat, 12 Apr 2003 21:10:31 +0200 (CEST) Received: (from pavel@localhost) by bug.ucw.cz (8.8.8/8.8.5) id UAA00233; Sat, 12 Apr 2003 20:38:04 +0200 Date: Sat, 12 Apr 2003 20:38:01 +0200 From: Pavel Machek To: Tom Lord Cc: changesets@red-bean.com Subject: Re: the problem, so far, with this list (Re: spatch hiearchy) Message-ID: <20030412183801.GA224@elf.ucw.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <200304121644.JAA00261@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304121644.JAA00261@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-Warning: Reading this can be dangerous to your mental health. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Hi! On Sat 12-04-03 09:44:35, Tom Lord wrote: > > From: Petr Baudis > > I'm going to pick on your reply, but you're hardly alone as the target > of my complaint -- Perhaps you are confusing me with Petr? You cc-ed me but are clearly quoting Petr... We have both @ucw.cz address and same namesday, but that's about it. > In the arch-1.0pre17 source tree (do you have a copy?), you can find > functional prototypes of the mkpatch/dopatch algorithms, and some > documentation for the changeset format that implementation uses. If If you propose spatch to use mkpatch/dopatch changesets, please post specification here. That's sure to help the discussion... Pavel -- When do you have heart between your knees? From pasky@machine.sinus.cz Sat Apr 12 16:56:26 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3CLuPbs026610 for ; Sat, 12 Apr 2003 16:56:26 -0500 Received: (qmail 18664 invoked by uid 2001); 12 Apr 2003 21:56:24 -0000 Date: Sat, 12 Apr 2003 23:56:24 +0200 From: Petr Baudis To: Tom Lord Cc: changesets@red-bean.com, pavel@ucw.cz Subject: Re: the problem, so far, with this list (Re: spatch hiearchy) Message-ID: <20030412215624.GN3037@pasky.ji.cz> References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <200304121644.JAA00261@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304121644.JAA00261@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Sat, Apr 12, 2003 at 06:44:35PM CEST, I got a letter, where Tom Lord told me, that... > > Huh. I guess there is maybe a terminology problem here. I'd > > hiearchize it as: > > > > [ascii art omitted] > > > > A changeset can consist of few ordered changes, each concerning one file > > (repository scope changes being represented by some special > > metafile). [....] > > > > [....] > > > > If it should be indeed possible to export a repository to set of > > spatches, we need a way to represent branching there. But how? > > > > [....] > > Please slow down. Yeah, sorry for getting out of scope. One general comment first, I thought it was general consensus to first agree upon the principles and concepts of the work, then worry about the particular implementation. > Initially, we need nothing more or less than whole-tree changesets. > That is we need a tool, let's call it `mkpatch', which is like `diff', > except that it compares two trees where there might have been renames > instead of comparing two files or a tree of non-renamed files. The > output of `mkpatch' is a changeset. A changeset is half the input to > another tool, let's call it `dopatch', which applies that changeset to > a tree which might or might not be the same as the ORIG tree given to > `mkpatch'. Rather a side-note: as said several times already, one spatch should be able to carry several changesets and the mkpatch and dopatch tools should probably generate the spatches directly (ie. one-changeset ones) instead of the changeset fragments. It is mostly a formal issue of level of abstraction, practically speaking I think the only visible rider will be some boundary marks for the tools to be able to take several changeset objects from one file. > That's _all_. We can worry about higher level structures after we > have a working-draft of a spec for mkpatch/dopatch. Agreed. > In the arch-1.0pre17 source tree (do you have a copy?), you can find > functional prototypes of the mkpatch/dopatch algorithms, and some > documentation for the changeset format that implementation uses. If > you haven't already, get a copy of arch, play around with it, explore > the tutorial for a few hours. Play around with arch inventories (the > command `larch inventory') and then changesets (`larch mkpatch', > `larch what-changed', `larch dopatch'). Look at some changesets while > looking at src/arch/patch-sets/PATCHES and > src/arch/patch-sets/DOPATCH. Have a look at > src/arch/manual/=retired/patches.doc and > src/arch/manual/=retired/patch-set-format.doc. All the commands in > arch have help messages (e.g. `larch inventory --help'). I had a brief look, but I have no idea what should I focus on because I can't see how the arch patch format could be beneficial for us. Hold on, I will try to elaborate and reparcel once more our requirements, so that you will have some frame to argue inside ;-). (In spirit of my previous posts, I will use apatch instead of "arch's patchset format" below.) Data: - apatch uses just the traditional unified diff, that is nothing new. - In fact some people argued against reusing of the unified diff format, however I personally saw no hints about how should a replacement look like. Metadata: - New/removed files information is stored in separate parts (directories). In suitable spatch encapsulation they should be of same format (ie. unified diffs) as the other files and their (disappearance) should be noted in a way consistent with other metadata (I've already proposed renaming from/to an empty file name). - [? I'm not sure I get the way renames are represented completely yet.] Renames are also stored separately from the other file changes, and the changes are identified by actual file names instead of tags. - The permissions, symlinks info and "other" metadata is not saved in a particularily extensible way (like the namespaces etc) neither. - Thus there is no consistent way how metadata are recorded and in order to have some interoperably usable result, I believe the way of tracking them would have to be significantly (if not completely) rethought. So, how I see it, it doesn't match on the details nor it does on the general concepts level (or it matches but gives us no advantage anyway). It looks like modifying the GNU diff and GNU patch tools to our desirect image would be an easier and better (as it would give us more freedom in the file format) way to take. What in particular can apatch give us? Kind regards, -- Petr "Pasky" Baudis . The pure and simple truth is rarely pure and never simple. -- Oscar Wilde . Stuff: http://pasky.ji.cz/ From lord@emf.net Sat Apr 12 17:22:53 2003 Received: from morrowfield.regexps.com (1Cust195.tnt13.sfo8.da.uu.net [65.234.195.195]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CMMYbs027194 for ; Sat, 12 Apr 2003 17:22:44 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA01287; Sat, 12 Apr 2003 15:33:04 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sat, 12 Apr 2003 15:33:04 -0700 (PDT) Message-Id: <200304122233.PAA01287@morrowfield.regexps.com> From: Tom Lord To: changesets@sanpietro.red-bean.com CC: rwa@alumni.princeton.edu In-reply-to: <1050180246.15959.56.camel@lan1> (message from Robert Anderson on 12 Apr 2003 13:44:04 -0700) Subject: Re: spatch hiearchy References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <1050180246.15959.56.camel@lan1> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Robert Anderson [...] > If you have some idea of why it is essential to include any of > those concepts in the construction of a standard for the > creation and application of changesets, please explain it. > Otherwise, all discussion of "history" and "branches" and > "repositories" will be considered off-topic from now on. I think it's a _tiny_tiny_bit_ on topic, but not nearly at the level we've seen here. It's on topic in this very limited sense: Presumably we'll get around to changeset _syntax_ at some point. And for that syntax, we'll want to consider email and other transports and the problem of extracting a substream of a larger stream which is a changeset while keeping all the data together. And as we add higher levels, well beyond just changesets, we'll want those higher-levels to be able to label changesets with some of their data. So, eventually, _maybe_, we'll want to talk about adding, general header fields to changesets or something similar -- an extensible mechanism of places where one might want to stash revision ids and so forth. But yeah -- in the mean time -- (a) the topic should be pretty much about mkpatch/dopatch (not the arch commands specifically -- just that abstract category of tool) (b) at this rate it's never going to make progress or get serious without adopting a charter and process -t From lord@emf.net Sat Apr 12 17:33:53 2003 Received: from morrowfield.regexps.com (1Cust195.tnt13.sfo8.da.uu.net [65.234.195.195]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CMXqbs027486 for ; Sat, 12 Apr 2003 17:33:52 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA01316; Sat, 12 Apr 2003 15:44:34 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sat, 12 Apr 2003 15:44:34 -0700 (PDT) Message-Id: <200304122244.PAA01316@morrowfield.regexps.com> From: Tom Lord To: rwa@alumni.princeton.edu CC: changesets@sanpietro.red-bean.com In-reply-to: <1050182172.15939.76.camel@lan1> (message from Robert Anderson on 12 Apr 2003 14:16:11 -0700) Subject: Re: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] References: <1050182172.15939.76.camel@lan1> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Robert Anderson >> 1) Do you understand the arch concepts of a project tree, inventory, >> and inventory tags? Do you understand how and why these three >> concepts are not tied to any particular revision control >> technology? That they are just conventions for organizing a source >> tree? > To start, isn't the concept of "inventory" superfluous? I don't > see why you can't reduce the problem, without loss of > generality, to the case of everything in the tree being (arch's > notion of) "source" - and leave transforming (in effect) to/from > an "only source" state to some other layer. It is not surperfluous. Even GNU diff has `--exclude'. It is also not superfluous for the deeper reason that inventory tag mgt. (which is directly essential to changesets) has a lot of pragmatic considerations, and inventories are key to solving those, imo. > > 2) Building on that, do you at least roughly understand the arch > > concept of a whole-tree changeset? [....] > > Do you understand how inventory tags relate to whole-tree > > changesets? > > 3) Based on (1) and (2), we can consider an ordinary development line > > as starting with a base revision of a project tree, then consisting > > of a sequence of revisions in that line, each being (logically) > > related to its predecessor by a whole-tree changeset. [....] > > 4) [....] Specifically: let's define a global > > namespace for development lines and the revisions with in > > [....] them. > > 5) Finally, are you aware of the arch concept of a "patch > > log"? [....] [> > 6) svn implications ] > Isn't all of this off-topic with respect to changesets? (2) is clearly not. (3) and (4) is an important use case for changesets -- reasons to bother with them at all. (5) and (6) are part of the motivation behind the IRC chat that led to the creation of this list. In general, the list wasn't created in a vacuum. From my perspective, it was created for bridge-building between svn and arch (initially). -t From lord@emf.net Sat Apr 12 17:41:23 2003 Received: from morrowfield.regexps.com (1Cust195.tnt13.sfo8.da.uu.net [65.234.195.195]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CMfMbs027672 for ; Sat, 12 Apr 2003 17:41:22 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA01326; Sat, 12 Apr 2003 15:46:56 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sat, 12 Apr 2003 15:46:56 -0700 (PDT) Message-Id: <200304122246.PAA01326@morrowfield.regexps.com> From: Tom Lord To: pavel@ucw.cz CC: changesets@red-bean.com In-reply-to: <20030412183801.GA224@elf.ucw.cz> (message from Pavel Machek on Sat, 12 Apr 2003 20:38:01 +0200) Subject: Re: the problem, so far, with this list (Re: spatch hiearchy) References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <200304121644.JAA00261@morrowfield.regexps.com> <20030412183801.GA224@elf.ucw.cz> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: Pavel Machek > Perhaps you are confusing me with Petr? You cc-ed me but are clearly > quoting Petr... Sorry about that. > If you propose spatch to use mkpatch/dopatch changesets, please post > specification here. That's sure to help the discussion... I have pointed to the parts of the documentation that add up to an informal spec. -t From rwa@alumni.princeton.edu Sat Apr 12 17:47:44 2003 Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CMlhbs027784 for ; Sat, 12 Apr 2003 17:47:43 -0500 Received: from [192.168.0.2] (adsl-64-165-208-253.dsl.snfc21.pacbell.net [64.165.208.253]) by pimout2-ext.prodigy.net (8.12.9/8.12.3) with ESMTP id h3CMlgoc125106 for ; Sat, 12 Apr 2003 18:47:42 -0400 Subject: Re: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] From: Robert Anderson Cc: changesets In-Reply-To: <200304122244.PAA01316@morrowfield.regexps.com> References: <1050182172.15939.76.camel@lan1> <200304122244.PAA01316@morrowfield.regexps.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) Date: 12 Apr 2003 16:14:31 -0700 Message-Id: <1050189273.23237.89.camel@lan1> Mime-Version: 1.0 Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: On Sat, 2003-04-12 at 15:44, Tom Lord wrote: > > > From: Robert Anderson > > >> 1) Do you understand the arch concepts of a project tree, inventory, > >> and inventory tags? Do you understand how and why these three > >> concepts are not tied to any particular revision control > >> technology? That they are just conventions for organizing a source > >> tree? > > > To start, isn't the concept of "inventory" superfluous? I don't > > see why you can't reduce the problem, without loss of > > generality, to the case of everything in the tree being (arch's > > notion of) "source" - and leave transforming (in effect) to/from > > an "only source" state to some other layer. > > > It is not surperfluous. Even GNU diff has `--exclude'. It's a nice feature, but take away "--exclude" and you still have a program everyone would call "diff." It's not essential. > It is also not superfluous for the deeper reason that inventory tag > mgt. (which is directly essential to changesets) has a lot of > pragmatic considerations, and inventories are key to solving those, > imo. Maybe there's something there. I'm not sure. > > > 2) Building on that, do you at least roughly understand the arch > > > concept of a whole-tree changeset? [....] > > > Do you understand how inventory tags relate to whole-tree > > > changesets? > > > > 3) Based on (1) and (2), we can consider an ordinary development line > > > as starting with a base revision of a project tree, then consisting > > > of a sequence of revisions in that line, each being (logically) > > > related to its predecessor by a whole-tree changeset. [....] > > > > 4) [....] Specifically: let's define a global > > > namespace for development lines and the revisions with in > > > [....] them. > > > > 5) Finally, are you aware of the arch concept of a "patch > > > log"? [....] > > [> > 6) svn implications ] > > > Isn't all of this off-topic with respect to changesets? > > > (2) is clearly not. Cut/paste error on my part. > (3) and (4) is an important use case for changesets -- reasons to > bother with them at all. I don't think there's any argument over whether to bother with them or not. > (5) and (6) are part of the motivation behind the IRC chat that led > to the creation of this list. > > In general, the list wasn't created in a vacuum. From my perspective, > it was created for bridge-building between svn and arch (initially). > > -t The whole juxtaposition of this post and your most recent flame seemed a little hypocritical. Either we are going to stay on target for changesets, or, the larger picture, arch-centric or not, is ok for discussion. I think focus would serve well. Bob From lord@emf.net Sat Apr 12 18:25:48 2003 Received: from morrowfield.regexps.com (1Cust195.tnt13.sfo8.da.uu.net [65.234.195.195]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3CNPkbs028660 for ; Sat, 12 Apr 2003 18:25:47 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id QAA01503; Sat, 12 Apr 2003 16:36:23 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sat, 12 Apr 2003 16:36:23 -0700 (PDT) Message-Id: <200304122336.QAA01503@morrowfield.regexps.com> From: Tom Lord To: rwa@alumni.princeton.edu CC: changesets@sanpietro.red-bean.com In-reply-to: <1050189273.23237.89.camel@lan1> (message from Robert Anderson on 12 Apr 2003 16:14:31 -0700) Subject: Re: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] References: <1050182172.15939.76.camel@lan1> <200304122244.PAA01316@morrowfield.regexps.com> <1050189273.23237.89.camel@lan1> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: rwa: > The whole juxtaposition of this post and your most recent > flame seemed a little hypocritical. Either we are going to > stay on target for changesets, or, the larger picture, > arch-centric or not, is ok for discussion. > I think focus would serve well. I certainly don't disagree with the last sentence: formal charter and process, I say. And I don't _entirely_ disagree with the first paragraph, but I have a defense, of sorts: This list _didn't_ arise out of thin air when a bunch of folks decided to work on changeset standards. That'd be the ideal formal way to view the list -- but it isn't the accurate historical way to view the list. The list _did_ arise because I keep saying to svn developers that arch and svn have largely complementary abstract approaches -- that it makes a lot of sense, for example, to solve some of their goals by grafting arch onto svn (or, from the arch perspective, to enable the use of svn as a "smart server"). So the question of "what does all this mean to svn?" is on-topic in the history-of-the-list sense and the larger-context sesne, but not in the idealized-charter sense. -t From kfogel@newton.ch.collab.net Sun Apr 13 09:25:30 2003 Received: from newton.ch.collab.net (newton.ch.collab.net [216.127.237.130]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3DEPUbt016160 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 13 Apr 2003 09:25:30 -0500 Received: (from kfogel@localhost) by newton.ch.collab.net (8.11.6/8.11.6) id h3DDgTD43694; Sun, 13 Apr 2003 08:42:29 -0500 (CDT) (envelope-from kfogel@newton.ch.collab.net) To: Tom Lord Cc: rwa@alumni.princeton.edu, changesets@sanpietro.red-bean.com Subject: Re: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] References: <1050182172.15939.76.camel@lan1> <200304122244.PAA01316@morrowfield.regexps.com> <1050189273.23237.89.camel@lan1> <200304122336.QAA01503@morrowfield.regexps.com> From: kfogel@collab.net Reply-To: kfogel@collab.net Emacs: ... it's not just a way of life, it's a text editor! Date: 13 Apr 2003 08:42:25 -0500 In-Reply-To: <200304122336.QAA01503@morrowfield.regexps.com> Message-ID: <85r886seda.fsf@newton.ch.collab.net> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom Lord writes: > The list _did_ arise because I keep saying to svn developers that arch > and svn have largely complementary abstract approaches -- that it > makes a lot of sense, for example, to solve some of their goals by > grafting arch onto svn (or, from the arch perspective, to enable the > use of svn as a "smart server"). > > So the question of "what does all this mean to svn?" is on-topic in > the history-of-the-list sense and the larger-context sesne, but not in > the idealized-charter sense. That's a fair statement -- and it follows then that I shouldn't be viewing this list as though it's mainly meant to serve SVN developer's immediate purposes. Sorry, & thanks for the reminder, Tom. From lord@emf.net Sun Apr 13 11:37:53 2003 Received: from morrowfield.regexps.com (1Cust28.tnt13.sfo8.da.uu.net [65.234.195.28]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3DGbobs019113 for ; Sun, 13 Apr 2003 11:37:51 -0500 Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id JAA04016; Sun, 13 Apr 2003 09:48:41 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Date: Sun, 13 Apr 2003 09:48:41 -0700 (PDT) Message-Id: <200304131648.JAA04016@morrowfield.regexps.com> From: Tom Lord To: kfogel@collab.net CC: rwa@alumni.princeton.edu, changesets@sanpietro.red-bean.com In-reply-to: <85r886seda.fsf@newton.ch.collab.net> (kfogel@collab.net) Subject: Re: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] References: <1050182172.15939.76.camel@lan1> <200304122244.PAA01316@morrowfield.regexps.com> <1050189273.23237.89.camel@lan1> <200304122336.QAA01503@morrowfield.regexps.com> <85r886seda.fsf@newton.ch.collab.net> Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: > From: kfogel@collab.net >> So the question of "what does all this mean to svn?" is >> on-topic in the history-of-the-list sense and the >> larger-context sesne, but not in the idealized-charter sense. > That's a fair statement -- and it follows then that I shouldn't > be viewing this list as though it's mainly meant to serve SVN > developer's immediate purposes. Sorry, & thanks for the > reminder, Tom. Well, you're welcome, but in my opinion: please don't take it _quite_ that way. Sure, sure -- it's not a list _about_ svn or about arch. Personally, I'd like to see it become the mailing list for a working group with a charter document and semi-formal process, the goal of said group being something along the lines of (a) writing formal specs for a whole-tree-diff and whole-tree-patch; (b) providing reference implementations of those specs. I tend to believe that unless we have _some_ structure and institutionalized agenda like that, real progress will be impossible. The two big players in this space right now are arch and svn. There are other players who we might like to join in (e.g. Bitmover), but if that's possible at all, I think a little formality and structure will be necessary to make the invitation credible. Before we get to those other players: the invitation is already credible to the arch project ('cause I say so, pfft!). So the next thing is to make the invitation credible and compelling to svn. And that works directly against _much_ of what we know about the state of the svn project for the immediate future (i.e., the push to 1.0). But it doesn't work against _everything_ we know about the state of the svn project and there are several areas I'll call your attention to: 1) Planning for fancy merge features is already going on in svn and, though yes, we still have to work on getting you efficiently to the "Aha!" point, I claim we have a plan for "faster, cheaper, better" -- and that the changeset work of this list is a cornerstone of that. 2) You have post 1.0 issues like distributed branching: here again, we (in the arch world) have a faster, cheaper, better approach than what I've seen being tenatively contemplated/hacked on in svn. Changesets are foundational to this, too. 3) Something we haven't talked about before: Now that I understand a little better what a "commit" entails on the server side in svn, I think that we have a faster, cheaper, better solution to offer you for storage management (than using BDB or a RDBMS). Changesets are, yet again, foundational. 4) I think your "1.0 story" is improved not _necessarily_ by rushing any of these f.c.b. solutions into 1.0, but by accompanying a 1.0 release with a more detailed "heads up" roadmap about what's planned. I think that to make such a map well, the f.c.b. solutions ought to be examined and considered. So in that light, your "What are you saying you want us (svn) to do?" question isn't a bad one to explore. -t From mass@akuma.org Sun Apr 13 14:10:57 2003 Received: from mail.aspect.net (adsl-65-69-210-161.dsl.hstntx.swbell.net [65.69.210.161]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with ESMTP id h3DJAubs022729 for ; Sun, 13 Apr 2003 14:10:57 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.aspect.net (Postfix) with ESMTP id 6E627A982; Sun, 13 Apr 2003 14:10:56 -0500 (CDT) Received: from mail.aspect.net ([127.0.0.1]) by localhost (pavia.aspect.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18407-04; Sun, 13 Apr 2003 14:10:54 -0500 (CDT) Received: from akuma.org (12-253-230-167.client.attbi.com [12.253.230.167]) by mail.aspect.net (Postfix) with ESMTP id 2580685F2; Sun, 13 Apr 2003 14:10:52 -0500 (CDT) Message-ID: <3E99B639.6040007@akuma.org> Date: Sun, 13 Apr 2003 13:10:49 -0600 From: David Waite User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: changesets@red-bean.com Cc: Tom Lord Subject: Re: spatch hiearchy References: <20030409224841.GB20996@atrey.karlin.mff.cuni.cz> <200304092345.QAA03994@morrowfield.regexps.com> <20030410193549.GA10793@atrey.karlin.mff.cuni.cz> <20030412115309.GG3037@pasky.ji.cz> <1050180246.15959.56.camel@lan1> <200304122233.PAA01287@morrowfield.regexps.com> In-Reply-To: <200304122233.PAA01287@morrowfield.regexps.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030314-p1 (Debian) Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Tom Lord wrote: >(b) at this rate it's never going to make progress or get serious > without adopting a charter and process > > I'm starting to think this would be a very, very good idea - everyone on this list seems to be somewhere different on the line between establishing goals and constructing a prototype (I am personally still back at establishing goals) :-) It would be very useful to have a document which defines common terms in addition to defining goals; then we can work on a timeline. I'm guessing that we know enough about the problem space now that we can work bottom-up on a specification - start with just changes to a file within a tree and a tree itself as a changeset; additional inventory and repository/revision information associated with a changeset, then (lastly?) the 'smart patch' changeset collection with branch/merge tracking and optional DAG of changeset dependancies. If wanted, I will author such documents (I'm considering working on them a little this weekend anyways, to foster more structured conversation) -David Waite From pasky@machine.sinus.cz Sun Apr 13 17:32:36 2003 Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by sanpietro.red-bean.com (8.12.3/8.12.3/Debian -4) with SMTP id h3DMWMbs027133 for ; Sun, 13 Apr 2003 17:32:31 -0500 Received: (qmail 28275 invoked by uid 2001); 13 Apr 2003 22:32:06 -0000 Date: Mon, 14 Apr 2003 00:32:06 +0200 From: Petr Baudis To: Tom Lord Cc: kfogel@collab.net, rwa@alumni.princeton.edu, changesets@sanpietro.red-bean.com Subject: Re: [Fwd: Re: the problem, so far, with this list (Re: spatch hiearchy)] Message-ID: <20030413223206.GX3037@pasky.ji.cz> References: <1050182172.15939.76.camel@lan1> <200304122244.PAA01316@morrowfield.regexps.com> <1050189273.23237.89.camel@lan1> <200304122336.QAA01503@morrowfield.regexps.com> <85r886seda.fsf@newton.ch.collab.net> <200304131648.JAA04016@morrowfield.regexps.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304131648.JAA04016@morrowfield.regexps.com> User-Agent: Mutt/1.4i X-message-flag: Outlook : A program to spread viri, but it can do mail too. Sender: changesets-admin@sp.red-bean.com Errors-To: changesets-admin@sp.red-bean.com X-BeenThere: changesets@sp.red-bean.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: patch formats, changesets, etc List-Unsubscribe: , List-Archive: Dear diary, on Sun, Apr 13, 2003 at 06:48:41PM CEST, I got a letter, where Tom Lord told me, that... > > > > From: kfogel@collab.net > > >> So the question of "what does all this mean to svn?" is > >> on-topic in the history-of-the-list sense and the > >> larger-context sesne, but not in the idealized-charter sense. > > > That's a fair statement -- and it follows then that I shouldn't > > be viewing this list as though it's mainly meant to serve SVN > > developer's immediate purposes. Sorry, & thanks for the > > reminder, Tom. > > Well, you're welcome, but in my opinion: please don't take it _quite_ > that way. > > Sure, sure -- it's not a list _about_ svn or about arch. > > Personally, I'd like to see it become the mailing list for a working > group with a charter document and semi-formal process, the goal of > said group being something along the lines of (a) writing formal specs > for a whole-tree-diff and whole-tree-patch; (b) providing reference > implementations of those specs. > > I tend to believe that unless we have _some_ structure and > institutionalized agenda like that, real progress will be impossible. > > The two big players in this space right now are arch and svn. There > are other players who we might like to join in (e.g. Bitmover), but > if that's possible at all, I think a little formality and structure > will be necessary to make the invitation credible. Also there is number of people (at least I believe so) on this list not engaged with arch nor svn (development-wise) which would just like to discuss the spatch format. Focusing this too much on arch vs. svn could probably very well end up just as a generic arch<->svn gatewaying specification, rather than a universal new generation diff format with wide usage, which is probably what we all aim to get. > Before we get to those other players: the invitation is already > credible to the arch project ('cause I say so, pfft!). > > So the next thing is to make the invitation credible and compelling to > svn. And that works directly against _much_ of what we know about th