SVN reorg

[Maât]

Hi,

We spoke earlier about svn reorganization so that we can have a working
phpgroupware with a single checkout and trunk/tags/branches for each module.

Can we consider doing this reorganization before .18 branching ?

(I think that would also make branching and release easier.)

regards,
Maât

[Olivier Berger]

Hi Pascal.

Post by Maât
Hi,
We spoke earlier about svn reorganization so that we can have a working
phpgroupware with a single checkout and trunk/tags/branches for each module.
Can we consider doing this reorganization before .18 branching ?

You seem to mean that there are plans for .18... what are they ?

Post by Maât
(I think that would also make branching and release easier.)

Is this some issue which delays .18 at the moment ?

No opinion here on the svn reorg anyway... but really interested in the
roadmap ;)

Best regards,

[Maât]

Post by Olivier Berger
Hi Pascal.

Post by Maât
Hi,
We spoke earlier about svn reorganization so that we can have a working
phpgroupware with a single checkout and trunk/tags/branches for each module.
Can we consider doing this reorganization before .18 branching ?

You seem to mean that there are plans for .18... what are they ?

Well i just rely on what have been said on this very list and on IRC
chan history... .18 have been announced for early may then for the
summer ( though the year was not clearly defined... i may be wrong when
i understand 2008 ^^)

Post by Olivier Berger

Post by Maât
(I think that would also make branching and release easier.)

Is this some issue which delays .18 at the moment ?
No opinion here on the svn reorg anyway... but really interested in the
roadmap ;)
Best regards,

I'm not the roadmap guy but i offered to make things easier for
everybody (roadmap guys, coders, betatesters...)

no answer = go ?
no answer = do wtf you wan we dont care ?
no answer = don't move ?


I'd prefer a "no" answer or like Olivier did a "no opinion" than a great
white void


rgrds,

[Sigurd Nes]

Post by Maât
Hi,
We spoke earlier about svn reorganization so that we can have a working
phpgroupware with a single checkout and trunk/tags/branches for each module.
Can we consider doing this reorganization before .18 branching ?
(I think that would also make branching and release easier.)
regards,
Maât

It is fine by me.

Maybe we should try to summarize previous discussions on the subject into a
final scheme/layout before actually doing the change?

Regards

Sigurd

[Maât]

Post by Sigurd Nes

Post by Maât
Hi,
We spoke earlier about svn reorganization so that we can have a
working phpgroupware with a single checkout and trunk/tags/branches
for each module.
Can we consider doing this reorganization before .18 branching ?
(I think that would also make branching and release easier.)
regards,
Maât

It is fine by me.
Maybe we should try to summarize previous discussions on the subject
into a final scheme/layout before actually doing the change?
Regards
Sigurd

Of course.


the idea is :

1) to have a trunk/tag/branches tree for each application/module of
phpgroupware

2) to have a trunk/tags/branches tree for phpgroupware and to use
svn:externals on it so that a single checkout on
url://of/phpgroupware/trunk retrives automatically the dependancies (
setup, phpgwapi, home, admin...)

If one wants to add a specific (not retrieved by default) module he'll
just have to edit svn:externals and make a svn update

for branching and releases the source control manager will just have to
edit svn:externals in branch so that it targets modules tags instead of
branches or trunk then procceed to tag creation then change back to
target again branches for those who would like to betatest bleeding edge
for the given branch.

for phpgroupware trunk svn:externals would of course target trunks of
modules

phpgroupware dir would appear at the top of svn repository so that svn
checkout url is easy for everybody

modules and components would appear as subdirs of a top level dir called
for example "modules" or "applications" or "components" their specific
url would only be used by people managing modules versions and branches
and sometimes by modules coders

the result : for people wanting to use or test phpgw from svn :

for a release :
svn co http://svn.savannah.gnu.org/svn/phpgroupware/tags/release_0.18.001

for a branch :
svn co http://svn.savannah.gnu.org/svn/phpgroupware/branches/branch_0.18

for the trunk :
svn co http://svn.savannah.gnu.org/svn/phpgroupware/trunk

for people working on phpgw :

for a branch :
svn co svn://svn.savannah.gnu.org/svn/phpgroupware/branches/branch_0.18

for the trunk :
svn co svn://svn.savannah.gnu.org/svn/phpgroupware/trunk

regards,
Maât


Nota : we could also imagine "flavored" branches with differents sets of
modules declared ( to match the main users profiles... project
management, facility management, community communication....)

[Maât]

/ping list

Post by Maât
1) to have a trunk/tag/branches tree for each application/module of
phpgroupware
2) to have a trunk/tags/branches tree for phpgroupware and to use
svn:externals on it so that a single checkout on
url://of/phpgroupware/trunk retrives automatically the dependancies (
setup, phpgwapi, home, admin...)
If one wants to add a specific (not retrieved by default) module he'll
just have to edit svn:externals and make a svn update
for branching and releases the source control manager will just have
to edit svn:externals in branch so that it targets modules tags
instead of branches or trunk then procceed to tag creation then change
back to target again branches for those who would like to betatest
bleeding edge for the given branch.
for phpgroupware trunk svn:externals would of course target trunks of
modules
phpgroupware dir would appear at the top of svn repository so that svn
checkout url is easy for everybody
modules and components would appear as subdirs of a top level dir
called for example "modules" or "applications" or "components" their
specific url would only be used by people managing modules versions
and branches and sometimes by modules coders
svn co http://svn.savannah.gnu.org/svn/phpgroupware/tags/release_0.18.001
svn co http://svn.savannah.gnu.org/svn/phpgroupware/branches/branch_0.18
svn co http://svn.savannah.gnu.org/svn/phpgroupware/trunk
svn co svn://svn.savannah.gnu.org/svn/phpgroupware/branches/branch_0.18
svn co svn://svn.savannah.gnu.org/svn/phpgroupware/trunk
regards,
Maât
Nota : we could also imagine "flavored" branches with differents sets
of modules declared ( to match the main users profiles... project
management, facility management, community communication....)

[Bob Crandell]

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for list:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss).

Post by Maât
/ping list

Post by Maât
1) to have a trunk/tag/branches tree for each application/module of
phpgroupware
2) to have a trunk/tags/branches tree for phpgroupware and to use
svn:externals on it so that a single checkout on
url://of/phpgroupware/trunk retrives automatically the dependancies (
setup, phpgwapi, home, admin...)
If one wants to add a specific (not retrieved by default) module he'll
just have to edit svn:externals and make a svn update
for branching and releases the source control manager will just have
to edit svn:externals in branch so that it targets modules tags
instead of branches or trunk then procceed to tag creation then change
back to target again branches for those who would like to betatest
bleeding edge for the given branch.
for phpgroupware trunk svn:externals would of course target trunks of
modules
phpgroupware dir would appear at the top of svn repository so that svn
checkout url is easy for everybody
modules and components would appear as subdirs of a top level dir
called for example "modules" or "applications" or "components" their
specific url would only be used by people managing modules versions
and branches and sometimes by modules coders
svn co http://svn.savannah.gnu.org/svn/phpgroupware/tags/release_0.18.001
svn co http://svn.savannah.gnu.org/svn/phpgroupware/branches/branch_0.18
svn co http://svn.savannah.gnu.org/svn/phpgroupware/trunk
svn co svn://svn.savannah.gnu.org/svn/phpgroupware/branches/branch_0.18
svn co svn://svn.savannah.gnu.org/svn/phpgroupware/trunk
regards,
Maât
Nota : we could also imagine "flavored" branches with differents sets
of modules declared ( to match the main users profiles... project
management, facility management, community communication....)

_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

[Maât]

Post by Bob Crandell
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss).

OK then i'll proceed to this svn reorg in a few days :)

1] you'll be noticed of the start here by mail.

2] during the svn reorg phpgw coders should refrain from committing

3] you'll be noticed of the end here also by email.

4] after reorg every contributor will have to do a fresh checkout before
playing again with phpgw.


Note : i'll publish here and on the user list the new way to play with
sources.


grtx,
Maât