External SVN item in kdebase/runtime/nepomuk/services/queryservice/lib

Matthew Woehlke mw_triad at users.sourceforge.net
Thu Sep 18 23:17:37 BST 2008

Thiago Macieira wrote:
> Matthew Woehlke wrote:
>> For that matter, I wish git would support partial checkouts, at least
>> the kind that pick one directory deeper into the tree...
> The problem with that is most developers will argue that you should have 
> the full checkout of the module. You have to make sure everything still 
> compiles when you're done.
> The problem is the concept of "module": it's supposed to be one single 
> unit of related files. It doesn't exactly map to our concept of modules 
> in KDE.

That's exactly what I was thinking of. We have instances when you 
sometimes want to have a set of loosely-related files in a single 
checkout. kdesupport is probably the best example (not so long ago I 
switched from single checkouts of kdesupport bits to building all of 
kdesupport at once). kdebase is another instance. You can manage without 
this with multiple checkouts (in fact, having "metamodules" that have 
some stitching and a number of git externals is probably the best way to 
go), but it can certainly result in more work...

The other thing that bothers me is, I think you would lose history doing 
cross-module merges? For example, in our current playground -> review -> 
trunk model, when you move, you keep history, not only the changes, but 
that FooModule used to be in playground. With git I assume you can 
replay the checkouts to not lose the history outright, but you've still 
lost the metadata of where it came from (plus you now have duplicate 
history, though I suppose you can just nuke the old module).

(Seasonal branches might mitigate this, but what about situations like 
we had with Kate, that moved from kdebase (IIRC?) to kdesdk?)

ENOCOFFEE: operator suffering from lack of sleep and/or early-morning-itis

More information about the kde-core-devel mailing list