recent changes

[Martin Pool]

On 20 Jun 2005, John Arbash Meinel <john at arbash-meinel.com> wrote:

> Is this designed to be similar to monotone's merge functionality? Where
> two branches diverge, and then are merged back together again?

Yes, it's more similar to monotone.  It's only a change of degree from
what was previously planned, which was to have a single parent and a
list of merged-revisions, but they were mostly treated as identical.  

Unlike monotone, any particular branch still has a linear mainline
(from revision-history).  Those revisions might be present, but not
mainline, on another branch.

> This makes the "common_ancestor" code more complicated, since you have
> potentially multiple paths to follow, but at least you can detect old
> merges.

Common-ancestor (or rather, best-common-ancestor) is a tricky problem,
as we know, but I don't think this makes it any harder.  We still have
the option of trying to find an ancestor only on the revision-history
path of the two branches, which will find the point they diverged.

> Interesting. Might I recommend creating either a "test" package, or
> possibly a whitebox & blackbox packages. I'm just thinking that as time
> goes by, we'll probably want a very complete set of tests, and it would
> be cleaner if we could break them into multiple files, and not have it
> pollute the bzrlib directory.

Yes, it's probably better to keep them a bit separate.

I think some of Aaron's earlier code had tests within the modules
themselves, which is attractive in some ways but does make the files
larger and probably slow load time.

> My idea would be something like:
> 
> bzr.dev/bzrlib/
>     commands.py ... etc
>     selftest/
>         __init__.py
>         whitebox/
>         	__init__.py
> 		a_test.py
>         blackbox/
> 	        __init__.py
> 		a_test.py
> 		...
> 
> 
> 
> I like the idea of having everything under "bzr selftest" rather than a
> separate front end.
 
> I also think we would want to use "subprocess" if it is available, and
> fall back to something that looks a lot like it.
> Because you can install it as a module for 2.3, it is built-in to 2.4,
> and it is much nicer than os.system, or popen*

I'm going to try to avoid subprocess unless there's something in there
we really need; I think the 2.3 functions may be enough.  os.system is
probably never much use since the shells differ so much between
windows and unix that any actual shell code won't work.

-- 
Martin