[Kde-scm-interest] Meeting minutes

[Oswald Buddenhagen]

On Thu, Nov 12, 2009 at 01:12:25PM -0600, Ian Monroe wrote:
> > - loss of history. there are only two clean ways to preserve history
> >  when moving around applications: have everything in one repo (like in
> >  svn, but that just plain does not work with git) or have no need for
> >  moving at all, i.e., have idependent atomic applications and do moves at
> >  an abstract level (possibily via submodules).
> 
> It is possible to move an independent git repo into another. Its not
> trivial, not something you want to do everyday, but it is possible.
> 
i said *clean*.

> But actually this is one of the reasons we want to keep the kde
> modules whole. It becomes trivial to move stuff around within kdebase
> for example.
> 
moving stuff within a module is probably the more seldom case. usually,
stuff gets moved between modules (typical application "introduction
cycle", random app code moving to kdelibs). i think optimizing the case
of keeping the history of big logical entities as a whole intact is more
important than a few random files that happen to have the luck to move
within one module.

> > - merging mess (random conflict resolution). forward-merging stable =>
> >  master is hard enough in qt already, and that's a well-organized
> >  (kinda ;) company of full-time workers and "only" two major time zones.
> >  imagine the bottlenecks in a disorganized bunch like kde. it simply
> >  won't work.
> 
> Huh? Why would there be a merging problem for "unrelated" apps in the same repo?
> 
- dev1 pushes fix to app1 stable
- somebody pushes conflicting fix to app1 master
- dev2 pushes fix to app2 stable
- dev2 wants to merge stable => master so he can build upon the fix in
  stable. he gets the app1 conflict. if he can't fix it and dev1 cannot
  be reached at this time, dev2 is screwed.
- alternatively (more commonly) the "usual merge monkey" does the
  forward merging. he may need to consult several people to resolve
  conflicts.

the alternative to that scenario is everyone doing a fix in a stable
branch doing the forward-merging himself. however, that is impracticable
for effort reasons, and leads to a nasty history with tons of merges.

> Just so its clear we're not using git-svn to do the import. :)
> 
oh, well.

> Harald Sitter is also working on one to provide CCMAIL and such to
> Amarok in Ruby. Not sure if you can coordinate or not.
> 
well, he's aware of it ...