You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Sander Striker <st...@apache.org> on 2004/03/12 19:25:49 UTC

[PROPOSAL] Move APR to the subversion repository

Hi,

I hereby would like to propose that we move APR to the Subversion
repository at http://svn.apache.org/repos/asf/.  Subversion had a
1.0 release februari 23rd.  Binaries are available for various
platforms.  Given that it is built on top of APR, it shouldn't
be a problem to build it on the platforms where no binaries
are available yet.

Subversion itself has been self hosting without problems for a few
years now.  There is overlap between APR and Subversion developers,
so we should be able to help eachother out if we come across any
issues.

A couple of projects have already gone before us, and there have
been no complaints (quite the opposite :).  The Commons TLP, and
the SpamAssassin project (incubator), have been using Subversion
for years, amongst others.

You can browse through history here:
  http://svn.apache.org/viewcvs/?root=Apache-SVN

Speaking of history, the full history will be preserved.

Then there is also the fine Subversion book:
  http://svnbook.red-bean.com/

To play around with subversion a bit, we have a scratch
repository at: https://svn.apache.org/repos/test.

First, log in via ssh, and run 'svnpasswd' to set
your subversion password.

Now you're ready to start messing about.

Create a personal area:
$ svn mkdir https://svn.apache.org/repos/test/<userid>
< you'll get a passwd prompt, your username is your asf userid >

Check out a working copy of your area:
$ svn co https://svn.apache.org/repos/test/<userid> my_working_copy

Experiment!


Sander

PS.  I'm going to propose the same on the dev@httpd list.

Re: [PROPOSAL] Move APR to the subversion repository

Posted by kf...@collab.net.
Thom May <th...@planetarytramp.net> writes:
> > As for timing, I would suggest making APR 1.0 official first, then 
> > switching over to Subversion shortly after.  But, let's please get APR 1.0 
> > out the door first.  It's overdue enough.  =)  -- justin

+1 on moving to Subversion given a consensus among the APR developers.
If people feel that switching will cause a temporary hiccup in
development, and this will delay APR 1.0, then waiting till after 1.0
seems like a good idea.

But the "raises the bar for contributions in general" objection is
decreasingly valid, I think.  A Subversion client is not that hard to
get these days; and installing one is not something that an APR
contributor would find difficult in any case. (Remember, contributors
don't need to set up a Subversion *server*, just a client.  That means
no potential Apache HTTPD dependency, no Berkeley DB dependency.)
IMHO, given that Spamassassin was fine with Subversion, APR has
nothing to be afraid of as far as raising the bar for unsolicited
contributions.

Let's make this decision on the basis of what current committers will
be comfortable with.  If people there have strong objections *on their
own behalf*, rather than on behalf of unknown future contributors,
then we shouldn't do it until those objections are assuaged.

Right now, the primary objection seems to be "Let's not interfere with
getting APR 1.0 done."  That seems very wise.  But once 1.0 is out,
does anyone object to switching then?

Aaron Bannert <aa...@clove.org> wrote:
> (Note the circular dependency in asking APR to adopt SVN before APR
> 1.0 is released, since SVN depends on APR. :)

:-)

But seriously, there is no circular dependency here.  SVN 1.0 depends
on APR 0.9.5, not APR 1.0.  All Subversion releases will always depend
on a particular release or release range of APR, never on APR head.

-Karl

Re: [PROPOSAL] Move APR to the subversion repository

Posted by Thom May <th...@planetarytramp.net>.
* Justin Erenkrantz (justin@erenkrantz.com) wrote :
> --On Friday, March 12, 2004 7:25 PM +0100 Sander Striker 
> <st...@apache.org> wrote:
> 
> >I hereby would like to propose that we move APR to the Subversion
> >repository at http://svn.apache.org/repos/asf/.  Subversion had a
> >1.0 release februari 23rd.  Binaries are available for various
> >platforms.  Given that it is built on top of APR, it shouldn't
> >be a problem to build it on the platforms where no binaries
> >are available yet.
> 
> +1.  The only other point I'd add is we'll still have 4x-daily source 
> snapshots available for those without the requisite tools.
> 
> As for timing, I would suggest making APR 1.0 official first, then 
> switching over to Subversion shortly after.  But, let's please get APR 1.0 
> out the door first.  It's overdue enough.  =)  -- justin
+1.
-Thom

Re: [PROPOSAL] Move APR to the subversion repository

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, March 12, 2004 7:25 PM +0100 Sander Striker <st...@apache.org> 
wrote:

> I hereby would like to propose that we move APR to the Subversion
> repository at http://svn.apache.org/repos/asf/.  Subversion had a
> 1.0 release februari 23rd.  Binaries are available for various
> platforms.  Given that it is built on top of APR, it shouldn't
> be a problem to build it on the platforms where no binaries
> are available yet.

+1.  The only other point I'd add is we'll still have 4x-daily source 
snapshots available for those without the requisite tools.

As for timing, I would suggest making APR 1.0 official first, then switching 
over to Subversion shortly after.  But, let's please get APR 1.0 out the door 
first.  It's overdue enough.  =)  -- justin

Re: [OT] lower the bar - was [PROPOSAL] Move APR to the subversion repository

Posted by Guenter Knauf <ef...@gmx.net>.
Hi Jeff,
> Not recommended, but when building on Win32 I always comment out the call
> to InterlockedCompareExchangePointer() and just return NULL ;)
hehe, I wasnt brave enough to do that...!

> For better handling of this dependency, how can we check for 64-bit build
> at
> compile time on Win32?  For a 64-bit build we really need to call
> InterlockedCompareExchangePointer(), but for 32-bit build, calling
> InterlockedCompareExchange() is fine and we can avoid the extra SDK
> dependency.
cool! That would be very great if we could find a way around this; even a simple -DBUILD32 would be suffient!

thanks, Guenter.




Re: [OT] lower the bar - was [PROPOSAL] Move APR to the subversion repository

Posted by Jeff Trawick <tr...@attglobal.net>.
Guenter Knauf wrote:
> Hi,
> 
>>I'm against immediate adoption of SVN for purely community-based
>>reasons, but not for technical reasons. I believe that switching to SVN
>>will raise the bar to entry for new contributors, and I think we
>>should do whatever we can do to try and lower this bar. Unfortunately
> 
> one other point I would like to to get around is that it seems I'm 
 >now forced to get MSVC7 if I want to continue to follow the 2.1-dev
 >development on Win32. Since the atomic functions were introduced
 >last November, I'm no longer able to compile 2.1-dev. I've tried
 >to update the platform SDK, but couldnt get around that update
 >either (not a ASF problem, but M$); perhaps someone can point me
 > to an update which cleanly applies to MSVC6 on W2K, and fixes the
 >problem with the atomic functions?
> If not, and MSVC7 turns out as mandatory, this will certaily raise 
 >the bar at least for Win32...

Not recommended, but when building on Win32 I always comment out the call to 
InterlockedCompareExchangePointer() and just return NULL ;)

For better handling of this dependency, how can we check for 64-bit build at 
compile time on Win32?  For a 64-bit build we really need to call 
InterlockedCompareExchangePointer(), but for 32-bit build, calling 
InterlockedCompareExchange() is fine and we can avoid the extra SDK dependency.

[OT] lower the bar - was [PROPOSAL] Move APR to the subversion repository

Posted by Guenter Knauf <ef...@gmx.net>.
Hi,
> I'm against immediate adoption of SVN for purely community-based
> reasons, but not for technical reasons. I believe that switching to SVN
> will raise the bar to entry for new contributors, and I think we
> should do whatever we can do to try and lower this bar. Unfortunately
one other point I would like to to get around is that it seems I'm now forced to get MSVC7 if I want to continue to follow the 2.1-dev development on Win32. Since the atomic functions were introduced last November, I'm no longer able to compile 2.1-dev. I've tried to update the platform SDK, but couldnt get around that update either (not a ASF problem, but M$); perhaps someone can point me to an update which cleanly applies to MSVC6 on W2K, and fixes the problem with the atomic functions?
If not, and MSVC7 turns out as mandatory, this will certaily raise the bar at least for Win32...

thanks, Guenter.



Re: [PROPOSAL] Move APR to the subversion repository

Posted by Jeff Trawick <tr...@attglobal.net>.
Guenter Knauf wrote:
> Hi,
> 
>>On Fri, Mar 12, 2004 at 07:25:49PM +0100, Sander Striker wrote:
>>
>>>I hereby would like to propose that we move APR to the Subversion
>>>repository at http://svn.apache.org/repos/asf/.
> 
> 
>>-1
> 
> 
>>I'm against immediate adoption of SVN for purely community-based
>>reasons, but not for technical reasons. I believe that switching to SVN
>>will raise the bar to entry for new contributors, and I think we
> 
> sorry, but I cant get this. 
> For what is it good for that I'm familiar with CVS, have it on my machine, 
 > and am able to contribute patches, if I'm not able to commit them, and
 >my posts get mostly ignored (as with many other posts too) because either
 >the commiters have no time for review or no time for commiting???

FYI...   if you want your patches to stick out like a sore thumb until they are 
committed, submit a PR for them at http://issues.apache.org/bugzilla/index.html 
and specify the PatchAvailable keyword...  it is all too easy for patches 
submitted via the mailing list to scroll off the top of the screen as more and 
more mail arrives...

certainly the work has to be done to address patches, but at least putting them 
there makes it easy for developers to concentrate on them when they have time


Re: [PROPOSAL] Move APR to the subversion repository

Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 14 Mar 2004, Cliff Woolley wrote:

> I'll put my heads together with the PMC and see what we can come up
> with.

Umm... just reread that... "my heads"... *crosses all (four?  eight? ;)
eyes*... okay... I need a vacation ;)

Re: [PROPOSAL] Move APR to the subversion repository

Posted by Cliff Woolley <jw...@virginia.edu>.
On Sun, 14 Mar 2004, Guenter Knauf wrote:

> For what is it good for that I'm familiar with CVS, have it on my
> machine, and am able to contribute patches, if I'm not able to commit
> them, and my posts get mostly ignored (as with many other posts too)
> because either the commiters have no time for review or no time for
> commiting???

That's a completely fair question... and fortunately one we can take
action to correct.  :)  I'll put my heads together with the PMC and see
what we can come up with.

--Cliff

Re: [PROPOSAL] Move APR to the subversion repository

Posted by Guenter Knauf <ef...@gmx.net>.
Hi,
> On Fri, Mar 12, 2004 at 07:25:49PM +0100, Sander Striker wrote:
>> I hereby would like to propose that we move APR to the Subversion
>> repository at http://svn.apache.org/repos/asf/.

> -1

> I'm against immediate adoption of SVN for purely community-based
> reasons, but not for technical reasons. I believe that switching to SVN
> will raise the bar to entry for new contributors, and I think we
sorry, but I cant get this. 
For what is it good for that I'm familiar with CVS, have it on my machine, and am able to contribute patches, if I'm not able to commit them, and my posts get mostly ignored (as with many other posts too) because either the commiters have no time for review or no time for commiting???

> should do whatever we can do to try and lower this bar. Unfortunately
correct. Then get more commiters; there are anyway not much out here who are crazy enough to test their patches at least on 2 or more different platforms like I do mostly; and I was hoping that after the split-up to 2.1-dev we could continue with a lower level of checking, that means getting more commiters, and that they are allowed to check in simple patches without discussion, and only conceptual changes need to be discussed.
The truth seems to be other than that: even commiters fear to commit changes without discussing it, and if they try to discuss then it even happens to those that the discussion dies....

just my 0.2 EUR.

thanks, Guenter.



Re: [PROPOSAL] Move APR to the subversion repository

Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Mar 12, 2004 at 07:25:49PM +0100, Sander Striker wrote:
> I hereby would like to propose that we move APR to the Subversion
> repository at http://svn.apache.org/repos/asf/.

-1

I'm against immediate adoption of SVN for purely community-based
reasons, but not for technical reasons. I believe that switching to SVN
will raise the bar to entry for new contributors, and I think we
should do whatever we can do to try and lower this bar. Unfortunately
SVN doesn't yet have the wide distribution that our current tools
have, and I feel that by pushing this now we will hurt the project.


(Note the circular dependency in asking APR to adopt SVN before APR
1.0 is released, since SVN depends on APR. :)

-aaron

Repository conversion, WAS: Re: Re[2]: [PROPOSAL] Move APR to the subversion repository

Posted by Sander Striker <st...@apache.org>.
First off all, the repository conversion toolset is irrelevant
to this proposal.  The repository will be converted by the
Infrastructure Team (hi fitz!), and an integrity check will
be done.  If we encounter bugs in cvs2svn during the process,
those will be fixed.

And the other way around aswell.  If cvs2svn encounters an impossible
state, it will warn, and we can fix up the CVS repository.

Furthermore, over the years people have done some wonky things
directly in the filesystem, in some ASF projects, to 'preserve
history'.  I'm willing to bet that even when checking out a tree
with CVS you may end up with a broken tree.  This is all to do
with the fact CVS tracks files and not trees.

That said it becomes a bit more apparent why we _need_ knobs to
turn and buttons to push to do a conversion tweaked to fit our
needs.

Now, given this all has very little to do with APR, it would be
best to find a different forum for any followup discussion.

Thanks,

Sander

Re: Re[2]: [PROPOSAL] Move APR to the subversion repository

Posted by Max Bowsher <ma...@ukf.net>.
Lev Serebryakov wrote:
> Hello, Brian!
> Saturday, March 13, 2004, 5:44:27 PM, you wrote:
>
>> Please define 'better'
>   50+ success stories with refinecvs (and all of these people try
>   cvs2svn before). About 10 repositories I know, which COULD NOT BE
>   converted with cvs2svn & converted with refinecvs. I don't know any
>   repository, which is converted with cvs2svn without problems and
>   could not be proceed with refinecvs. If you know such repositories
>   -- you are welcome!

Yes, cvs2svn used to be pretty buggy. It is now significantly less so, and
still improving.

>> Last time I checked refinecvs it:
>> - Did the entire repository conversion in-memory.
>   Yes, it is one of main `feature/bug' of this script. It works fast, but
>   consume memory. Some algorithms inside is O(n^2) and even worse. For
>   example, restoring tag creation history is very slow procedure. I've
>   tried to store tables in DBM, but it slow down process in orders of
>   magnitude.
>> - Skipped over branches and tags with anomalies (if you supply certain
>> switches--otherwise, it just errors out).  CVS repositories often have
>> more RCS edge cases than actual data. :-)
>   Even in case of `apr'?
>
>> - Had no test suite.
>   FreeBSD repository + whole cvs2svn test suite. Is it enough?

Where is this test suite? It doesn't seem to be in the tarball.

>> All of the above three things make me hesitant to trust my (let alone
>> the ASF's!) historical data to it.
>   Ok. But why should I trust my historical data cvs2svn, if it even
>   could not create proper dump for some of my repositories? We (I,
>   you, other authors of cvs2svn, whole CVS and SVN systems) are not
>   Donald Khuth or Dijkstra. We didn't prove our programs
>   mathematically.
>
>   I've started to write refinecvs when cvs2svn reports `All done'
>   about my repository and `svnadmin load' reject resulting dump! After
>   that I fixed 3 errors in dump by hands (adding files twice, deleting
>   files twice) and, as final result, got repository with messed branches.

You encountered bugs, OK, many of which are fixed now.

For reasons I do not fully understand, instead of helping to fix them, you
wrote a new piece of software.

The result is 2 tools each with their own advantages and disadvantages,
neither of which is strictly better than the other. Unfortunately, since one
is in Perl and the other in Python, I'm not sure there is any way to rectify
this situation.

>   In any case it is bad idea to blindly convert repo and think, that
>   everything is Ok. In any case, it is good idea to check every branch
>   and every tag (by checking out two working copies: from CVS and from
>   svn and comparing byte-by-byte).

Agree.


Max.


Re[2]: [PROPOSAL] Move APR to the subversion repository

Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
Hello, Brian!
Saturday, March 13, 2004, 5:44:27 PM, you wrote:

BWF> Please define 'better'
  50+ success stories with refinecvs (and all of these people try
  cvs2svn before). About 10 repositories I know, which COULD NOT BE
  converted with cvs2svn & converted with refinecvs. I don't know any
  repository, which is converted with cvs2svn without problems and
  could not be proceed with refinecvs. If you know such repositories
  -- you are welcome!

BWF> Last time I checked refinecvs it:
BWF> - Did the entire repository conversion in-memory.
  Yes, it is one of main `feature/bug' of this script. It works fast, but
  consume memory. Some algorithms inside is O(n^2) and even worse. For
  example, restoring tag creation history is very slow procedure. I've
  tried to store tables in DBM, but it slow down process in orders of
  magnitude.
BWF> - Skipped over branches and tags with anomalies (if you supply certain
BWF> switches--otherwise, it just errors out).  CVS repositories often have
BWF> more RCS edge cases than actual data. :-)
  Even in case of `apr'?
  
BWF> - Had no test suite.
  FreeBSD repository + whole cvs2svn test suite. Is it enough?

BWF> All of the above three things make me hesitant to trust my (let alone
BWF> the ASF's!) historical data to it.
  Ok. But why should I trust my historical data cvs2svn, if it even
  could not create proper dump for some of my repositories? We (I,
  you, other authors of cvs2svn, whole CVS and SVN systems) are not
  Donald Khuth or Dijkstra. We didn't prove our programs
  mathematically.
  
  I've started to write refinecvs when cvs2svn reports `All done'
  about my repository and `svnadmin load' reject resulting dump! After
  that I fixed 3 errors in dump by hands (adding files twice, deleting
  files twice) and, as final result, got repository with messed branches.

  In any case it is bad idea to blindly convert repo and think, that
  everything is Ok. In any case, it is good idea to check every branch
  and every tag (by checking out two working copies: from CVS and from
  svn and comparing byte-by-byte).
  
BWF> Has any of the above changed in the last month?
  No. Because here are no bugreports. And nobody, who complains about
  RCS edge cases could not answer on simple question: `How it should
  be proceed, what you want as result?'. What do you want as result when
  two revisions marked with one tag? Could you answer?

  I'm thinking about interactive mode for such cases... But refinecvs
  doesn't have ANY knobs to affect such cases! And even without
  interactive mode, refinecvs give you fine control over conversion
  process.

--
               Lev Serebryakov


Re: [PROPOSAL] Move APR to the subversion repository

Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Fri, 2004-03-12 at 14:49, Lev Serebryakov wrote:
> Hello, Sander!
> Friday, March 12, 2004, 9:25:49 PM, you wrote:
> 
> SS> Speaking of history, the full history will be preserved.
>   Sort of self-advertisement :)
>   You could try `refinecvs' script to convert CVS repo into SVN one.
>   Many users reported, that refinecvs works much better, that cvs2svn.
> 
>   http://lev.serebryakov.spb.ru/refinecvs/

Please define 'better'

Last time I checked refinecvs it:

- Did the entire repository conversion in-memory.
- Skipped over branches and tags with anomalies (if you supply certain
switches--otherwise, it just errors out).  CVS repositories often have
more RCS edge cases than actual data. :-)
- Had no test suite.

All of the above three things make me hesitant to trust my (let alone
the ASF's!) historical data to it.

Has any of the above changed in the last month?

-Fitz


Re: [PROPOSAL] Move APR to the subversion repository

Posted by Lev Serebryakov <le...@serebryakov.spb.ru>.
Hello, Sander!
Friday, March 12, 2004, 9:25:49 PM, you wrote:

SS> Speaking of history, the full history will be preserved.
  Sort of self-advertisement :)
  You could try `refinecvs' script to convert CVS repo into SVN one.
  Many users reported, that refinecvs works much better, that cvs2svn.

  http://lev.serebryakov.spb.ru/refinecvs/

--
               Lev Serebryakov


Re: [PROPOSAL] Move APR to the subversion repository

Posted by Sander Striker <st...@apache.org>.
On Fri, 2004-03-12 at 19:25, Sander Striker wrote:
[...]
> A couple of projects have already gone before us, and there have
> been no complaints (quite the opposite :).  The Commons TLP, and
> the SpamAssassin project (incubator), have been using Subversion
> for years, amongst others.

This would be s/years/months/ ofcourse.  Sorry about that.

We'll try to get a to svn converted apr in the test repository
shortly so you can experiment with real data.

Sander

Re: [PROPOSAL] Move APR to the subversion repository

Posted by Jeff Trawick <tr...@attglobal.net>.
related trivia for Solaris users: the folks at www.blastwave.org were kind 
enough to add ssl support to their subversion package this weekend... 
previously it was not useful for accessing the test repository