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?)
--
Matthew
ENOCOFFEE: operator suffering from lack of sleep and/or early-morning-itis
More information about the kde-core-devel
mailing list