Things to remove for 2.0

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gioele Barabucci wrote:
> Aaron Bentley wrote:
>>> I still don't see many practical uses for a split operation that does not
>>> really split a directory off a tree, it just hides the other directories.
>> It doesn't hide them.  They are gone from that tree.  They exist in the
>> history, because history is not mutable.
> I'm not suggesting to make split modify the branch history. It should create 
> a new branch with a refined/filtered history.

You are suggesting that split create a new history and associate it with
the tree produced by split.  That is what I mean by rewriting history,
but not what I mean by "history is not mutable".  Your proposed change
would mean that the history associated with that tree would be different
from the history that was associated with those files before you ran split.

By "history is not mutable" I mean that for a given revision-id, there
must be one and only one state.  I don't think we disagree about this,
just that you didn't understand what I meant by it.


>> The practical use is that it retains the ability to merge with related
>> trees.  In particular, it makes Nested Trees possible.
> From what I see it makes the nesting of some trees easier. But I doubt that 
> is something really needed.

I introduced split specifically because it would be useful with nested
trees.

> As I said earlier, I see a very common use case for split implemented on top 
> of fast-import-filter. What I don't see is a practical use case for split as 
> it is now.

Splitting one project into pieces, as we recently did with Launchpad
before releasing its source.

> For example a Google search for "bzr split" returned no articles 
> or tutorials about that commands. Does anybody use it?

I don't think that it is commonly used, but I don't think that any split
command would be commonly used.  However, Launchpad used it in
preparation for our open-sourcing.  The person who did the split made it
clear that preserving history was important to him.

> The common use case for split as I suggest is as follows. A team develops a 
> big project (let's say a database). after a bit of time (years) the code is 
> refactored and it is seen that a certain part of the project (the Makefile 
> generator) could live as a separate project and should be split from the 
> original project. Luckily it is all contained in the tools/makegen 
> directory. Now, if they had a bzr split command that behaves like fast-
> export + fast-import-filter they could split that directory, create a 
> project on launchpad for the Makefile generator and upload a 200 KB branch 
> with a dozen of file. With the current split command, the history could be 
> as a big as 20 or 40 MB and would contain references to completely unknown 
> files (unknown to the Makefile generator users). Is merging useful in this 
> case? No, the directory lives its one life as a new project and both the 
> original project and new projects would use something like 'bzr link-tree 
> lp:makefile-gen tools/makegen' (bzr link-tree is, maybe, more explanatory 
> than bzr join).

In scenarios where shared repositories and stacking are not used, your
version of split would produce a smaller output.  In scenarios where
stacking or shared repositories are used, the current approach produces
a smaller output.

> Back to practical use: do you think this kind of scenario happens too 
> infrequently to justify a dedicated command?

Yes, but more to the point, rewriting history is generally bad.  It
prevents merging.  Consider the example of bzr.  If we split bzrlib out
from bzr itself using your command, we would be unable to merge fixes
from pre-split bzr into bzrlib.

Doing what you're suggesting should be hard.  It should be off the
beaten path.  It should be done by people who understand the
implications, because breaking associations is a destructive act.

> If so, how often is "split", as is now, used?

At least twice.

>> And what is your argument against join, btw?
> Well, join should be adapted to match the new split, that's all.

Why?  The current version of join would work perfectly well with the
split you've described.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpqCl0ACgkQ0F+nu1YWqI2M4QCePSnei5SBli5/oMhoP7yVQ9mE
HnIAn1vALC7IL7bonaqafn4a7QnLoEeV
=8Qpc
-----END PGP SIGNATURE-----