You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2012/02/12 17:23:52 UTC
svnpubsub as an initiative
There are many Apache projects using Maven for some or all of their
websites, and I think it would be a good public service to smooth
their path to the requirement to use svnpubsub.
After a bit of discussion on the infra list, I can now describe one
scheme and I'd like to see what we can do to support it.
First, assume that the user is going to have svn 1.7 as a client.
We're aiming at our fellow Apache developers; if infra recommends 1.7,
we can in conscience aim at that.
So, the drill is as follows:
1) svn co a tree from svn used to publish the site.
2) remove all the local files, leaving the metadata.
3) run the site plugin aiming at this location.
4) svn remove all files in the metadata now absent from the tree, add
all new files.
5) Pause, optionally, for review.
6) commit.
I was thinking that this could be expressed as a plugin with a couple
of goals to add to the site lifecycle, combined with the plain old
ordinary local file wagon. I wonder if the scm provider API is strong
enough to handle step 4, or whether this has to be coded from scratch,
or whether it's reasonable to imagine extending the scm provider API
to go here.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Arnaud Héritier <ah...@gmail.com>.
if it is an asf dedicated plugin yes.
I see no real usage/interest for our community to include that in the
existing site plugin or something like that.
Even if I agree that our current site plugin doesn't offer something to
manage versions and it is annoying to manage documentations the solution
adopted by our infra is from my point of view proprietary.
My 2 cents
On Sun, Feb 12, 2012 at 8:31 PM, Simone Tripodi <si...@apache.org>wrote:
> I think that a plugin that does all that work, would definitively help!!!!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Feb 12, 2012 at 5:23 PM, Benson Margulies <bi...@gmail.com>
> wrote:
> > There are many Apache projects using Maven for some or all of their
> > websites, and I think it would be a good public service to smooth
> > their path to the requirement to use svnpubsub.
> >
> > After a bit of discussion on the infra list, I can now describe one
> > scheme and I'd like to see what we can do to support it.
> >
> > First, assume that the user is going to have svn 1.7 as a client.
> > We're aiming at our fellow Apache developers; if infra recommends 1.7,
> > we can in conscience aim at that.
> >
> > So, the drill is as follows:
> >
> > 1) svn co a tree from svn used to publish the site.
> >
> > 2) remove all the local files, leaving the metadata.
> >
> > 3) run the site plugin aiming at this location.
> >
> > 4) svn remove all files in the metadata now absent from the tree, add
> > all new files.
> >
> > 5) Pause, optionally, for review.
> >
> > 6) commit.
> >
> > I was thinking that this could be expressed as a plugin with a couple
> > of goals to add to the site lifecycle, combined with the plain old
> > ordinary local file wagon. I wonder if the scm provider API is strong
> > enough to handle step 4, or whether this has to be coded from scratch,
> > or whether it's reasonable to imagine extending the scm provider API
> > to go here.
> >
> > Thoughts?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
-----
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aheritier@gmail.com
Twitter/Skype : aheritier
Re: svnpubsub as an initiative
Posted by Simone Tripodi <si...@apache.org>.
I think that a plugin that does all that work, would definitively help!!!!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Feb 12, 2012 at 5:23 PM, Benson Margulies <bi...@gmail.com> wrote:
> There are many Apache projects using Maven for some or all of their
> websites, and I think it would be a good public service to smooth
> their path to the requirement to use svnpubsub.
>
> After a bit of discussion on the infra list, I can now describe one
> scheme and I'd like to see what we can do to support it.
>
> First, assume that the user is going to have svn 1.7 as a client.
> We're aiming at our fellow Apache developers; if infra recommends 1.7,
> we can in conscience aim at that.
>
> So, the drill is as follows:
>
> 1) svn co a tree from svn used to publish the site.
>
> 2) remove all the local files, leaving the metadata.
>
> 3) run the site plugin aiming at this location.
>
> 4) svn remove all files in the metadata now absent from the tree, add
> all new files.
>
> 5) Pause, optionally, for review.
>
> 6) commit.
>
> I was thinking that this could be expressed as a plugin with a couple
> of goals to add to the site lifecycle, combined with the plain old
> ordinary local file wagon. I wonder if the scm provider API is strong
> enough to handle step 4, or whether this has to be coded from scratch,
> or whether it's reasonable to imagine extending the scm provider API
> to go here.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Feb 13, 2012 at 12:54 PM, Kristian Rosenvold <
kristian.rosenvold@zenior.no> wrote:
> Does that mean we can't bitch about it?
>
> K ;)
>
In my experience, bitching at infra never ends well.
>
> Den 13. feb. 2012 kl. 18:37 skrev Benson Margulies <bimargulies@gmail.com
> >:
>
> > Folks,
> >
> > I anticipate that it will take me another two hours (spread over some
> days)
> > to make an adequate solution for this as a plugin. svnpubsub is what it
> is,
> > it's not going to go away, and I don't see why we need to pick a larger
> > fight with infra@ when this scheme of mine may work just fine for us and
> > all the other TLPs that use maven to make their sites.
> >
> > --benson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: svnpubsub as an initiative
Posted by Kristian Rosenvold <kr...@zenior.no>.
Does that mean we can't bitch about it?
K ;)
Den 13. feb. 2012 kl. 18:37 skrev Benson Margulies <bi...@gmail.com>:
> Folks,
>
> I anticipate that it will take me another two hours (spread over some days)
> to make an adequate solution for this as a plugin. svnpubsub is what it is,
> it's not going to go away, and I don't see why we need to pick a larger
> fight with infra@ when this scheme of mine may work just fine for us and
> all the other TLPs that use maven to make their sites.
>
> --benson
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Benson Margulies <bi...@gmail.com>.
Folks,
I anticipate that it will take me another two hours (spread over some days)
to make an adequate solution for this as a plugin. svnpubsub is what it is,
it's not going to go away, and I don't see why we need to pick a larger
fight with infra@ when this scheme of mine may work just fine for us and
all the other TLPs that use maven to make their sites.
--benson
Re: svnpubsub as an initiative
Posted by Stephen Connolly <st...@gmail.com>.
Well keep in mind that all I have written is a scp-jail, it supports
the "bare" minimum to handle scp upload, i.e.
mkdir -p
scp -t
cd xyz
unzip -q -o abc.zip
rm -f abc.zip
chmod <-- actually cheat for this one and do a no-op ;-)
all within an Apache Mina SshFileSystem impl that keeps you within a
specific directory.
for the svnpubsub, we'd need the servlet to checkout the site, apply
the commands and then push back the commit. There is also the issue of
how we pass through authentication... for codehaus it is easy as we
are operating on the raw filesystem, and we just auth via LDAP... but
in any case there is a chance that what I have can help
On 13 February 2012 15:16, Kristian Rosenvold
<kr...@gmail.com> wrote:
> Well assuming you're manually building your site by hand *and*
> you are one of the 12 remaining people in the known universe
> that know how svn branches work, I'm sure an svn based
> content management system is an excellent way to manually
> prepare your next site release.
>
> The limitations of WebDAV are unfortunate, I was not aware of
> these. Let's hope Stephen's solution fares better.
>
> Judging by the instructions for using svnsubpub it just
> seems like a step backward, and it does not seem to
> be designed for automation. But I suppose I consider
> moving from anything "standard" unix-like to svn
> a huge step in the wrong direction.
>
> Kristian
>
>
>
> 2012/2/13 Stephen Connolly <st...@gmail.com>:
>> Well we'll see how Ben gets on deploying my scp jail site deployer
>> servlet container on codehaus.
>>
>> If that goes well we could look at asking Infra about hosting a
>> similar app on ASF infra
>>
>> -Stephen
>>
>> On 13 February 2012 12:57, Benson Margulies <bi...@gmail.com> wrote:
>>> Infra@ is not friendly to the dav approach, so I'm not going there.
>>>
>>> On Mon, Feb 13, 2012 at 4:19 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On 13 February 2012 07:05, Kristian Rosenvold
>>>> <kr...@gmail.com> wrote:
>>>> > DAV has support for "lock" concept, which I somehow would
>>>> > assume a decent server-side implementation would map to a transaction?
>>>> > (I would rather improve dav_svn to make sure we can get 1 commit ;)
>>>>
>>>> I would have concern getting transaction time-outs... dav_svn is going
>>>> to be over http/https and given the "fun" deploying the mojo sites at
>>>> codehaus over webdav... [I am working with Ben on a SCP container that
>>>> can provide the fast site deploy we currently have @Apache to
>>>> Codehaus... I wonder if infra would be open to allowing that container
>>>> to run on apache hardware to allow effectively the same thing?]
>>>>
>>>> >
>>>> > Removed files should be quite simple; the server side file store is
>>>> enumerable
>>>> > and it would seem like a nice addition to the site plugin
>>>> > ("mirrorImage" or similar)
>>>> > I would really prefer adding features that has value to everyone
>>>> >
>>>> > As for a lower efficiency I'm sure that's real but do we really care ?
>>>> > (I'm assuming
>>>> > we can get 1 svn transaction and the overhead would be DAV ping-pong and
>>>> > maybe content comparison)
>>>> >
>>>> > Kristian
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Kristian Rosenvold <kr...@gmail.com>.
Well assuming you're manually building your site by hand *and*
you are one of the 12 remaining people in the known universe
that know how svn branches work, I'm sure an svn based
content management system is an excellent way to manually
prepare your next site release.
The limitations of WebDAV are unfortunate, I was not aware of
these. Let's hope Stephen's solution fares better.
Judging by the instructions for using svnsubpub it just
seems like a step backward, and it does not seem to
be designed for automation. But I suppose I consider
moving from anything "standard" unix-like to svn
a huge step in the wrong direction.
Kristian
2012/2/13 Stephen Connolly <st...@gmail.com>:
> Well we'll see how Ben gets on deploying my scp jail site deployer
> servlet container on codehaus.
>
> If that goes well we could look at asking Infra about hosting a
> similar app on ASF infra
>
> -Stephen
>
> On 13 February 2012 12:57, Benson Margulies <bi...@gmail.com> wrote:
>> Infra@ is not friendly to the dav approach, so I'm not going there.
>>
>> On Mon, Feb 13, 2012 at 4:19 AM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> On 13 February 2012 07:05, Kristian Rosenvold
>>> <kr...@gmail.com> wrote:
>>> > DAV has support for "lock" concept, which I somehow would
>>> > assume a decent server-side implementation would map to a transaction?
>>> > (I would rather improve dav_svn to make sure we can get 1 commit ;)
>>>
>>> I would have concern getting transaction time-outs... dav_svn is going
>>> to be over http/https and given the "fun" deploying the mojo sites at
>>> codehaus over webdav... [I am working with Ben on a SCP container that
>>> can provide the fast site deploy we currently have @Apache to
>>> Codehaus... I wonder if infra would be open to allowing that container
>>> to run on apache hardware to allow effectively the same thing?]
>>>
>>> >
>>> > Removed files should be quite simple; the server side file store is
>>> enumerable
>>> > and it would seem like a nice addition to the site plugin
>>> > ("mirrorImage" or similar)
>>> > I would really prefer adding features that has value to everyone
>>> >
>>> > As for a lower efficiency I'm sure that's real but do we really care ?
>>> > (I'm assuming
>>> > we can get 1 svn transaction and the overhead would be DAV ping-pong and
>>> > maybe content comparison)
>>> >
>>> > Kristian
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Stephen Connolly <st...@gmail.com>.
Well we'll see how Ben gets on deploying my scp jail site deployer
servlet container on codehaus.
If that goes well we could look at asking Infra about hosting a
similar app on ASF infra
-Stephen
On 13 February 2012 12:57, Benson Margulies <bi...@gmail.com> wrote:
> Infra@ is not friendly to the dav approach, so I'm not going there.
>
> On Mon, Feb 13, 2012 at 4:19 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> On 13 February 2012 07:05, Kristian Rosenvold
>> <kr...@gmail.com> wrote:
>> > DAV has support for "lock" concept, which I somehow would
>> > assume a decent server-side implementation would map to a transaction?
>> > (I would rather improve dav_svn to make sure we can get 1 commit ;)
>>
>> I would have concern getting transaction time-outs... dav_svn is going
>> to be over http/https and given the "fun" deploying the mojo sites at
>> codehaus over webdav... [I am working with Ben on a SCP container that
>> can provide the fast site deploy we currently have @Apache to
>> Codehaus... I wonder if infra would be open to allowing that container
>> to run on apache hardware to allow effectively the same thing?]
>>
>> >
>> > Removed files should be quite simple; the server side file store is
>> enumerable
>> > and it would seem like a nice addition to the site plugin
>> > ("mirrorImage" or similar)
>> > I would really prefer adding features that has value to everyone
>> >
>> > As for a lower efficiency I'm sure that's real but do we really care ?
>> > (I'm assuming
>> > we can get 1 svn transaction and the overhead would be DAV ping-pong and
>> > maybe content comparison)
>> >
>> > Kristian
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Benson Margulies <bi...@gmail.com>.
Infra@ is not friendly to the dav approach, so I'm not going there.
On Mon, Feb 13, 2012 at 4:19 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On 13 February 2012 07:05, Kristian Rosenvold
> <kr...@gmail.com> wrote:
> > DAV has support for "lock" concept, which I somehow would
> > assume a decent server-side implementation would map to a transaction?
> > (I would rather improve dav_svn to make sure we can get 1 commit ;)
>
> I would have concern getting transaction time-outs... dav_svn is going
> to be over http/https and given the "fun" deploying the mojo sites at
> codehaus over webdav... [I am working with Ben on a SCP container that
> can provide the fast site deploy we currently have @Apache to
> Codehaus... I wonder if infra would be open to allowing that container
> to run on apache hardware to allow effectively the same thing?]
>
> >
> > Removed files should be quite simple; the server side file store is
> enumerable
> > and it would seem like a nice addition to the site plugin
> > ("mirrorImage" or similar)
> > I would really prefer adding features that has value to everyone
> >
> > As for a lower efficiency I'm sure that's real but do we really care ?
> > (I'm assuming
> > we can get 1 svn transaction and the overhead would be DAV ping-pong and
> > maybe content comparison)
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: svnpubsub as an initiative
Posted by Stephen Connolly <st...@gmail.com>.
On 13 February 2012 07:05, Kristian Rosenvold
<kr...@gmail.com> wrote:
> DAV has support for "lock" concept, which I somehow would
> assume a decent server-side implementation would map to a transaction?
> (I would rather improve dav_svn to make sure we can get 1 commit ;)
I would have concern getting transaction time-outs... dav_svn is going
to be over http/https and given the "fun" deploying the mojo sites at
codehaus over webdav... [I am working with Ben on a SCP container that
can provide the fast site deploy we currently have @Apache to
Codehaus... I wonder if infra would be open to allowing that container
to run on apache hardware to allow effectively the same thing?]
>
> Removed files should be quite simple; the server side file store is enumerable
> and it would seem like a nice addition to the site plugin
> ("mirrorImage" or similar)
> I would really prefer adding features that has value to everyone
>
> As for a lower efficiency I'm sure that's real but do we really care ?
> (I'm assuming
> we can get 1 svn transaction and the overhead would be DAV ping-pong and
> maybe content comparison)
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Kristian Rosenvold <kr...@gmail.com>.
DAV has support for "lock" concept, which I somehow would
assume a decent server-side implementation would map to a transaction?
(I would rather improve dav_svn to make sure we can get 1 commit ;)
Removed files should be quite simple; the server side file store is enumerable
and it would seem like a nice addition to the site plugin
("mirrorImage" or similar)
I would really prefer adding features that has value to everyone
As for a lower efficiency I'm sure that's real but do we really care ?
(I'm assuming
we can get 1 svn transaction and the overhead would be DAV ping-pong and
maybe content comparison)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Brett Porter <br...@apache.org>.
On 13/02/2012, at 9:11 AM, Benson Margulies wrote:
> I did minimal reading on mod_dav_svn, and posted a message to
> infrastructure@ to ask what they think of it.
>
> I think we'd still need an extra maven plugin to organize deletions of
> no-longer-valid files.
There's a couple of other issues there:
- mod_dav_svn is going to log a revision for every file, rather than each deployment, which might be suboptimal
- I'm not sure it will be able to detect which files have changed and which haven't - so you might end up uploading more than desired. This would apply to any generic DAV server, since we're going to be comparing content, not timestamps.
Your general plan, whether it ends up as part of site-deploy, wagon, or a standalone plugin, sounds reasonable. I'm not sure you can rely on svn 1.7 - there's still problems with IDE integration that means some folks won't want to upgrade or fiddle with parallel installs. However, I'm pretty sure the maven-scm libraries can help you do what you want with small enhancements.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Benson Margulies <bi...@gmail.com>.
I did minimal reading on mod_dav_svn, and posted a message to
infrastructure@ to ask what they think of it.
I think we'd still need an extra maven plugin to organize deletions of
no-longer-valid files.
I'll start sketching something into the sandbox soon in the form of a pair
of goals: one to run at the start and one to run at the end. What exactly
happens is different if we're expecting to talk to dav as opposed to using
the scm provider.
Hervé or another site expert: can you think of a way for the first
execution to pass the pathname of the site plugin of the place to deploy
to, assuming for the moment the non-site trick? Obviously, it can just be
done explicitly in the POM to start with.
If site-folks think that deletion management (on the assumption of a wagon
API for the purpose) should be a core site plugin feature, I could be
easily roped into working on where to put it in there.
--benson
On Sun, Feb 12, 2012 at 4:58 PM, Benson Margulies <bi...@gmail.com>wrote:
> On Sun, Feb 12, 2012 at 4:50 PM, Hervé BOUTEMY <he...@free.fr>
> wrote:
> > if this would work well for any project (even with modules), I see more
> > problems with maven site itself [1]: checking out the site will check out
> > every module ever done into Maven.
> > We'll need to find some way to limit the content checked out, IMHO
>
> Yes.
>
> >
> > Regards,
> >
> > Hervé
> >
> >
> > [1] http://svn.apache.org/repos/asf/maven/site/trunk/
> >
> > Le dimanche 12 février 2012 11:23:52 Benson Margulies a écrit :
> >> There are many Apache projects using Maven for some or all of their
> >> websites, and I think it would be a good public service to smooth
> >> their path to the requirement to use svnpubsub.
> >>
> >> After a bit of discussion on the infra list, I can now describe one
> >> scheme and I'd like to see what we can do to support it.
> >>
> >> First, assume that the user is going to have svn 1.7 as a client.
> >> We're aiming at our fellow Apache developers; if infra recommends 1.7,
> >> we can in conscience aim at that.
> >>
> >> So, the drill is as follows:
> >>
> >> 1) svn co a tree from svn used to publish the site.
> >>
> >> 2) remove all the local files, leaving the metadata.
> >>
> >> 3) run the site plugin aiming at this location.
> >>
> >> 4) svn remove all files in the metadata now absent from the tree, add
> >> all new files.
> >>
> >> 5) Pause, optionally, for review.
> >>
> >> 6) commit.
> >>
> >> I was thinking that this could be expressed as a plugin with a couple
> >> of goals to add to the site lifecycle, combined with the plain old
> >> ordinary local file wagon. I wonder if the scm provider API is strong
> >> enough to handle step 4, or whether this has to be coded from scratch,
> >> or whether it's reasonable to imagine extending the scm provider API
> >> to go here.
> >>
> >> Thoughts?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
Re: svnpubsub as an initiative
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Feb 12, 2012 at 4:50 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> if this would work well for any project (even with modules), I see more
> problems with maven site itself [1]: checking out the site will check out
> every module ever done into Maven.
> We'll need to find some way to limit the content checked out, IMHO
Yes.
>
> Regards,
>
> Hervé
>
>
> [1] http://svn.apache.org/repos/asf/maven/site/trunk/
>
> Le dimanche 12 février 2012 11:23:52 Benson Margulies a écrit :
>> There are many Apache projects using Maven for some or all of their
>> websites, and I think it would be a good public service to smooth
>> their path to the requirement to use svnpubsub.
>>
>> After a bit of discussion on the infra list, I can now describe one
>> scheme and I'd like to see what we can do to support it.
>>
>> First, assume that the user is going to have svn 1.7 as a client.
>> We're aiming at our fellow Apache developers; if infra recommends 1.7,
>> we can in conscience aim at that.
>>
>> So, the drill is as follows:
>>
>> 1) svn co a tree from svn used to publish the site.
>>
>> 2) remove all the local files, leaving the metadata.
>>
>> 3) run the site plugin aiming at this location.
>>
>> 4) svn remove all files in the metadata now absent from the tree, add
>> all new files.
>>
>> 5) Pause, optionally, for review.
>>
>> 6) commit.
>>
>> I was thinking that this could be expressed as a plugin with a couple
>> of goals to add to the site lifecycle, combined with the plain old
>> ordinary local file wagon. I wonder if the scm provider API is strong
>> enough to handle step 4, or whether this has to be coded from scratch,
>> or whether it's reasonable to imagine extending the scm provider API
>> to go here.
>>
>> Thoughts?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Hervé BOUTEMY <he...@free.fr>.
if this would work well for any project (even with modules), I see more
problems with maven site itself [1]: checking out the site will check out
every module ever done into Maven.
We'll need to find some way to limit the content checked out, IMHO
Regards,
Hervé
[1] http://svn.apache.org/repos/asf/maven/site/trunk/
Le dimanche 12 février 2012 11:23:52 Benson Margulies a écrit :
> There are many Apache projects using Maven for some or all of their
> websites, and I think it would be a good public service to smooth
> their path to the requirement to use svnpubsub.
>
> After a bit of discussion on the infra list, I can now describe one
> scheme and I'd like to see what we can do to support it.
>
> First, assume that the user is going to have svn 1.7 as a client.
> We're aiming at our fellow Apache developers; if infra recommends 1.7,
> we can in conscience aim at that.
>
> So, the drill is as follows:
>
> 1) svn co a tree from svn used to publish the site.
>
> 2) remove all the local files, leaving the metadata.
>
> 3) run the site plugin aiming at this location.
>
> 4) svn remove all files in the metadata now absent from the tree, add
> all new files.
>
> 5) Pause, optionally, for review.
>
> 6) commit.
>
> I was thinking that this could be expressed as a plugin with a couple
> of goals to add to the site lifecycle, combined with the plain old
> ordinary local file wagon. I wonder if the scm provider API is strong
> enough to handle step 4, or whether this has to be coded from scratch,
> or whether it's reasonable to imagine extending the scm provider API
> to go here.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Hervé BOUTEMY <he...@free.fr>.
nice idea
I just Gooled a little bit and found mod_dav_svn [1]: does anybody know it?
Regards,
Hervé
[1] http://oreilly.com/opensource/excerpts/9780596510336/webdav-and-
autoversioning.html
Le dimanche 12 février 2012 15:59:38 Benson Margulies a écrit :
> On Sun, Feb 12, 2012 at 3:10 PM, Kristian Rosenvold
>
> <kr...@gmail.com> wrote:
> > /me cannot help to wonder what is wrong with a WebDAV front end
> > backed by "any" version control system we wouldn't have to care about.
>
> Kristian,
>
> My first reaction is that you've just proposed to replace my idea for
> a fairly small project with a much, much, larger one. Unless, of
> course, you know of an existing DAV service that fronts svn. Further,
> I don't know where the deletes would come from.
>
> However, I'm fairly comprehensively ignorant in this area, so please
> feel free to educate me as needed.
>
> Others,
>
> The ASF svnpubsub technology is a local beast, so indeed I make no
> strong claims that the scheme I described would be any use for anyone
> else. I don't see any reason to make changes to the site plugin unless
> we collectively have some scheme related to Kristian's idea: somehow
> teach the site plugin to interact with DAV to enumerate the existing
> content of a target, and issue delete commands for files no longer
> produced?
>
> --benson
>
> > Kristian
> >
> > 2012/2/12 Dawid Weiss <da...@gmail.com>:
> >>> 4) svn remove all files in the metadata now absent from the tree,
> >>> add
> >>> all new files.
> >>
> >> Ah... this would be so easy with git --
> >>
> >> git add -A .
> >>
> >> Dawid
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Feb 12, 2012 at 3:10 PM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> /me cannot help to wonder what is wrong with a WebDAV front end
> backed by "any" version control system we wouldn't have to care about.
Kristian,
My first reaction is that you've just proposed to replace my idea for
a fairly small project with a much, much, larger one. Unless, of
course, you know of an existing DAV service that fronts svn. Further,
I don't know where the deletes would come from.
However, I'm fairly comprehensively ignorant in this area, so please
feel free to educate me as needed.
Others,
The ASF svnpubsub technology is a local beast, so indeed I make no
strong claims that the scheme I described would be any use for anyone
else. I don't see any reason to make changes to the site plugin unless
we collectively have some scheme related to Kristian's idea: somehow
teach the site plugin to interact with DAV to enumerate the existing
content of a target, and issue delete commands for files no longer
produced?
--benson
>
> Kristian
>
>
> 2012/2/12 Dawid Weiss <da...@gmail.com>:
>>> 4) svn remove all files in the metadata now absent from the tree, add
>>> all new files.
>>
>> Ah... this would be so easy with git --
>>
>> git add -A .
>>
>> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Kristian Rosenvold <kr...@gmail.com>.
/me cannot help to wonder what is wrong with a WebDAV front end
backed by "any" version control system we wouldn't have to care about.
Kristian
2012/2/12 Dawid Weiss <da...@gmail.com>:
>> 4) svn remove all files in the metadata now absent from the tree, add
>> all new files.
>
> Ah... this would be so easy with git --
>
> git add -A .
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svnpubsub as an initiative
Posted by Dawid Weiss <da...@gmail.com>.
> 4) svn remove all files in the metadata now absent from the tree, add
> all new files.
Ah... this would be so easy with git --
git add -A .
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org