Hi Jan,
Jan Holesovsky wrote:
Hi Heiner,
On Monday 15 January 2007 21:00, Jens-Heiner Rechtien wrote:
For sure I'll have to split out things like the project www pages, etc.
Maybe I'll have to do even something similar to the recent source tarball
split into -core, -binfilter, -l10n, etc.
All the current code modules should be in one repository, I certainly
wouldn't like pulling changesets for one CWS from different repositories
and you loose the benefit of being able to move the files around etc.
And yes, this includes binfilter :-).
Right.
- git push openoffice.org git://any.server/kendy.git
- will publish the changes
And exactly here we would need to setup a full authentication scheme for
the committers which are allowed to push things upstream. That's not
impossible of course but subversion does that already for us. We would
work in a centralized way with a distributed SCM which somehow feels
wrong - and requires us to re-engineer some the features of a
centralized SCM ourselves.
And yet, X.org uses this 'centralized distributed model' -
http://keithp.com/blog/Repository_Formats_Matter.html . Very interesting
reading...
Right. But did you also read Keith other blog about the matter?
http://keithp.com/blog/Tyrannical_SCM_selection.html
There he states that this was his dictatorial decision alone and he
didn't asked his comitter base. He stated having superior knowledge
about SCM tools :-)
Anyway Keith enumerates three reasons for his "git" decision:
1) Offline repository access: for speed reasons (commiting to a local
repository is fast) and being able to work in a plane.
Speed is always a good argument but subversion is not at all bad in this
respect,heck even the CVS committing speed is acceptable. It's the
tagging and branching why we want get rid of CVS. Offline access is IMHO
overrated in times of cheap broadband lines - and how many of us need
repository access in a plane? But then you can do a lot more with
subversion offline than you could do with CVS.
2) The ability to hide work in local repositories (he cites driver
development under NDA): that's exactly what we don't want, we want to
share the code even during development. If there are any secrets ... put
them in a separate module on a private server. That's the only way to
ensure that you don't publish them incidentally.
3) Distributed backups: Now this a kinda inconsistent argument. I would
be more concerned about the content of my local repository on my local
hard disk which might not be upstreamed yet than about the repository
security of a regular maintained and backuped server. Anyway, any
conceivable OOo SCM will have replicated r/o repositories along the line
of cvsup. Subversion 1.4 has such a mechanism which seems to make it
easy to create such replicated repositories.
At any time I can open EIS entry with status 'new' saying, 'I'm
developing feature XY in git://any.server/kendy.git, branch
'myfeature01'.
One of the advantages of a DSCM is that it doesn't need net connectivity
all the time. This is far worse ... you'll need a server which is up and
serving so that others are able to take an early look of your CWS (or
just the tinderboxes and buildbots which are building your CWS). Again,
possible, but with a centralized SCM you get that basically for free and
only one server needs to be up all the time.
Both kernel and X.org host the git trees of the developers on one server, so
this wouldn't be an issue either. But we are probably too deep in
discussions of details, and I still don't have a git import to test with ;-)
I'm looking forward to play around with a git OpenOffice.org repository.
Me too ;-) The import unfortunately failed overnight, I'm re-running it with
the bug fixed.
Heiner
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
