directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: All projects folder in svn
Date Wed, 19 Jan 2011 20:09:49 GMT
On Wed, Jan 19, 2011 at 5:50 PM, Emmanuel Lécharny <> wrote:
> On 1/19/11 4:39 PM, Alex Karasulu wrote:
>>> Here we keep other branch specific svn:externals folders that
>>> reference project branches in their respective areas under svn. We can
>>> use a convention like<branch-name>-with-dependencies for such link
>>> folders on branches. This may however be redundant, so maybe we can
>>> just use the<branch-name>    by itself. It's already understood to be
>>> "link folder" because of it's location. WDYT?
>>> I'm wondering if we should not create a meta-project for apacheds. It's a
>>> bit painfull to have to co trunk-wih-dependencies :/
>> What is a meta-project?
> Well, instead of having a trunk-with-dependencies in
>, I'd rather prefer having a
> that points to all the
> sub-projects. I guess that it's what you proposed with the generic trunk.

OK so just for clarity this 'meta-project' term you're using is in
fact having a svn folder with svn:externals links with just a pom.xml
in it to trigger a top level build of everything.

The only difference here is in calling it 'trunk' instead of 'trunks'?

> Also the problem is that apacheds is the main project,

Well we don't really have a main project anymore. I'd count all our
releasable projects as equal peer projects. This is why I started the

but the
> trunk-with-dependencies is also in apacheds, which is a bit troublesome for
> new comers.

Exactly! The idea is to remove this and have a single one. I don't care if it's:


I just wanted to inform y'all about it or agree upon it together and
set it up. I could just set it up and we can change it if need be.
Then we can all check out from here to have all the trunk projects in
scope. Another question might be why do we need to do this all of a

All our projects depend on shared in one way or another. Now studio
directly depends on shared bundles and may soon depend on apacheds
bundles solving a big problem with IDE based refactoring.

So when we refactor in shared or apacheds we should make sure the
updates propagate over to studio. This prevents studio from breaking
causing extra work for the studio guys having to manually change the
code to account for the shared or apacheds refactoring.

This is why we should have studio and apacheds loaded into the IDE
while making shared changes. This is something we should all do as a
practice to make sure we don't cause trouble for each other.

>>> We should also require a branch log file in this branches folder to
>>> chronicle what we've creates and deleted over time an why. Subversion
>>> log will show this too so this may also be redundant but it's nice to
>>> just see this info via http without having to run svn log or sift
>>> through changes. WDYT?
>>> Well, I'd rather depend on svn logs. They will be up to date, all the
>>> time :)
>> This was something done before to know what was deleted. It helps a
>> bit as an index in case you want to get back something u delete but
>> cannot remember the name.

Please read the above again. This is just on a delete not on each commit.

> Yeah, but it's never updated, unless someone does a check on all the
> commits, a painful task :/

The idea is svn log, logs everything. It might be nice not to see a
lot of log messages and save some bandwidth by just listing your
deleted branch when done with it into this file.

This file just shows which branches existed at some point in time and
why, along with which commit they were deleted. This just makes it
really easy to resuscitate a branch if you need it again, or need to
browse it using viewcvs.

It's not necessary since you can search through all the svn logs but
it makes life easier. Just seeing the list of old deleted branches
often triggers some thoughts.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message