On 10/16/08 22:52, Frank Schönheit - Sun Microsystems Germany wrote:
Hi Heiner,
[...]
Well, you probably already noticed that I'm somehow not very
enthusiastic about maintaining these 1 entries. Remember, you'll
have to add the properties every time someone invents a new top level
Hi,
now that we start working with SVN-based CWSes, those module output
trees (common[.pro], unxlngi6[.pro], wntmsci12[.pro] etc.) become
somewhat inconvenient, as they clutter your svn status output, for example.
http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#Ignoring_output_trees
In short: Can we please add the platform-dependent output tree names
as svn:ignore property to all modules?
+1
Malte.
Frank Schönheit - Sun Microsystems Germany wrote, On 10/16/08 10:53 AM:
Hi,
now that we start working with SVN-based CWSes, those module output
trees (common[.pro],
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
On 10/16/08 11:00, Malte Timmermann wrote:
In short: Can we please add the platform-dependent output tree names
as svn:ignore property to all modules?
+1
+1
-1
Heiner
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
Hi Heiner,
On 10/16/08 11:00, Malte Timmermann wrote:
In short: Can we please add the platform-dependent output tree names
as svn:ignore property to all modules?
+1
+1
-1
I tried to explain why I think the property-approach is better, please
also elaborate why you think it isn't. Just
Moin Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Heiner,
On 10/16/08 11:00, Malte Timmermann wrote:
In short: Can we please add the platform-dependent output tree names
as svn:ignore property to all modules?
+1
+1
-1
I tried to explain why I think the
Hi Heiner,
Well, this +1 or -1 one in s a kind of vote and you normally don't have
to explain your votes. Note that I didn't say We will not do this, I'm
the maintainer of this stuff, basta! :-) Just a vote.
Ah, okay ;)
These are roughly 50 platforms times 191 top level dirs, about 9550
Any explanation for -1?
My explanation for +1: People shouldn't have to care.
If working on some SVN repository based project, all the tweaks should
be automatically there, w/o urging the developer to create any global
svn settings.
If many different projects would start urging the developer to
On 10/16/08 10:53, Frank Schönheit - Sun Microsystems Germany wrote:
Surely the our output tree names/locations are a facet equal across all
working copies, so we should address the issue in the repository.
In a sense, the output tree names are not equal across all working
copies, in that
On 10/16/08 15:41, Jens-Heiner Rechtien wrote:
[...]
There is another reason to use svn:ignore set in the repo:
There is no way to check if all of us lazy devs really set the stuff in
our local svn config.
Having svn:ignore on the output tree dirs should make it extra hard for
one lazy/tired
On 10/16/08 11:00, Malte Timmermann wrote:
In short: Can we please add the platform-dependent output tree names
as svn:ignore property to all modules?
+1
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Hi,
just a little correction ...
[...]
So, I still think putting the stuff into SVN is better ... (Hey, what
did we do the migration for if we don't use all the cool new SVN features?)
... at least for the *most common* platforms - what the *#+%$# is
unxhpxr? And how many people will ever
Hi Heiner,
[...]
Well, you probably already noticed that I'm somehow not very
enthusiastic about maintaining these 1 entries. Remember, you'll
have to add the properties every time someone invents a new top level
directory, which means with most milestones.
We have 191 modules so far,
13 matches
Mail list logo
