You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/11/23 18:02:10 UTC
another svn problem (diff across svn:external
I see yet another problem with svn. modperl-2.0 uses svn:externals:
docs
https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/src/docs/2.0
Apache-Test
https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test
Now when I run 'svn diff' at the top level it won't show the diff for
those externals. Why? How this can be fixed? Thanks.
--
__________________________________________________________________
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: another svn problem (diff across svn:external
Posted by Stas Bekman <st...@stason.org>.
Garrett Rooney wrote:
> Stas Bekman wrote:
>
>> While it's sort of OK for us developers to figure it out, quite often
>> we ask users to get a fresh "cvs-r.i.p." checkout and we won't want to
>> make them jumping through hoops, there is enough pain they have to
>> endure.
>
>
> Well, you already need to run 'perl Makefile.PL' in order to build,
> right? Why not stick some code in there that looks for the Apache-Test
> stuff you need and if it isn't there (and you're in an svn working copy)
> do the switch?
Yeah, why not slap yet another workaround for 100 workarounds. It doesn't
seem like we really have another choice. And then someone needs to manage
those 10000 lines Makefile.PL and make sense of it.
>> So what's the forecast for svn:externals, is it planned to be fixed,
>> and how soon?
>
>
> I don't personally have any plans to fix it, and I don't know of any
> other Subversion developers who do in the immediate future. There are
> some plans as to how it could be made to work better, but at this point
> that's all it is, plans. As usual in open source projects something
> gets fixed when someone is motivated to fix it, and most of the
> developers do not seem to make heavy use of externals, thus they are
> devoting their time to other issues, like locking support and merge
> tracking.
that's clear. the short answer is: "no, it's not going to be fixed any
time soon".
>> What bothers me the most is that when we asked whether modperl will be
>> OK moved to svn, the answer was: "yes of course, everything is ready".
>> Now we discover lots of broken/missing things. And unfortunately I
>> find that the move to svn was really rushed and unjustifiable. In fact
>> I'd prefer to see things reverted to cvs at least until after we get
>> mp2.0 out, but that's too late in the game and we depend on
>> Apache-Test which is now under svn without a question.
>
>
> It seems that mod_perl2 is making use of some features (specifically
> pulling in other parts of the repository) that other Apache projects
> just don't make much use of. I agree that the transition could
> certainly have gone smoother if some more thought had been put into it
> beforehand, and some more information distributed to the developers as
> to what life post-conversion would be like, as opposed to the "you'll
> figure out it" kind of thing that seems to have happened.
I've explicitly asked about this functionality, and I was told that it
just works.
> That said, I don't think any of the problems you've got are
> insurmountable. If you can figure out a way to work around the few
> remaining problems I think you'll be ok.
Right, no problem is the world is insurmountable. I guess I will soon
finish mourning the environment that just worked and had 0 problems for
us, and move on trying to ride the more complicated beast which gives 0
extra benefits to us.
--
__________________________________________________________________
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: commit messages (was Re: another svn problem)
Posted by David Wheeler <da...@kineticode.com>.
On Nov 29, 2004, at 9:24 AM, Geoffrey Young wrote:
> svn commit: r106927 -
> /perl/modperl/docs/trunk/src/docs/2.0/api/Apache/compat.pod
> /perl/modperl/docs/trunk/src/docs/2.0/user/porting/compat.pod
>
> Becomes:
>
> svn commit: r106927 - src/docs/2.0/api/Apache/compat.pod
> src/docs/2.0/user/porting/compat.pod
I always hated having the file names in the subject--what if you make
changes to 50 files?? That's why SVN::Notify has a "context" option,
where only the lowest directory in the file tree is listed in the
subject when you've committed again more than one file.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: commit messages (was Re: another svn problem)
Posted by David Wheeler <da...@kineticode.com>.
On Nov 29, 2004, at 10:01 AM, Stas Bekman wrote:
> but as Geoff says we can't really use it and stuck with the python
> script.
Yeah, I was just saying, "nyah-nyah-nya-nya-nyah!" ;-)
>>> so I propose to put it at the very end of the subject line.
>> Or in a header? That will be fun for them. ;-)
>
> You mean a new mail header? X-SVN-Trunk? Sounds cool :)
Exactly. Maybe I'll add this to SVN::Notify. ;-)
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: commit messages (was Re: another svn problem)
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Nov 29, 2004, at 9:43 AM, Stas Bekman wrote:
>
>> it should list just the first entry.
>
>
> That's what svnnotify --subject-cx does.
but as Geoff says we can't really use it and stuck with the python script.
>>> since the branch information (/trunk or /branches) comes out under the
>>> Modified header in the email, I don't see why we wouldn't want to
>>> truncate
>>> to that point.
>>
>>
>> because if we start doing branching one may want to filter the mesages
>> by the prefix. (even though one could filter by matching against the
>> body as well). But normally I don't want to see it in the subject.
>>
>> so I propose to put it at the very end of the subject line.
>
>
> Or in a header? That will be fun for them. ;-)
You mean a new mail header? X-SVN-Trunk? Sounds cool :)
--
__________________________________________________________________
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: commit messages (was Re: another svn problem)
Posted by David Wheeler <da...@kineticode.com>.
On Nov 29, 2004, at 9:43 AM, Stas Bekman wrote:
> it should list just the first entry.
That's what svnnotify --subject-cx does.
>> since the branch information (/trunk or /branches) comes out under the
>> Modified header in the email, I don't see why we wouldn't want to
>> truncate
>> to that point.
>
> because if we start doing branching one may want to filter the mesages
> by the prefix. (even though one could filter by matching against the
> body as well). But normally I don't want to see it in the subject.
>
> so I propose to put it at the very end of the subject line.
Or in a header? That will be fun for them. ;-)
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: commit messages (was Re: another svn problem)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> so, we need to come up with a format. I guess for me, the only thing I'm
> still irked about is that the commit message includes lots of unnecessary
> path information. so, I would like to see something like this:
>
> Subject:
>
> svn commit: r106927 -
> /perl/modperl/docs/trunk/src/docs/2.0/api/Apache/compat.pod
> /perl/modperl/docs/trunk/src/docs/2.0/user/porting/compat.pod
>
> Becomes:
>
> svn commit: r106927 - src/docs/2.0/api/Apache/compat.pod
> src/docs/2.0/user/porting/compat.pod
what's the point of listing all the changed files in the Subject? You
can't see it anyway when it's too long. See the example of the one such
commit in modperl-2.0/SVN-MOVE:
Subject: svn commit: r105803 - in httpd/test/trunk/perl-framework: .
Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf
c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post
c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter
c-modules/list_modules c-modules/nntp_like c-modules/random_chunk
c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite
c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess
t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules
it should list just the first entry.
> since the branch information (/trunk or /branches) comes out under the
> Modified header in the email, I don't see why we wouldn't want to truncate
> to that point.
because if we start doing branching one may want to filter the mesages by
the prefix. (even though one could filter by matching against the body as
well). But normally I don't want to see it in the subject.
so I propose to put it at the very end of the subject line.
> any other opinions? once we come up with some concrete desires we will
> forward them to infrastructure@.
As written in SVN-MOVE doc:
Proposed Subject format:
$svn_id $first_subdir/$first_file ($trunk)
I doubt we should waste the crucual first chars that fit into the mailer
line with 'svn commit:' prefix.
--
__________________________________________________________________
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
commit messages (was Re: another svn problem)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
ok, I talked to justin at #asfinfra and he said that he would prefer that we
come up with a mail format we would like to see so that the default python
mailer could be tweaked and re-given to the SVN folks. the alternative
would be to use SVN::Notify _and_ mailer.py, which would be two scripts for
the infrastructure team to maintain.
so, we need to come up with a format. I guess for me, the only thing I'm
still irked about is that the commit message includes lots of unnecessary
path information. so, I would like to see something like this:
Subject:
svn commit: r106927 -
/perl/modperl/docs/trunk/src/docs/2.0/api/Apache/compat.pod
/perl/modperl/docs/trunk/src/docs/2.0/user/porting/compat.pod
Becomes:
svn commit: r106927 - src/docs/2.0/api/Apache/compat.pod
src/docs/2.0/user/porting/compat.pod
since the branch information (/trunk or /branches) comes out under the
Modified header in the email, I don't see why we wouldn't want to truncate
to that point.
any other opinions? once we come up with some concrete desires we will
forward them to infrastructure@.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by David Wheeler <da...@kineticode.com>.
On Nov 23, 2004, at 7:00 PM, Geoffrey Young wrote:
>> What's required for this, Geoff?
>
> I really don't know. but I'll take it up with infrastructure@ or
> #asfinfra
> on monday and find out.
I released a new version of SVN::Notify on Friday that has the
functionality required by Stas and others. So here's what needs to
happen to get it working:
1. Download and install SVN::Notify 2.43 from CPAN.
2. Add something like this to post-commit:
REPOS="$1"
REV="$2"
/usr/local/bin/svnnotify --repos-path "$REPOS" --revision "$REV" \
--to-regex-map docs-cvs@perl.apache.org=perl/modperl-docs \
--to-regex-map dev-cvs@perl.apache.org=perl/modperl2 \
--to-regex-map test-cvs@perl.apache.org=httpd/test \
--subject-cx --no-first-line
--strip-cx-regex "/perl/modperl|/perl/modperl-docs|/httpd/test"
--user-domain apache.org --with-diff --svnlook /usr/local/bin/svnlook \
--sendmail /usr/sbin/sendmail \
--viewcvs-url 'http://svn.apache.org/viewcvs.cgi/?rev=%s&view=rev'
A few notes on these commands:
* Be sure that the path to svnlook and sendmail are correct full paths.
* Modify the --to-regex-map values as necessary. It looks like the
paths haven't been reorganized yet...
* Use the --bugzilla-url or --rt-url options if you use Bugzilla or RT.
I'll be on IRC tomorrow.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by David Wheeler <da...@kineticode.com>.
On Nov 23, 2004, at 7:00 PM, Geoffrey Young wrote:
> I really don't know. but I'll take it up with infrastructure@ or
> #asfinfra
> on monday and find out.
I'm on #asfinfra most days. Holler at "Theory" to get my attention and
I'll join in.
> my thought is that if there is a chance that we can control the mailer
> on a
> per-PMC level that I'd rather it be in our control in perl. so, let's
> attack that issue first with infrastructure and go from there. I'll
> follow
> up here on monday with my success or failure.
Okay.
> in preparation, working on the subclass would be great. based on our
> other
> discussions you have a place to start. the only thing I would add to
> that
> is that using a filename in the subject as opposed to the first line
> of the
> commit probably makes more sense for a broad project like this, where
> people
> may only care about portions of the codebase. but we can always tweak
> it if
> I'm wrong.
The current subclass supports adding the lowest directory affected or
the file name affected, if there's only one. It would be simple for me
to add an option to leave out the first line of the message and another
one to strip out part of the directory tree from the directory or file
name as Stas originally suggested.
> thanks for helping out with this.
No problem.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
David Wheeler wrote:
> On Nov 23, 2004, at 4:55 PM, Geoffrey Young wrote:
>
>> david and I started a one-way conversation with infrastructure@ about
>> making
>> commit emails better which went nowhere. if we can control our own
>> mailer
>> and messages I think I'd like to prove to everyone that we can come up
>> with
>> something better using a SVN::Notify subclass than they can modifying
>> some
>> global python script. but, alas, I don't have the tuits to do it on
>> my own atm.
>
>
> What's required for this, Geoff?
I really don't know. but I'll take it up with infrastructure@ or #asfinfra
on monday and find out.
> It would take me no time to whip up a
> subclass. All that needs doing to set it up is for someone to add the
> appropriate command to post-commits. I can send the command spec, and
> discuss issues of getting it to be triggered only for mod_perl projects
> (which it can do using regular expressions). But svn users don't
> generally get access to post-commits the way we used to get access to
> CVSROOT...
my thought is that if there is a chance that we can control the mailer on a
per-PMC level that I'd rather it be in our control in perl. so, let's
attack that issue first with infrastructure and go from there. I'll follow
up here on monday with my success or failure.
in preparation, working on the subclass would be great. based on our other
discussions you have a place to start. the only thing I would add to that
is that using a filename in the subject as opposed to the first line of the
commit probably makes more sense for a broad project like this, where people
may only care about portions of the codebase. but we can always tweak it if
I'm wrong.
thanks for helping out with this.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by David Wheeler <da...@kineticode.com>.
On Nov 23, 2004, at 4:55 PM, Geoffrey Young wrote:
> david and I started a one-way conversation with infrastructure@ about
> making
> commit emails better which went nowhere. if we can control our own
> mailer
> and messages I think I'd like to prove to everyone that we can come up
> with
> something better using a SVN::Notify subclass than they can modifying
> some
> global python script. but, alas, I don't have the tuits to do it on
> my own atm.
What's required for this, Geoff? It would take me no time to whip up a
subclass. All that needs doing to set it up is for someone to add the
appropriate command to post-commits. I can send the command spec, and
discuss issues of getting it to be triggered only for mod_perl projects
(which it can do using regular expressions). But svn users don't
generally get access to post-commits the way we used to get access to
CVSROOT...
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> mod_perl is probably the project most closely tied to httpd outside of
> apr, but they have 10 million times the userbase that we do - being
> developmentally consistent with what is essentially our parent project
> lowers the bar for both new mod_perl developers and httpd developers
> who would like to see mod_perl succeed. for me, whenever I talk about
> how httpd does one thing or another this connection and desire for
> community crossover is what I have in mind.
+1. Cross-collaboration between projects is a real challenge,
because both developer communities have to see the benefits of
sharing a common goal. ++Apache::Test!
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I also find it interesting to see the different reactions in different
> ASF projects I keep an eye on as they convert. APR and HTTPD, for
> example, don't seem to have any real problems with the conversion, while
> mod_perl seems to keep running into issues. I guess it's just different
> projects having different usage patterns for the software.
I'm not entirely sure that we aren't making some of these issues up, or at
least making more of them than everyone else.
from my pov, the real issues are these:
- commit email subject
- no commit template
- the whole svn:external bit
all the rest fall under "svn is different than cvs, and different isn't as
good because making my mind undifferent takes up my few remaining precious
tuits." that's not criticism either - I felt the same way the first time I
had to use svn (though I got over it).
david and I started a one-way conversation with infrastructure@ about making
commit emails better which went nowhere. if we can control our own mailer
and messages I think I'd like to prove to everyone that we can come up with
something better using a SVN::Notify subclass than they can modifying some
global python script. but, alas, I don't have the tuits to do it on my own atm.
now, the commit template issue is a global one that all project need to deal
with. apparently everyone else is ok with it, or not making a big enough
fuss to make it something to worry about. so, we either accept it and move
on, or take care of it ourselves through infrastructure@.
the most serious issue is the svn:external bit, and it seems like we are in
exactly the same place as httpd/apr - you are required to have apr and
apr-util right under srclib/ to get httpd to build (as well as for release).
but nobody over there is complaining about how svn ignores foo or doesn't
do bar. so, the problem is either our mindset or something is really wrong
with our setup. in either case, both are fixable (just in different
places). if the solution is to checkout mod_perl then checkout A-T then we
should just do it, since it will just be for the developers anyway and
everyone is used to doing the same for httpd.
I can't see another real issue out there at the moment, but there may well
be others. fwiw, I checked out httpd/apr/mod_perl from svn as soon as they
were available and my nightly builds have gone off without a hitch since, so
I have no real complaints at all (save the way it was all kind of thrown
together, but no sense in complaining about that).
>> or just send them both to the same list, that's what httpd seems to do.
>
>
> thanks, but we aren't not httpd.
you know, animosity like this can't have a net positive effect on anyone.
mod_perl is probably the project most closely tied to httpd outside of apr,
but they have 10 million times the userbase that we do - being
developmentally consistent with what is essentially our parent project
lowers the bar for both new mod_perl developers and httpd developers who
would like to see mod_perl succeed. for me, whenever I talk about how httpd
does one thing or another this connection and desire for community crossover
is what I have in mind.
it is in our best interest to maintain a somewhat consistent feel between
the two projects - not to follow them over a bridge, of course, but to
follow them into battle even if it doesn't quite make sense to us on the
ground :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Stas Bekman wrote:
> While it's sort of OK for us developers to figure it out, quite often we
> ask users to get a fresh "cvs-r.i.p." checkout and we won't want to make
> them jumping through hoops, there is enough pain they have to endure.
Well, you already need to run 'perl Makefile.PL' in order to build,
right? Why not stick some code in there that looks for the Apache-Test
stuff you need and if it isn't there (and you're in an svn working copy)
do the switch?
> So what's the forecast for svn:externals, is it planned to be fixed, and
> how soon?
I don't personally have any plans to fix it, and I don't know of any
other Subversion developers who do in the immediate future. There are
some plans as to how it could be made to work better, but at this point
that's all it is, plans. As usual in open source projects something
gets fixed when someone is motivated to fix it, and most of the
developers do not seem to make heavy use of externals, thus they are
devoting their time to other issues, like locking support and merge
tracking.
> What bothers me the most is that when we asked whether modperl will be
> OK moved to svn, the answer was: "yes of course, everything is ready".
> Now we discover lots of broken/missing things. And unfortunately I find
> that the move to svn was really rushed and unjustifiable. In fact I'd
> prefer to see things reverted to cvs at least until after we get mp2.0
> out, but that's too late in the game and we depend on Apache-Test which
> is now under svn without a question.
It seems that mod_perl2 is making use of some features (specifically
pulling in other parts of the repository) that other Apache projects
just don't make much use of. I agree that the transition could
certainly have gone smoother if some more thought had been put into it
beforehand, and some more information distributed to the developers as
to what life post-conversion would be like, as opposed to the "you'll
figure out it" kind of thing that seems to have happened.
That said, I don't think any of the problems you've got are
insurmountable. If you can figure out a way to work around the few
remaining problems I think you'll be ok.
I also find it interesting to see the different reactions in different
ASF projects I keep an eye on as they convert. APR and HTTPD, for
example, don't seem to have any real problems with the conversion, while
mod_perl seems to keep running into issues. I guess it's just different
projects having different usage patterns for the software.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Stas Bekman <st...@stason.org>.
Garrett Rooney wrote:
> Stas Bekman wrote:
>
>>> svn diff seems plain broken for externals, other commands have no
>>> trouble seeing the modifications.
>>
>>
>>
>> :(
>>
>
> It also doesn't interact well with tagging or branching (you have to go
> in and fix up the svn:externals properties on the branch/tag manually)
> or with accessing a repository via multiple different ra layers (or even
> the same ra layer with http and https).
That's very important, that tags are applied across externals. I suppose
that also means that one can't ask to checkout a certain revision number
and expect to get the externals of the matching version? Is that right? In
which case this is very broken.
> svn:externals was a poorly thought out feature when it was added, and
> there are a number of problems with it, some of which can be fixed (the
> svn diff thing is probably fixable by making the underlying diff code
> aware of externals), some of which are just conceptually busted (the
> tags and multiple ra layer things just can't work in some cases). I
> personally argued for it to be deleted before 1.0 was released, but
> there were too many people using it by that point, and nobody was
> willing to put in the work for a real replacement at the time, so it
> stayed.
>
> This is why I suggested to Philippe that you use a dummy directory and
> svn switch to bring in the parts of the mod_perl tree that come from
> other places in the asf repository. It's irritating that it isn't
> automatic, but there are far fewer broken edge cases because svn switch
> is actually something that's baked right into the system as opposed to
> bolted on top of it.
While it's sort of OK for us developers to figure it out, quite often we
ask users to get a fresh "cvs-r.i.p." checkout and we won't want to make
them jumping through hoops, there is enough pain they have to endure.
So what's the forecast for svn:externals, is it planned to be fixed, and
how soon?
What bothers me the most is that when we asked whether modperl will be OK
moved to svn, the answer was: "yes of course, everything is ready". Now we
discover lots of broken/missing things. And unfortunately I find that the
move to svn was really rushed and unjustifiable. In fact I'd prefer to see
things reverted to cvs at least until after we get mp2.0 out, but that's
too late in the game and we depend on Apache-Test which is now under svn
without a question.
Thanks Garrett!
--
__________________________________________________________________
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: another svn problem (diff across svn:external
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Stas Bekman wrote:
>> svn diff seems plain broken for externals, other commands have no
>> trouble seeing the modifications.
>
>
> :(
>
It also doesn't interact well with tagging or branching (you have to go
in and fix up the svn:externals properties on the branch/tag manually)
or with accessing a repository via multiple different ra layers (or even
the same ra layer with http and https).
svn:externals was a poorly thought out feature when it was added, and
there are a number of problems with it, some of which can be fixed (the
svn diff thing is probably fixable by making the underlying diff code
aware of externals), some of which are just conceptually busted (the
tags and multiple ra layer things just can't work in some cases). I
personally argued for it to be deleted before 1.0 was released, but
there were too many people using it by that point, and nobody was
willing to put in the work for a real replacement at the time, so it stayed.
This is why I suggested to Philippe that you use a dummy directory and
svn switch to bring in the parts of the mod_perl tree that come from
other places in the asf repository. It's irritating that it isn't
automatic, but there are far fewer broken edge cases because svn switch
is actually something that's baked right into the system as opposed to
bolted on top of it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>
>> Markus Wichitill wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> I see yet another problem with svn. modperl-2.0 uses svn:externals:
>>>> docs
>>>> https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/src/docs/2.0
>>>> Apache-Test
>>>> https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test
>>>>
>>>> Now when I run 'svn diff' at the top level it won't show the diff
>>>> for those externals. Why? How this can be fixed? Thanks.
>>>
>>>
>>> Would it be feasible to only change and commit files in separate
>>> working copies of A-T and docs? That would also have the advantage
>>> that the externals wouldn't require https URLs.
>>
>>
>> Sorry Markus, I don't understand what do you propose.
>
>
> What I mean is, checkout
> https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/ and
> https://svn.apache.org/repos/asf/httpd/test/trunk/ (or subpaths of
> those) into their own working copies, and only edit files in those WCs,
> instead of editing files in the external paths of your main modperl WC
> of https://svn.apache.org/repos/asf/perl/modperl/trunk.
>
> That way, you don't need recursive diff over externals, and you don't
> need https URLs for the externals, since you don't commit through them.
> Even Unix users without SSL compiled-in can then retrieve the source
> (standard Windows binaries and the popular TortoiseSVN client have SSL).
>
> Of course, depending on how you work, having three different working
> copies might not be a good option.
Got it :)
While that will work for docs (I never edit docs inside the modperl
checkout, but always in its own checkout) that's not quite possible for
Apache-Test when the developed feature requires mod_perl checkout for
testing. Trying to shuffle external dirs in this case is very error-prone
and counter-productive.
--
__________________________________________________________________
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: another svn problem (diff across svn:external
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
> Markus Wichitill wrote:
>> Stas Bekman wrote:
>>> I see yet another problem with svn. modperl-2.0 uses svn:externals:
>>> docs
>>> https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/src/docs/2.0
>>> Apache-Test
>>> https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test
>>>
>>> Now when I run 'svn diff' at the top level it won't show the diff for
>>> those externals. Why? How this can be fixed? Thanks.
>>
>> Would it be feasible to only change and commit files in separate
>> working copies of A-T and docs? That would also have the advantage
>> that the externals wouldn't require https URLs.
>
> Sorry Markus, I don't understand what do you propose.
What I mean is, checkout
https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/ and
https://svn.apache.org/repos/asf/httpd/test/trunk/ (or subpaths of those)
into their own working copies, and only edit files in those WCs, instead of
editing files in the external paths of your main modperl WC of
https://svn.apache.org/repos/asf/perl/modperl/trunk.
That way, you don't need recursive diff over externals, and you don't need
https URLs for the externals, since you don't commit through them. Even Unix
users without SSL compiled-in can then retrieve the source (standard Windows
binaries and the popular TortoiseSVN client have SSL).
Of course, depending on how you work, having three different working copies
might not be a good option.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: another svn problem (diff across svn:external
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>
>> I see yet another problem with svn. modperl-2.0 uses svn:externals:
>> docs
>> https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/src/docs/2.0
>> Apache-Test
>> https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test
>>
>> Now when I run 'svn diff' at the top level it won't show the diff for
>> those externals. Why? How this can be fixed? Thanks.
>
>
> Would it be feasible to only change and commit files in separate working
> copies of A-T and docs? That would also have the advantage that the
> externals wouldn't require https URLs.
Sorry Marcus, I don't understand what do you propose.
> svn diff seems plain broken for externals, other commands have no
> trouble seeing the modifications.
:(
--
__________________________________________________________________
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: another svn problem (diff across svn:external
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
> I see yet another problem with svn. modperl-2.0 uses svn:externals:
> docs https://svn.apache.org/repos/asf/perl/modperl/docs/trunk/src/docs/2.0
> Apache-Test
> https://svn.apache.org/repos/asf/httpd/test/trunk/perl-framework/Apache-Test
>
> Now when I run 'svn diff' at the top level it won't show the diff for
> those externals. Why? How this can be fixed? Thanks.
Would it be feasible to only change and commit files in separate working
copies of A-T and docs? That would also have the advantage that the
externals wouldn't require https URLs.
svn diff seems plain broken for externals, other commands have no trouble
seeing the modifications.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org