[Kde-scm-interest] distributed source control status

[Thomas Capricelli]

On venerdì 10 ottobre 2008, Boyd Stephen Smith Jr. wrote:
> >	The only other option is mercurial I think.
>
> I'm fairly sure the project is considering any DVCS.

Sure, but i meant that I can't see any other serious contender.


> That's what any DVCS needs to be seriously considered.  Someone needs to
> perform testing to generate a concrete migration plan -- including scripts
> or instructions to do the migration.

I'm ready to provide this.

> Beyond just
> converting the repository to another format, scripty needs to be taught to
> work on the new repository

Mmh, that's this i guess ? :
http://developer.kde.org/documentation/other/whatisscripty.php
I did not know about it, but according to this page, most of the work is 
independant of the source control. Though there are quite some svn* files in 
trunk/kdesdk/scripts. I'll look into this, but this is probably not too hard 
to do.

> we need something to replace kdesvn, and the 

This one is easy : whether on linux (hg view) or windows (tortoise hg), 
mercurial comes with something that i find a lot more useful than kdesvn (I 
use kdesvn for all my svn projects). See some screenshots here:

linux (made my own as i can't find any official ones):
http://www.freehackers.org/media/orzel/kde-mercurial/screenshots.hgk.1.png 
(strigi)
http://www.freehackers.org/media/orzel/kde-mercurial/screenshots.hgk.2.png 
(kdebase)

windows:
http://tortoisehg.sourceforge.net/images/screenshots/tortoisehg-snapshot-overlayicons.png
http://tortoisehg.sourceforge.net/images/screenshots/tortoisehg-snapshot-contextmenu.png


> DVCS should have kdevelop integration.

Good poitn, I'll look into this.

> Assuming Mercurial is similar to Git in that an initial checkout
> (generally) includes all history, we will definitely want to split the
> repository by module (and for some modules, have them split as well).

I think so, too.

> You should review some of Thiago's posts about how he was considering
> arranging the git repositories, at least as a starting point.  Keep in
> mind that while we want to keep initial checkout small, we also need to
> way to do atomic commits across multiple modules (or something close to
> atomic.)

Yes. It seems to be the most difficult part, either for git or mercurial. To 
have distinct repositories, but a kind of atomic commit. I will see what can 
be done.


Thomas
-- 
Thomas Capricelli <orzel at freehackers.org>
http://www.freehackers.org/