You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/11/19 15:47:41 UTC
svn and Apache-Test
hi guys...
I know that when we left apachecon there were still some issues with mp2 and
A-T. did these ever resolve or do we still need to figure things out?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: svn and Apache-Test
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> +1 for #2:
>
>
> Coolio, I'll make it so later unless anybody else strongly objects or sth.
yeah, that's fine with me too.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: svn and Apache-Test
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>> Geoffrey Young wrote:
>>
>>> hi guys...
>>>
>>> I know that when we left apachecon there were still some issues with
>>> mp2 and
>>> A-T. did these ever resolve or do we still need to figure things out?
>>
>> [...]
>>
>> Possibility #1: Use http:// urls
>> Problems is for developers like us that want a read-write docs/ and
>> Apache-Test/ directories we can
>> change and checkin from, right ? (if that's not the case, this
>> solution works)
>
> svn is primerily needed for developers and that should be the first
> priority.
Also the way I felt.
>> Possibility #2: Use https://urls
>> Problem is only that for read-only users, the added slowdown with
>> using SSL is wasted on them, since
>> http would work just fine for them.
>
> Go with #2, who cares about a little overhead, most people aren't
> checking out the source via cvs/svn anyway.
I guess the only people who could raise an objection to this would be
infrastructure folks, but unless we suddently
have 100s users all downloading mp-svn all at once, shouldn't be a problem.
>> After thinking about these quite a lot, I talked with a guy from SVN
>> and he effictively told me: "externals
>> are broken and you should _not_ use them for this"
>
> Heh, so much for rushing to move to svn :( What does he mean "broken",
> when I've asked last time on infrastructure, I was told that it
> "externals" works just fine. If it's broken it should be fixed asap,
> since the move to svn was approved after the promise was made that
> things will just work.
Not to worry. I guess I paraphrased him a bit too simply. It's working
fine, he just didn't like the way it was implemented and how
it was the source of little problems like the one we were facing. It's
just a feature he thinks will need to be changed/improved in the
future. So, in a nutshell, it's not 'broken' ;-)
>> So, here comes Possibility #3:
>>
>> Don't use svn:externals and use svn switch. That allows grafting
>> pieces of one repos into other parts of the
>> same repos. Yay! Only drawback is that now checkout can't just be
>> automatic, there needs to be a small client-side
>> script (util/svn.pl for me now) that needs to be run once after
>> checking out mp2 to issue the right svn switch commands.
>> Once that is done, ro/rw for developers/users works just fine. svn
>> ci/diff/up also proprely propagete down these switched
>> repositories.
>
> Please don't. This makes things complicated and invited unnecessary
> questions/problem reports for us to deal with. The snapshotting
> mechanism will be broken as well.
Snapshots in http://svn.apache.org/snapshots/ are still coming off CVS
and it's on infra's plate to get new scripts in place
to take care of snapshotting from SVN. (for instance, i'd expect
repository $revision to be in the filename, like
modperl-2.0-22293332.tgz) instead of the date.
>> I personally would be more or less with solution #1 or #3.
>>
>> Thoughts? In any case, I've got it all done on my side, so whatever
>> we pick, I can just make it so in 2 flick of the mouse.
>
> +1 for #2:
Coolio, I'll make it so later unless anybody else strongly objects or sth.
Gozer .
Re: svn and Apache-Test
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> Geoffrey Young wrote:
>
>> hi guys...
>>
>> I know that when we left apachecon there were still some issues with
>> mp2 and
>> A-T. did these ever resolve or do we still need to figure things out?
>>
>>
> Yes, these had to do with the difference in how you can link
> repositories together. Take modperl-2.0
> and cvs, with the CVSROOT/modules files, causing Apache-Test and parts
> of mp-docs to be
> checked out automatically when you checkout modperl-2.0.
>
> Now in SVN, there are 2 ways to do that, the first one is using a cool
> svn:externals proprety. That
> would almost work for us with one exception. Since it requires that you
> put fully-qualified URLs
> in the external definitions, you'd have to stick to either http/https
> access to the repository.
>
> Possibility #1: Use http:// urls
> Problems is for developers like us that want a read-write docs/ and
> Apache-Test/ directories we can
> change and checkin from, right ? (if that's not the case, this solution
> works)
svn is primerily needed for developers and that should be the first priority.
> Possibility #2: Use https://urls
> Problem is only that for read-only users, the added slowdown with using
> SSL is wasted on them, since
> http would work just fine for them.
Go with #2, who cares about a little overhead, most people aren't checking
out the source via cvs/svn anyway.
> After thinking about these quite a lot, I talked with a guy from SVN and
> he effictively told me: "externals
> are broken and you should _not_ use them for this"
Heh, so much for rushing to move to svn :( What does he mean "broken",
when I've asked last time on infrastructure, I was told that it
"externals" works just fine. If it's broken it should be fixed asap, since
the move to svn was approved after the promise was made that things will
just work.
> So, here comes Possibility #3:
>
> Don't use svn:externals and use svn switch. That allows grafting pieces
> of one repos into other parts of the
> same repos. Yay! Only drawback is that now checkout can't just be
> automatic, there needs to be a small client-side
> script (util/svn.pl for me now) that needs to be run once after checking
> out mp2 to issue the right svn switch commands.
> Once that is done, ro/rw for developers/users works just fine. svn
> ci/diff/up also proprely propagete down these switched
> repositories.
Please don't. This makes things complicated and invited unnecessary
questions/problem reports for us to deal with. The snapshotting mechanism
will be broken as well.
> I personally would be more or less with solution #1 or #3.
>
> Thoughts? In any case, I've got it all done on my side, so whatever we
> pick, I can just make it so in 2 flick of the mouse.
+1 for #2:
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: svn and Apache-Test
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Geoffrey Young wrote:
>hi guys...
>
>I know that when we left apachecon there were still some issues with mp2 and
>A-T. did these ever resolve or do we still need to figure things out?
>
>
Yes, these had to do with the difference in how you can link
repositories together. Take modperl-2.0
and cvs, with the CVSROOT/modules files, causing Apache-Test and parts
of mp-docs to be
checked out automatically when you checkout modperl-2.0.
Now in SVN, there are 2 ways to do that, the first one is using a cool
svn:externals proprety. That
would almost work for us with one exception. Since it requires that you
put fully-qualified URLs
in the external definitions, you'd have to stick to either http/https
access to the repository.
Possibility #1: Use http:// urls
Problems is for developers like us that want a read-write docs/ and
Apache-Test/ directories we can
change and checkin from, right ? (if that's not the case, this
solution works)
Possibility #2: Use https://urls
Problem is only that for read-only users, the added slowdown with
using SSL is wasted on them, since
http would work just fine for them.
After thinking about these quite a lot, I talked with a guy from SVN and
he effictively told me: "externals
are broken and you should _not_ use them for this"
So, here comes Possibility #3:
Don't use svn:externals and use svn switch. That allows grafting
pieces of one repos into other parts of the
same repos. Yay! Only drawback is that now checkout can't just be
automatic, there needs to be a small client-side
script (util/svn.pl for me now) that needs to be run once after checking
out mp2 to issue the right svn switch commands.
Once that is done, ro/rw for developers/users works just fine. svn
ci/diff/up also proprely propagete down these switched
repositories.
I personally would be more or less with solution #1 or #3.
Thoughts? In any case, I've got it all done on my side, so whatever we
pick, I can just make it so in 2 flick of the mouse.
Gozer out.
>--Geoff
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>
>
>