gmane.comp.version-control.arch.devel

Showing ancestor in 3 way merge.

Matthieu Moy — 2005-08-07T18:47:03

Hi, In thelove< at >canonical.com/bazaar--devo--1.5--patch-20, I /tried/ to implement a --show-ancestor option for merge commands. The idea is that the conflict markers should be of the form <<<<<<< TREE lines from TREE ||||||| ANCESTOR lines from ANCESTOR ======= lines from MERGE-SOURCE This would be quite usefull in the case of a small patch applied in a large portion of modified file (TREE and ANCESTOR do not differ much, but ANCESTOR and MERGE-SOURCE have many difference). The way I've implemented it was to remove the "-E" option in the call to diff3. This works fine in the case where TREE and MERGE-SOURCE do not have the same modifications applied. Unfortunately, it also reports a conflict when TREE and MERGE-SOURCE are identical and different from ANCESTOR. Does anybody know the best way to implement what I'm looking for? I didn't find an option doing this in diff3. Either it reports too many conflicts or it doesn't show the ancestor in the conflict markers. Thanks for your help.

important web site updates

Thomas Lord — 2005-08-05T19:04:33

I've made an important change (first link) to http://www.gnuarch.org and http://www.seyza.com Thanks, -t

2.0, history,and merging (was Re: [Gnu-arch-users] arch 2.0 anddelta compression)

Thomas Lord — 2005-07-26T19:30:08

Leaving aside the burning questions of whether the "codeville merge algorithm" is desirable and, for that matter, exactly what it is ... I'll try here to briefly fill in developers on what's in revc re ancestry-for-merging tracking. This is a good point in time, btw, to influence the final design before it is locked down. Here are things you need to know about ancestry in revc, starting with some background: * no more {arch} Revc does away entirely with the `{arch}' mechanism. It has no "in-tree" meta-data whatsoever. Revc *does* create a `.revc' directory at the root of a checked out tree but (a) it does not contain a patch log and (b) it is not a "regular directory" -- it is not part of the inventory of the tree; it is not ever blindly modified by merge algorithms; etc. The complete ancestry of a tree (see below) is available locally, in the .revc dir. The complete ancestry of a tree can be retrieved from its commit record in "O(1)" which means that you can obtain it by op

file-based history commands

Matthieu Moy — 2005-07-26T16:57:59

Hi all, We've discussed some time ago about the ability to see which revision modified a particular file. I'm hacking on this for baz at the moment. The file-based-history-aware "logs" command is more or less operational. Here's a demo (the file used to be scp-global.h and is now pinapa-global.h): $ baz logs -s -- include/scp-global.h patch-12 Use of namespaces in pinapa patch-32 Renamed pinapa source files (scp -> pinapa) patch-33 Renamed all macros and autoconf variables prefixed by SCP patch-34 Updated Copyrights in headers (use LGPL) (=> works fine if you specify the original name) $ baz logs -s -- include/pinapa-global.h patch-32 Renamed pinapa source files (scp -> pinapa) patch-33 Renamed all macros and autoconf variables prefixed by SCP patch-34 Updated Copyrights in headers (use LGPL) (=> follows renaming from the point the file

[BAZ] build on Mac 10.4 fails with -Werror

John A Meinel — 2005-07-25T22:58:24

[BAZ][BUG] Incomplete ancestry mirror messes up "bazget"

John A Meinel — 2005-07-25T22:13:23

[BAZ] lock-revision without parameters

John A Meinel — 2005-07-25T21:01:26

[BUG] Neon 2.5 breaks at least bazaar.

Matthieu Moy — 2005-07-20T09:35:29

register-archive does a t_uchar * temp_location = escape_location (archive_name); which itself does t_uchar * escape_location (t_uchar const *location) { return ne_path_escape(location); } which on libneon 2.5 seems to transform "http://server.com" into "/current/working/dir/http:/server.com". Well, at least, a friend of mine had this strange behavior on MacOS 10.4.2, and downgrading to libneon 2.4 solved the problem.

[BAZ] unit-ar test failure on Cygwin

John A Meinel — 2005-07-19T19:06:14

Travelling to Brazil

Robert Collins — 2005-07-15T14:32:26

attn Tom - hackerlab bug

Robert Collins — 2005-07-15T10:21:54

CVS to arch

John A Meinel — 2005-07-14T21:10:13

Branch API for baz

Robert Collins — 2005-07-14T07:41:54

Arch 2.0 second release

Thomas Lord — 2005-07-13T19:17:56

See http://www.seyza.com [[title GNU Arch 2.0: `revc' ]] [[abstract /GNU Arch/ is a distributed, democratic, changeset-oriented, peer-to-peer revision control system. ]] [[blockquote The second (unstable) release of Arch 2.0 is ready. [[blockquote /SHA1:/ `101e282242cfbcf83d38cca23b9e7ae60c579023' /Size:/ `1743053' ]] This release adds the `changes' command which prints a description of differences between a tree and its immediate ancestor. ]] Revc is currently, tentatively self-hosting however I've not yet officially published the self-hosting archive: some minor tweaks to archive format are still likely to be made in the near future. You can read about: [[blockquote /<"brochure" -- quick-intro.html>/ -- A quick introduction to the core of the `revc' command set. /<"hacker's guide" -- hackers-guide.html>/ -- A quick guide

Annotate postscript

Thomas Lord — 2005-07-13T18:05:10

I should add that the resulting design has a fairly large MasterAnnotate database on disk. Small in terms of storage consumed but a pain to backup or ship over the net. Two things follow: The API to Annotate should be abstract enough to work using a MasterAnnotate DB stored remotely. Probably this comes for free if the `commit' storage manager is used as backing store but the details are unclear to me. In other words: if I mirror your archive but not your MasterAnnotate db, I should still be able to annotate my branches of your source, at least as long as I'm connected to the net. It is probably a good idea to extend the Annotate definition with an "uncertain" or "ancient" output value to cope with cases of partial information: clients may wind up using a MasterAnnotate resource which knows about most but not all of the ancestors in the subject of their query. -t

How to Optimize for Annotate Calculations

Thomas Lord — 2005-07-13T17:58:06

Let's call trees "revisions". Every revision has a unique name. Every revision has a list of earlier revisions which are called its "ancestors". We'll assume that files have some kind of unique identity (could be tags, could just be by filename) such that we can recognize the "same file" between two trees, even if the contents of the file have changed. If you compute a `diff' between a file and the same file in the immediate ancestor tree, all lines that the `diff' reports as unmodified are considered to be inherited from the ancestors and all modified or inserted lines are considered to come from this tree. So there is a function -- kind of like `annotate' but not quite: Annotate_sorta (Revision, File, Line) -> Ancestor_Line | Revision which can be used to find out which lines are modified in a given revision. That function returns a corresponding line number from the immediate ancestor file if the line was not modified; the name of the tree's revision if the line has been modified. Th

arch 2.0 and delta compression

Thomas Lord — 2005-07-12T18:12:14

weaves, If people want the *space efficiency* of delta-compression they are being over-picky: *any* kind of compression that works across the boundaries of individual files will do. It's interesting that you site a second reason to want not only delta-compression but weaves specifically: the I'm very skeptical of "the Codeville merge algorithm" for reasons not terribly important here. Let's stipulate, for the sake of conversation, that it's the greatest thing since toast and, additionally, that it imposes a moral imperative on revctl developers to optimize-for-annotate. Piece of cake. If people are serious, we can perhaps make this a 9-month goal for revc 2.5. The difficulty, and why I'm not leaping to the cause on this one at just this moment, is that optimize-for-annotate complicates storage management by -- guessing -- 3x lines of code. I.e., I have maybe a few hundred lines for reading and writing blobs -- that would grow to a couple of thousand. And trickier code, too. Since I'm skeptica

GNU Arch 2.0 -- first source

Thomas Lord — 2005-07-08T20:57:46

build-config, I need your opinion.

Matthieu Moy — 2005-07-04T21:03:53

Hi, I've just added a --switch option to "baz build-config". The behavior is the following: * When a subdirectory doesn't exist, create it as usual (baz get) * When a subdirectory already exist, run "baz switch" to set the version to the requested one. As a result, "baz build-config --switch" looks like "baz update", but for configurations: It preserves local changes and non-source files in the project tree, but upgrades to the latest version available. I'm thinking about making this the default, and provide an option --backup or something like this to go back to the old behavior. Perhaps a "--update" running update (keeping the version) instead of switch would be usefull too. Typical use-case: I have a local tree of bazaar, developing a feature in my own branch for ./src/baz. It takes some time, and other people commit to the master archive, both in baz and hackerlab in the meantime. I merge from the master, and try to recompile, but figure out I need the hackerlab modifications too. Then, I could

directory closures in baz and tla 1.x

Robert Collins — 2005-07-04T05:28:54

FEATURE REQUEST: multiple ids per file

Jonathan Geisler — 2005-06-30T17:33:57