On 12/08/08 12:00, Jens-Heiner Rechtien wrote:
I wouldn't call for a complete ban but it looks like one has to be extra
careful. Restructuring should be done in CWS which lives only a very
short time. Best, say, opened on one milestone and integrated in the
next (as first CWS) this would
On 12/08/08 13:11, Stephan Bergmann wrote:
We do need a solution for this problem. No excuses. At least something
as good (erm, bad) as the CVS/CWS situation, where modifications to
moved files at least produced warnings.
http://www.openoffice.org/issues/show_bug.cgi?id=97012 cws rebase
Hi Heiner,
I wouldn't call for a complete ban but it looks like one has to be extra
careful. Restructuring should be done in CWS which lives only a very
short time. Best, say, opened on one milestone and integrated in the
next (as first CWS) this would minimize the potential for data loss.
Hi,
I wouldn't call for a complete ban but it looks like one has to be extra
careful. Restructuring should be done in CWS which lives only a very
short time. Best, say, opened on one milestone and integrated in the
next (as first CWS) this would minimize the potential for data loss.
Doing the
Naively thinking that Subversion with its svn move command would make
it easy to move files around in the OOo code base, I moved
connectivity/source/drivers/odbc/OPreparedStatement.cxx to connectiviy/
source/drivers/odbcbase/OPreparedStatement.cxx (note odbc vs.
odbcbase) on CWS sb102 (then
Hi Stephan,
So, back to good old manual merging: Remember which files you moved
in your CWS, and after every rebase, check whether they miss any
changes to the original files. Sigh.
With the additional hurdle that nobody will warn you about the lost
changes. If the compiler finds them,
On 6. 12. 2008, at 20:45, Frank Schönheit - Sun Microsystems Germany
wrote:
Hi Stephan,
So, back to good old manual merging: Remember which files you moved
in your CWS, and after every rebase, check whether they miss any
changes to the original files. Sigh.
With the additional hurdle that
