RE: Moving blocks
> -Original Message- > From: Reinhard Poetz [mailto:[EMAIL PROTECTED] > Sent: 18 February 2005 17:41 > To: dev@cocoon.apache.org > Subject: Re: Moving blocks > > Upayavira wrote: > > Reinhard Poetz wrote: > > > >> Could some people pls report back whether there have been any > >> problems on updates? (Escpecially be careful if you had changes in > >> one of the four moved blocks. In this case, sorry for any > >> inconveniences!) > > > > > > Have you tried checking out the external references via http rather > > than https? Just want to be sure that they'll still work for > > non-committers using http. > > Yes, > > svn checkout http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks > > worked for me. I guess that people not using https have to > accept the certificate once. That seems to be what just happened. TortoiseSVM deleted the blocks, and re-added them at the some location, but I had to accept the certificate. No major problem. Ben
Re: Moving blocks
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
I have not tested yet what happens with local changes after the block
is "mounted" using svn:external. Any experiences?
I've been using svn:external for including the documentation in the
simile.mit.edu web site (which is managed in SVN) importing the /docs
that come from the various projects (so no code) but I have no found a
problem yet with this approach.
good too hear
The only problem is that 'svn status' might not show you changed done in
the imported blocks, you have to 'cd' into the block directory and do
'svn status' there.
[but there might be a switch somewhere in turn that behavior off... that
havn't bugged me enough to be concerned about it]
The (possible) problem that I'm thinking of is if people haven't updated their
working copies yes and have some local changes. I don't know what's happening if
they do "svn update". I guess they have to manually save their changes, to "svn
update" and copy the changes back.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Moving blocks
Upayavira wrote:
Reinhard Poetz wrote:
This afternoon I've started to move some selected blocks:
- authentication-fw
- session-fw
- cron
- html
Cron and html are blocks don't require other blocks to build.
Authentication-fw depends on session-fw. This will give me the chance
to test my build system that will respect those relations. In my sense
all those blocks are well supported by the community but making a
decision whether they are supported, core or not was not my goal. We
can discuss this later in a separate thread.
As those blocks are not under heavy development I don't expect (too
many) problems. I have not tested yet what happens with local changes
after the block is "mounted" using svn:external. Any experiences? If
there are troubles we need some migration strategy (means code freeze).
Could some people pls report back whether there have been any problems
on updates? (Escpecially be careful if you had changes in one of the
four moved blocks. In this case, sorry for any inconveniences!)
Have you tried checking out the external references via http rather than
https? Just want to be sure that they'll still work for non-committers
using http.
Yes,
svn checkout http://svn.apache.org/repos/asf/cocoon/trunk/src/blocks
worked for me. I guess that people not using https have to accept the
certificate once.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Moving blocks
Reinhard Poetz wrote: I have not tested yet what happens with local changes after the block is "mounted" using svn:external. Any experiences? I've been using svn:external for including the documentation in the simile.mit.edu web site (which is managed in SVN) importing the /docs that come from the various projects (so no code) but I have no found a problem yet with this approach. The only problem is that 'svn status' might not show you changed done in the imported blocks, you have to 'cd' into the block directory and do 'svn status' there. [but there might be a switch somewhere in turn that behavior off... that havn't bugged me enough to be concerned about it] HTH -- Stefano.
Re: Moving blocks
Reinhard Poetz wrote: This afternoon I've started to move some selected blocks: - authentication-fw - session-fw - cron - html Cron and html are blocks don't require other blocks to build. Authentication-fw depends on session-fw. This will give me the chance to test my build system that will respect those relations. In my sense all those blocks are well supported by the community but making a decision whether they are supported, core or not was not my goal. We can discuss this later in a separate thread. As those blocks are not under heavy development I don't expect (too many) problems. I have not tested yet what happens with local changes after the block is "mounted" using svn:external. Any experiences? If there are troubles we need some migration strategy (means code freeze). Could some people pls report back whether there have been any problems on updates? (Escpecially be careful if you had changes in one of the four moved blocks. In this case, sorry for any inconveniences!) Have you tried checking out the external references via http rather than https? Just want to be sure that they'll still work for non-committers using http. Regards, Upayavira
Re: Moving blocks out of the core
Reinhard Poetz wrote: Ralph Goers wrote: Reinhard Poetz wrote: It would make me uneasy too if we did it now. But if the infrastructure (solid contracts between a block and core + an easy to use deployment tool) it should be the goal to have independant blocks with their own release cycles. But I thought the proposal is to move blocks now? Moving now, but use svn:external (http://svnbook.red-bean.com/en/1.0/ch07s03.html) to include them at the place where they are now. When the new build system is in place, we can _think_ about cutting this link. Independant release cycles of blocks are another story and need much more work. Maybe 2.3 will bring them. Thanks. You made me much more comfortable. :-) Ralph
Re: Moving blocks out of the core
Ralph Goers wrote:
Reinhard Poetz wrote:
It would make me uneasy too if we did it now. But if the
infrastructure (solid contracts between a block and core + an easy to
use deployment tool) it should be the goal to have independant blocks
with their own release cycles.
But I thought the proposal is to move blocks now?
Moving now, but use svn:external
(http://svnbook.red-bean.com/en/1.0/ch07s03.html) to include them at the place
where they are now.
When the new build system is in place, we can _think_ about cutting this link.
Independant release cycles of blocks are another story and need much more work.
Maybe 2.3 will bring them.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Moving blocks out of the core
Reinhard Poetz wrote: It would make me uneasy too if we did it now. But if the infrastructure (solid contracts between a block and core + an easy to use deployment tool) it should be the goal to have independant blocks with their own release cycles. But I thought the proposal is to move blocks now? Ralph
Re: Moving blocks out of the core
Ralph Goers wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
/cocoon/blocks/core/forms/branches/ .. empty for now
/cocoon/blocks/core/forms/tags/ .. empty for now
Oh wow. I guess I didn't get that. So the proposal IS to have every
block on its own release schedule.
I can't put my finger on why this makes me uneasy, but it does.
It would make me uneasy too if we did it now. But if the infrastructure (solid
contracts between a block and core + an easy to use deployment tool) it should
be the goal to have independant blocks with their own release cycles.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Moving blocks out of the core
Reinhard Poetz wrote: Carsten Ziegeler wrote: And then under core, supported, unsupported, come the different blocks with a trunk, tags, releases directory each, right? yes, e.g. /cocoon/blocks/core/forms/trunk/ . the current forms block /cocoon/blocks/core/forms/branches/ .. empty for now /cocoon/blocks/core/forms/tags/ .. empty for now Oh wow. I guess I didn't get that. So the proposal IS to have every block on its own release schedule. I can't put my finger on why this makes me uneasy, but it does. Ralph
Re: Moving blocks out of the core
This makes me a little uncomfortable. So blocks will now have a release schedule that is independent from core? I'm just wondering if that is a good thing or a bad thing at this time. And if that is so, why isn't each block on its own release? (That is just rhetorical, as I don't believe we are ready for that - but we will be when "real" blocks emerge.) Ralph Carsten Ziegeler wrote: It seems that we all agree more or less on moving the blocks out of the core, so which directory structure do we want to use in svn? We recently had this suggestion: /cocoon/trunk /cocoon/blocks/core/ /cocoon/blocks/supported/ /cocoon/blocks/unsupported/ And then under core, supported, unsupported, come the different blocks with a trunk, tags, releases directory each, right? I think the first step is easy, we could move the blocks to the new directory structure and then use svn:external to link the blocks into the core, so nothing really changes but we are one step further. Carsten
Re: Moving blocks out of the core
Carsten Ziegeler wrote: It seems that we all agree more or less on moving the blocks out of the core, so which directory structure do we want to use in svn? We recently had this suggestion: /cocoon/trunk /cocoon/blocks/core/ /cocoon/blocks/supported/ /cocoon/blocks/unsupported/ And then under core, supported, unsupported, come the different blocks with a trunk, tags, releases directory each, right? Yes I think the first step is easy, we could move the blocks to the new directory structure and then use svn:external to link the blocks into the core, so nothing really changes but we are one step further. +1 /Daniel
Re: Moving blocks out of the core
Would it be worth considering adding either 'legacy' or 'deprecated' to contain blocks that are going to disappear at some unspecified point in the future (or maybe s/unsupported/deprecated/)? I'm just suggesting that 'unsupported' may not be strongly worded enough for new users who start developing applications with certain blocks that are clearly dead-end streets. phil. Carsten Ziegeler wrote: It seems that we all agree more or less on moving the blocks out of the core, so which directory structure do we want to use in svn? We recently had this suggestion: /cocoon/trunk /cocoon/blocks/core/ /cocoon/blocks/supported/ /cocoon/blocks/unsupported/ And then under core, supported, unsupported, come the different blocks with a trunk, tags, releases directory each, right? I think the first step is easy, we could move the blocks to the new directory structure and then use svn:external to link the blocks into the core, so nothing really changes but we are one step further. Carsten -- Whirlycott Philip Jacob [EMAIL PROTECTED] http://www.whirlycott.com/phil/
Re: Moving blocks out of the core
Carsten Ziegeler wrote:
It seems that we all agree more or less on moving the blocks out of the
core, so which directory structure do we want to use in svn?
We recently had this suggestion:
/cocoon/trunk
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
And then under core, supported, unsupported, come the different blocks
with a trunk, tags, releases directory each, right?
yes, e.g.
/cocoon/blocks/core/forms/trunk/ . the current forms block
/cocoon/blocks/core/forms/branches/ .. empty for now
/cocoon/blocks/core/forms/tags/ .. empty for now
I think the first step is easy, we could move the blocks to the new
directory structure and then use svn:external to link the blocks into
the core, so nothing really changes but we are one step further.
an excellent idea. So my work on the build system won't break Cocoon and lowers
a bit the pressure to do everything at once.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
