Am 03.08.2011 21:23, schrieb Mathias Bauer:
On 03.08.2011 10:38, IngridvdM wrote:
Am 03.08.2011 10:24, schrieb Stephan Bergmann:
On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
Ok agreed, binfilter is not the best example.
But what about the general idea to have a second directory where we can place
all the stuff that is not needed to build the main office (so not needed in the
usual day to day work of a code developer), but anyhow belongs to the product
and to each codeline/release.
Maybe templates or some extensions could qualify for this stuff. Maybe we have
nothing right now but my point is, if we identify such things later I do not
want to clutter the directory structure with more and more directories next to
trunk.
Remember, with svn the complete directory structure can always be changed. So
I see no need to come up with a perfect solution up front.
It is not only svn to think about. When it comes to building and
packaging and creation of release branches there is easily a lot of
scripting involved. Those things are often not so nice to change
afterwards. So may we can think a day or two about a good directory
structure before. ;-)
As Stephan wrote, the structure can be changed easily afterwards.
Building and packaging should follow dependencies (after all that was
the idea of our new build environment) and so the directory structure is
of second order importance.
Besides that I agree that moving parts that are already known to be no
part of the regular OOo installation set into separate top level
directories makes sense. We just shouldn't dive too deep into that now.
Agreed and it wasn't my point to dive deep into which single parts
should be moved around. My point was only to prepare that we can move
parts with less hassle later. I just want to prepare the target
directory for such moves. Nothing more, nothing less. It is really a
quite simple and quick question that could be solved right now.
What directory setup do you prefer and why:
1)
ooo/trunk/main/sw
ooo/trunk/extras/l10n
or 2)
ooo/trunk/sw
ooo/l10n
I would prefer 1) because it accumulates all that belongs to the trunk
code line in the trunk directory, while still allowing to easily check
out only one directory for the typical day to day code development.
Collecting more and more directories outside trunk that logically would
belong to trunk, will complicate the creation of release branches
unnecessarily. In addition something that is not logically is a problem
in itself, because it confuses people.
Kind regards,
Ingrid
Regards,
Mathias
