[dev] Re: Moving files in a Subversion CWS

2008-12-08 Thread bjoern michaelsen - Sun Microsystems - Hamburg Germany

Jens-Heiner Rechtien wrote:

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.
As first CWS? Wouldnt that doom any changes from other CWS on the moved 
files because the file is already deleted when they are itegrated. 
*Confused* I thought _last_ CWS would be the safest ...


Still data loss is possible even in this scenario, which IMHO is very 
scary.


I would feel much more comfortable, if a naked move wouldnt be possible. 
As an (ugly, very ugly) workaround for now, we might need a command in 
the cws tool that registers the moved files by their old name (the 
name it is known as on the master) somewhere. This could be either in a 
svn property (on trunk??) or in a administrative file somewhere. It 
should at least be noted, if changes to a file are wandering to /dev/null.


Have Fun, Björn


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



[dev] Re: Moving files in a Subversion CWS

2008-12-08 Thread bjoern michaelsen - Sun Microsystems - Hamburg Germany

Frank Schönheit - Sun Microsystems Germany wrote:

Perhaps a postprocess hook which sends mails to EIS, keeping track of
moved files, and issueing warnings upon integration when some change is
about to be lost?
I fear this is not possible in post-commit, as the info that something 
was a move isnt available anymore, because it will show up as a delete 
and an addition in the commit when you analyse it with svnlook.


ugh.

Best Regards,

Björn


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



Re: [dev] Moving files in a Subversion CWS

2008-12-08 Thread Stephan Bergmann

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 minimize the potential for data loss.
Doing the restructuring in a big CWS which needs many month to complete
won't do it, I completely agree here.


Restricting restructuring this way simply does not work.  For example, 
CWS sb102 simply *had* to move files (because different .cxx files in 
the same directory, controlled by the same makefile.mk turned out to 
need different CDEFS; of course, instead of cleaning up and splitting 
into two directories, I could have improved solenv/inc by introducing 
LIB1CDEFS, LIB2CDEFS, ...), and simply *had* to last longer than one 
milestone (simply because fixing issue 95065 so that it still works on 
Windows takes so much time).


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.


-Stephan

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



Re: [dev] Moving files in a Subversion CWS

2008-12-08 Thread Stephan Bergmann

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 
silently loses modifications to moved files


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



Re: [dev] Re: Moving files in a Subversion CWS

2008-12-08 Thread Frank Schönheit - Sun Microsystems Germany
Hi Bjoern,

 As an (ugly, very ugly) workaround for now, we might need a command in 
 the cws tool that registers the moved files by their old name (the 
 name it is known as on the master) somewhere. This could be either in a 
 svn property (on trunk??) or in a administrative file somewhere. It 
 should at least be noted, if changes to a file are wandering to /dev/null.

Perhaps a postprocess hook which sends mails to EIS, keeping track of
moved files, and issueing warnings upon integration when some change is
about to be lost?

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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



Re: [dev] Moving files in a Subversion CWS

2008-12-08 Thread Frank Schönheit - Sun Microsystems Germany
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.

I'd say that anything which does not *eliminate* the potential for data
loss should be a no-go. Sorry, but I really do not like finding out
short before a release (or even short after it) that some important
fixes done during the last 6 months just silently vanished.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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



Re: [dev] Moving files in a Subversion CWS

2008-12-08 Thread Jens-Heiner Rechtien
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 restructuring in a big CWS which needs many month to complete
won't do it, I completely agree here.

I think I remember having read something about a warning system someone
devised but I just can't find the reference, Have to look harder.

Heiner

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 nobody will warn you about the lost
 changes. If the compiler finds them, that's fine, but if you just lose a
 small bug fix, then may not notice this at all.
 
 However, what worries me deeply is the [not] true data loss scenario  
 upon svn merge --reintegrate described at 
 http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves
  
  .  A disaster waiting to happen, I would say.  Or am I missing  
 something?
 
 I tend to agree here. Just recently asked Heiner about this, and in my
 opinion, both scenarios effectively mean we should completely ban svn
 move, as it has a pretty large potential to silently destroy our code base.
 
 Which is a pity, as this is *the* feature of SVN which made it worth
 suffering the additional complexity introduced with it.
 
 Ciao
 Frank
 


-- 
Jens-Heiner Rechtien
[EMAIL PROTECTED]

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



Re: [dev] Re: Moving files in a Subversion CWS

2008-12-08 Thread Jens-Heiner Rechtien
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
 Jens-Heiner Rechtien wrote:
 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.

 As first CWS? Wouldnt that doom any changes from other CWS on the moved
 files because the file is already deleted when they are itegrated.
 *Confused* I thought _last_ CWS would be the safest ...

That's not a problem because changes to no longer exiting files will
trigger warnings.

Heiner

 
 Still data loss is possible even in this scenario, which IMHO is very
 scary.
 
 I would feel much more comfortable, if a naked move wouldnt be possible.
 As an (ugly, very ugly) workaround for now, we might need a command in
 the cws tool that registers the moved files by their old name (the
 name it is known as on the master) somewhere. This could be either in a
 svn property (on trunk??) or in a administrative file somewhere. It
 should at least be noted, if changes to a file are wandering to /dev/null.
 
 Have Fun, Björn
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-- 
Jens-Heiner Rechtien
[EMAIL PROTECTED]

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



[dev] RSS feed to EIS?

2008-12-08 Thread Ariel Constenla-Haile
Hello there,

I'd like to keep truck of some CWS activities in EIS (well, mostly when
they get integrated), are there RSS channels to this kind of info? I've
been searching with no luck, so I guess there is none, but...

And also, is there some RSS to truck when a new tag is added (instead of
browsing everyday in http://svn.services.openoffice.org/ooo/tags/ )
All I've found is http://cia.vc/stats/project/OOo/.rss/customize but
didn't help me much.


Regards
Ariel.

-- 
Ariel Constenla-Haile
La Plata, Argentina


Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter.
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.



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



Re: [dev] RSS feed to EIS?

2008-12-08 Thread Frank Schönheit - Sun Microsystems Germany
Hi Ariel,

 I'd like to keep truck of some CWS activities in EIS (well, mostly when
 they get integrated), are there RSS channels to this kind of info? I've
 been searching with no luck, so I guess there is none, but...

I'd love to have some kind of CC functionality to EIS. That is, you
can subscribe yourself to a CC list for a given CWS, and then all
changes to this CWS are mailed to you. Pretty much how CC lists in issue
tracking systems work.

Would be most fine grained control over how many mails you get (only the
ones you're really interested in), and should on the other hand be
pretty simple to implement :)

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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



Re: [dev] RSS feed to EIS?

2008-12-08 Thread Ariel Constenla-Haile
Hi Frank,

Frank Schönheit - Sun Microsystems Germany escribió:
 Hi Ariel,
 
 I'd like to keep truck of some CWS activities in EIS (well, mostly when
 they get integrated), are there RSS channels to this kind of info? I've
 been searching with no luck, so I guess there is none, but...
 
 I'd love to have some kind of CC functionality to EIS. That is, you
 can subscribe yourself to a CC list for a given CWS, and then all
 changes to this CWS are mailed to you. Pretty much how CC lists in issue
 tracking systems work.

so this means: No there is no such a functionality.

 Would be most fine grained control over how many mails you get (only the
 ones you're really interested in), and should on the other hand be
 pretty simple to implement :)

does this mean Please, file an issue?
In that case, who owns that (component/subcomponent/owner)?

Regards
Ariel


-- 
Ariel Constenla-Haile
La Plata, Argentina


Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter.
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.

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



[dev] OOo BoundsChecker How-To

2008-12-08 Thread Malte Timmermann
Hi,

it's been a while (6 years) that I had created an OOo BoundsChecker
How-To, and I had to figure out that it was not 100% up to date anymore ;)

Some changes had been necessary to reflect 3-Layer-Office and new Memory
Manager.

Instead of updating the html file in the tools project, I decided to
create a Wiki page for this, which will make it easier for further changes:

http://wiki.services.openoffice.org/wiki/Error_Detection_with_BoundsChecker

The old html file will point you to that direction.

HTH,
Malte.

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



Re: [dev] RSS feed to EIS?

2008-12-08 Thread Frank Schönheit - Sun Microsystems Germany
Hi Ariel,

 I'd like to keep truck of some CWS activities in EIS (well, mostly when
 they get integrated), are there RSS channels to this kind of info? I've
 been searching with no luck, so I guess there is none, but...
 I'd love to have some kind of CC functionality to EIS. That is, you
 can subscribe yourself to a CC list for a given CWS, and then all
 changes to this CWS are mailed to you. Pretty much how CC lists in issue
 tracking systems work.
 
 so this means: No there is no such a functionality.

Uhm - well yes, I really wasn't too explicit here :)

 Would be most fine grained control over how many mails you get (only the
 ones you're really interested in), and should on the other hand be
 pretty simple to implement :)
 
 does this mean Please, file an issue?
 In that case, who owns that (component/subcomponent/owner)?

Not sure if EIS RFEs are handled via IssueZilla, too. I'd say
component=tools, subcomponent=??, owner=bei (Bernd Eilers).

Usually, Bernd is reading here and picking up easy-to-fix ideas quickly,
but an issue might help.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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