[Kde-scm-interest] Git roadmap

[Oswald Buddenhagen]

On Tue, Sep 18, 2007 at 10:42:23AM +0200, Thiago Macieira wrote:
> On Tuesday 18 September 2007 10:22:31 Oswald Buddenhagen wrote:
> > On Tue, Sep 18, 2007 at 09:27:19AM +0200, Thiago Macieira wrote:
> > > Another issue is the use of svn:externals. [...]
> >
> > hmm, does git version fs metadata (directories, permissions,
> > symlinks) at all?
> 
> Symlinks are special entries in the git tree. So, they are handled
> like any other file.
> 
good. not that we could use them, given windows ...

> Directories are "versioned" in the sense that git keeps track of them and 
> erases once they are empty. But empty directories are not supported. Add 
> a .gitignore file there if you want to keep it.
> 
feels a bit like cvs. ;)

> The only permissions that are kept are the execute bits.
>
that's fine.

so i guess the basic metadata support is fine.
externals ... well, the meta-modules we're talking about all the time
are *sort of* externals. i'm sure the concept can be extended.

> > > Unfortunately, they have. It's the copy across modules, like I said
> > > above.
> >
> > exactly. this is the reason why we should have per-app/lib repos.
> > kdelibs is no exception. organization would be done by two levels of
> > meta-repos.
> > this also solves the problem of partial tags/branches.
> > the trunk move would be basically just a special case of a module move.
> 
> Not sure I agree. It doesn't solve completely the problem of 
> copy-across-modules.
> 
sure it doesn't, i haven't touched that problem in this paragraph. ;)

> In fact, the more modules you have, the worse this problem is: we did
> a lot of moves between kdecore - kdeui - kio in the past year,
> probably as many as we did between kdelibs and kdebase/runtime.
>
indeed. but why should the ones be better off than the others? :)

> > finer grained moves across modules should leave a log entry with an
> > url that can be directly followed to the old location. replaying
> > history or something would be nonsense, and it wouldn't work in
> > later day-to-day use anyway.
> 
> Hmm... you're saying "when we move, ignore old history but add a note
> where it came from". This goes back to what we had with CVS without
> server-side moves.  It's a loss in functionality I'd like to avoid if
> we can.
> 
well, we can't avoid the problem without keeping a single monster repo.
but we can solve it ... there can be formalized log entries on both the
source and target side, with the tools automatically following the
links.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.