Hi Ruediger,

On Wednesday 25 April 2007 17:03, Rüdiger Timm wrote:

> > What we need is a tool that allows us to have a modified codebase
> > (ooo-build) while we are still able to contribute the modifications back
> > to up-stream easily.  Today we solve it with huge amount of patches
> > (~1000), we have to create CWS'es from that, and it's becoming hard to
> > manage, especially with
>
> I see how a DSCM would help you maintain ooo-build and that SVN would be
> no omprovement here. But, contributing back would not be influenced by
> whatever SCM we have. That would be by CWS in any case, I think

CWS is for me the same as branch in the DSCM world, but it is not in the world 
of the current up-stream/ooo-build distinction - because currently we have to 
perform extra steps to commit our work to a CWS [and it would be the same 
with CWS on top of SVN]; with DSCM it would be a no-op, because up-stream 
could pull the branch directly from ooo-build (it is all one project!) 
without any tweaks.

> > I also hope you don't want to do just a partial import as I saw
> > somewhere; one where the history would consist just from 'integration
> > commits' & the history in the branches would be abandoned.  This would
> > completely screw the ability to blame someone for a change that happend
> > in CVS; and there would be no way back even if we decided to go with git
> > (or any other DSCM) later - the information would be missing then.
>
> See Heiners description of our current plans at
> http://wiki.services.openoffice.org/wiki/SCM_Migration
> Yes, we want to keep main part of history (though not all old branches).
> This BTW seems to be a big advantage of SVN: import into git in a
> reasonable time frame up to now only succeeded without history, AFAIK.
> But, please correct me if I am wrong here.

Hmm, "skip tags and branches of all CWS with status integrated, finished, 
deleted or canceled at a certain date (currently the date is 2007/05/15)" - 
this scares me a lot :-((  If I understand it correctly, svn blame will be 
useless, everything in integrated branches will be lost.  What is the reason, 
please?

> > Yes.  A prerequisite for seeing the most advantages from the move to DSCM
> > is a split of the sources to smaller parts - URE, OOo w/o URE, copies of
> > the system libraries, translations, ODK.  [And ideally even a separate
> > ODF toolkit ;-)]
>
> Why would this be a prerequisite?

Prerequisite for the most advantages?  Because the history is an integral part 
of DSCM (git) tree.  Once you commit the packed mozilla there, it grows by 
the XY MB, and will never shrink again; but it is OK to have it in the 
history of some 3rdparty-libraries.git tree - which is downloaded just by the 
ones who really need it [eg. the recent Linux distros have them in, and it's 
possible to build against them].  And you don't have to checkout/update all 
the 3rd party libraries like berkeleydb, boost, etc. with every milestone, 
when they change (in a binary incompatible way) let's say once in few years.

Also, for normal developers hacking on the core, the translations are useless 
as well; similarly ODK.

Of course, we can have everything in one big tree; but it is 
somehow...suboptimal.  Having one big tree and create from it once URE, OOo 
at another time, something else for the 3rd time leads not to code reuse, but 
to copy and pasting.

Regards,
Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to