New semantics for split and join in bzr 2.0

Gioele Barabucci gioele at svario.it
Sat Jun 13 12:03:54 BST 2009


Jelmer Vernooij wrote:

>> That is, split the subtree in an *independent* branch. I used this
>> myself and I see many use cases where this would be useful. When are the
>> current actions of split and join useful?
> They're useful if you're splitting a new project out of an existing one.
> E.g. if you have a library that you're splitting out of an existing
> project to be a separate project.
That is what the name suggest. But what split and join do is to create a new 
branch that focus on a certain dir 'bzr rm'-ing the non needed files and 
moving the tree to root. All the history (log and revision) from the old 
project is retained, not only the part related to that subtree. This means 
that a project split from from a larger project retain all the original 
data; I don't see how this could be useful for a (now) separate project. 
Yes, you can merge things back more easily, but is that an important feature 
of a *separate* project? I think nested trees is how separate projects 
should be integrated back in the main project.

>> As 2.0 is approaching, it would be a good occasion to change the
>> semantics of these commands and move the old semantics to a separate
>> plugin.
> That approach is history-destroying, why would it be preferable over the
> current approach?
Well, the command is called "split", not "softly-separate" or "focus-on". ;)

When I wanted to split a directory into its own project I felt the need to 
remove all the unneeded history (and luckily Ian Clatworthy implemented
fast-import-filter short after my request, thank you again Ian). The fact 
that I was losing the ability to merge back has never been a problem to me. 
Instead, the ability to get rid of hundreds of megabytes of past history and 
files (not just in the working tree but in the .bzr files as well) and 
having a non-polluted log were way more important.

My question remains: what are the use cases for a split command that retains 
*all* the past history and whose bzr log output contains stuff and 
references to files no longer or never present in that directory?

Also, how (conceptually) does the current split differ from  a filtered 
view?

-- 
Gioele Barabucci <gioele at svario.it>





More information about the bazaar mailing list