On 10/20/08 09:11 AM, David Tardon wrote:
Seems that sc/source/ui/app/template.cpp is an unused file--it's not
built, it includes header which is not present anymore. Why it hasn't
got deleted yet? Or did it reappeared during CVS-SVN conversion?
Just small enough so it was never noticed. It
Hi list,
since we now have subversion, we might as well use the new features it
provides. I wrote a precommit hook on the weekend that does some
precommit sanity checks:
- It rejects commits changing files in a cws and outside of it (thus
hopefully preventing some accidental commits to a
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
Hi list,
since we now have subversion, we might as well use the new features it
provides. I wrote a precommit hook on the weekend that does some
precommit sanity checks:
- It rejects commits changing files in a cws and outside
On 10/20/08 12:56, Frank Schönheit - Sun Microsystems Germany wrote:
... modules ...
Not sure this is needed. AFAIK it is (at least in CVS times it was)
necessary to do other things for adding a new module (announcement to
releng etc.), so just preventing the commit doesn't really solve a
Hi,
Am 18.10.08 03:24, Nguyen Vu Hung schrieb:
It is obvious when we look at ls -l and I don't care to diff.
At least the folder script/{win32,unix} are missing so we can't run the
test.
with introducing testautomation module the automation team has cleaned
up the structure and the tests so
On Mon, Oct 20, 2008 at 01:55:11PM +0200, bjoern michaelsen - Sun Microsystems
- Hamburg Germany wrote:
- I like the module organization section, but would add more, like
e.g. the convention of building libs one directory up (for
Writer), what generally the util prj dirs are for
On 10/20/08 12:51, Rene Engelhard wrote:
How should that be possible when you svn switch a complete tree to a cws
(which you should do)?
There's no need for any checks at all, if everybody does what he should
do ;-).
There's no modules anymore but one big tree. That check imho is moot.
Hi Björn,
Given that pre- and postcommit hooks are basically working the same,
using this precommit hooks as a base to create a postcommit hook should
be easy.
See issue 95199 for my currently prepared (and already implemented)
solution, though a post-commit hook also sounds interesting.
On 10/20/08 15:08, Frank Schönheit - Sun Microsystems Germany wrote:
See issue 95199 for my currently prepared (and already implemented)
solution, though a post-commit hook also sounds interesting.
I just tried to add an svn:ignored dir. That works.
If someone does a svn diff in a module, and
Thorsten, all,
I assume the below commits to tags/DEV300_m33 are in error, and should
instead have gone to some cws?
-Stephan
On 10/20/08 13:59, [EMAIL PROTECTED] wrote:
Author: thb
Date: Mon Oct 20 11:58:48 2008
New Revision: 262317
Log:
#i95197# Fixes valgrind warnings by shuffling code
Hi Bjoern,
I just tried to add an svn:ignored dir. That works.
Sure - svn:ignore is just for ignoring the item in status and recursive
commits.
If someone does a svn diff in a module, and sees:
? source/somenewfile.cxx
? source/somenewfile.hxx
he might be tempted to do a 'svn add *; svn ci
Yup,
Thorsten got the price for being the first developer to commit on a tag.
Please clean up this mess.
I'm still pondering the question if it's a good idea to prevent people
doing such commits. I'm normally not a friend of overly strict access
controls as they tend to get in the way later.
To whom it may concern,
First, I want to just say that ever since I heard about OpenOffice programs
and downloaded them, I fell in love with them! You guys do a wonderful job.
I am curious though. I don't know where you are at or if you even would
consider this, but I will toss the idea out
Hi Bjoern,
there was no need for crucifying yourself, server side we are python
only. Actually we have no perl bindings installed.
I think we need to be a bit carefull with pre-commit hooks. Other than
post-commit hooks they do influence the user experience of SVN, so
they have to be fast. Well,
Hi,
Jens-Heiner Rechtien wrote:
I somehow don't like tying SCM functionality to commit messages, but
that's may be just me.
And should we enforce policy (like tabs vs spaces etc) via the SCM tool?
is there another point where we could actually enforce policy ? Enforce
as in preemptive, not
On 10/20/08 17:39, Philipp Lohmann wrote:
Hi,
Jens-Heiner Rechtien wrote:
I somehow don't like tying SCM functionality to commit messages, but
that's may be just me.
And should we enforce policy (like tabs vs spaces etc) via the SCM tool?
is there another point where we could actually
On 10/20/08 17:10, Jens-Heiner Rechtien wrote:
there was no need for crucifying yourself, server side we are python
only. Actually we have no perl bindings installed.
If I only had known that before. I like and know Python a lot better.
I think we need to be a bit carefull with pre-commit
17 matches
Mail list logo
