You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2006/04/06 20:04:37 UTC
Branching for 1.4
Hi,
It is now 3 months since we released 1.3.0 (and six months since we
branched). I think we have enough on trunk to warrant branching for
1.4. Below is a list of some things that come to my head, others
could probably fill in more.
diff/merge/blame can ignore whitespace and eol-style only changes.
svnsync/replay
svnserve is a real service on Windows.
wc replacements, bug fixes.
Lots of client bug fixes in diff (referring to malcolm's work)
wc propcaching and other speed and space improvements
svndiff1 format
The -c option to diff and merge (minor, but anyway)
The sws feature (http://www.red-bean.com/sws)
Use switch instead of recheckout when changing URLs of svn:externals.
bdb 4.4 support (if it doesn't go into 1.3.x)
Experimental serf support.
svn diff --summarize
So, I'm proposing to branch in two weeks, meaning April 21. The
reasons I want to wait for two weeks is for people to have some time
for stuff they want in before branching. (I, for example, have some
things that will affect the WC format that I want to get into
1.4. I'll post separately about that.) Note that branching doesn't
mean that we release an RC immediately, so the door won't be closed at
that date.
If we branch at the proposed date, then give it some weeks to
stabilize before RC, some more weeks for RC trouble (which we can hope
we don't have:-) and a month for soak. Then, we might release in late
June, making us roll 1.4.0 about 6 months after 1.3.0. Given the list
of improvements and the timing, I think starting the release process
soon is appropriate.
Any opinions about this?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Stefan Küng <to...@gmail.com>.
Peter N. Lundblad wrote:
> diff/merge/blame can ignore whitespace and eol-style only changes.
> svnsync/replay
> svnserve is a real service on Windows.
> wc replacements, bug fixes.
> Lots of client bug fixes in diff (referring to malcolm's work)
> wc propcaching and other speed and space improvements
> svndiff1 format
> The -c option to diff and merge (minor, but anyway)
> The sws feature (http://www.red-bean.com/sws)
:)
> Use switch instead of recheckout when changing URLs of svn:externals.
> bdb 4.4 support (if it doesn't go into 1.3.x)
> Experimental serf support.
> svn diff --summarize
Is 1.4 going to use neon-0.26 instead of 0.25? If yes, I'd really like
to have one more feature added (can't do it myself, sorry):
Neon-0.26 has a new API to explicitely choose which authentication
methods are used. This new API should be put to good use in Subversion
to specifically activate/deactivate the SSPI authentication on Windows
(and maybe other auth methods on other OS too).
This is really an important feature to have. Because as it is right now,
SSPI is used whenever it is available. The Problem is that some servers
have the user "guest" active, and that means the authentication will
succeed every time with that user, but then later the authorization will
fail when the user tries to access the repository. Since SSPI auth is
always used, there is no fall back to basic authentication - the
operation simply will fail.
This is also a problem with the current Subversion CL client. I guess
the reason nobody has reported problems with that yet is that most users
accessing a repo with authentication against a windows domain are not
using the CL client. TSVN has deactivated the SSPI authentication on the
1.3.x line, because we received some reports for the 1.3.0RCx releases.
The only option to 'solve' these problems was to deactivate SSPI completely.
So it would be much much better if there was an option in the Subversion
'servers' config file where a user can deactivate the SSPI
authentication if required.
Yes, the whole problem could also be solved by deactivating the user
'guest' on the domain controller. But that's not always possible because
other apps inside a company might rely on that user account to be active.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
David Anderson writes:
> * Peter N. Lundblad <pe...@famlundblad.se> [2006-04-06 22:04:37]:
> > It is now 3 months since we released 1.3.0 (and six months since we
> > branched). I think we have enough on trunk to warrant branching for
> > 1.4.
>
> An here was I writing in the RM guide that the usual delay is around 4
> months :-) (otoh, I also wrote it is feature and community driven, not
> time driven).
I didn't mean to imply that it is time driven. But looking at the
dicsussions from January some of us strongly object to a too short
release cycle. I just wanted to point out that we're at six months if
we branch in ttwo weeks, which doesn't seem too short:-)
> > If we branch at the proposed date, then give it some weeks to
> > stabilize before RC, some more weeks for RC trouble (which we can hope
> > we don't have:-) and a month for soak. Then, we might release in late
> > June, making us roll 1.4.0 about 6 months after 1.3.0. Given the list
> > of improvements and the timing, I think starting the release process
> > soon is appropriate.
> >
> > Any opinions about this?
>
> Good sense of timing :-)
We'll see if that holds:-)
> Preparing the RM hat to branch/stuff when people are happy with it,
Great!
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Serf support for APR 0.9.x (was: Branching for 1.4)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/7/06, Mark Phippard <ma...@softlanding.com> wrote:
> BTW, what other dependencies does ra_serf have? I would assume it would
> still need OpenSSL for SSL support as well as zlib? Does it also need an
> XML parser?
AFAIK ra_serf relies on OpenSSL for SSL support, zlib for compression
support, and expat for XML parsing.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Serf support for APR 0.9.x (was: Branching for 1.4)
Posted by Mark Phippard <ma...@softlanding.com>.
justin.erenkrantz@gmail.com wrote on 04/07/2006 01:17:08 PM:
> On 4/7/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > See, you should have committed those patches for APR 0.9.x support in
> > serf when I sent them in ;-)
>
> Nyah. =)
>
> If we decide bundling serf with 1.4 is the way to go, I'll go and add
> in APR 0.9.x support for serf. But, if we decide not to bundle, then
> I'll stick with the APR 1.0+ requirement in serf. -- justin
Take this for what it is worth.
We do not support ra_dav on OS/400 port because we have not ported Neon. I
have been hoping to target ra_serf since it is built on Serf which is
built on APR. However, we are probably stuck with APR 0.9 on OS/400 for
the foreseeable future. So it would be nice if Serf has support for APR
0.9.
BTW, what other dependencies does ra_serf have? I would assume it would
still need OpenSSL for SSL support as well as zlib? Does it also need an
XML parser?
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Ivan Zhakov <ch...@gmail.com>.
On 4/7/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 4/7/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > See, you should have committed those patches for APR 0.9.x support in
> > serf when I sent them in ;-)
>
> Nyah. =)
>
> If we decide bundling serf with 1.4 is the way to go, I'll go and add
> in APR 0.9.x support for serf. But, if we decide not to bundle, then
> I'll stick with the APR 1.0+ requirement in serf. -- justin
>
Support for APR 0.9.x will be usefull anyway. We use APR 0.9.x on
Windows (because httpd 2.0.x uses it). How difficult implement this?
--
Ivan Zhakov
Re: Dropping dependencies in tarballs (was: Re: Branching for 1.4)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Justin Erenkrantz writes:
> On 4/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> > The reason it was dropped was that it effectively double the burden on
> > tarball verifying, because you had to test it with and without dependencies.
>
> Why? If the source code is the same, why the need to verify with or
> without dependencies?
>
OK, downloading both packages, making sure the source code is the same
and test building both should be enough.
> > I'd rather like us to drop the shipping of dependencies. People will
> > have to fetch some extra packages to build from source. What's the
> > big problem with that?
>
> I think the argument is that people who use packaged versions don't
> care about dependencies (they probably don't even use our releases;
> but from their OS vendor). Those people who download directly from us
> want a smoother installation process. -- justin
Why not just put up a pre-release without dependencies included and
see how many complaints we get? I'd like to know if this "hard to
find the right dependencies" is a real problem or not.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs (was: Re: Branching for 1.4)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> The reason it was dropped was that it effectively double the burden on
> tarball verifying, because you had to test it with and without dependencies.
Why? If the source code is the same, why the need to verify with or
without dependencies?
> I'd rather like us to drop the shipping of dependencies. People will
> have to fetch some extra packages to build from source. What's the
> big problem with that?
I think the argument is that people who use packaged versions don't
care about dependencies (they probably don't even use our releases;
but from their OS vendor). Those people who download directly from us
want a smoother installation process. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 4/8/06, David Anderson <da...@calixo.net> wrote:
> What are people thoughts on this besides Justing and me?
"Three sigs per tarball" is what we've done for years. I don't
understand how Justin can say that this was "never Ben Reser's
intention", when Ben Reser *always* held up releases because we were
waiting for 1 more .zip sig, for example. The fact that this policy
is documented in hacking.html is not an accident, or the result of
some giant perpetual misunderstanding: it's what we've all agreed on
and have been deliberately following for a long time now.
I'm not saying there's anything wrong with debating the policy and
changing it; I'm just saying that Justin's objection of "overkill"
is the first and only objection we've ever heard to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by David Anderson <da...@calixo.net>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-04-08 08:39:39]:
> That policy was never Ben Reser's or my intention when we started
> asking for multiple sigs on files. Asking for at least six committers
> (3 Unix, 3 Windows) to sign off on a release is overkill that just
> isn't warranted. It's nice-to-have when we have a hyper-active
> committership; but there'll come a day when we need to push out a
> release quickly and we don't have swarms of committers looking over
> the RM's shoulder to get either 6 people to sign off on a release or
> force people to go to heroic steps and test on *both* Win32 and Unix
> in order for their votes to count.
That last part was never my intention (forcing people to test both
win32 and unix to make their sig count).
3 sigs per file is the current policy as per hacking.html, and as I
said, I have never heard anyone suggest otherwise before this, which
is why I'm surprised at what you are saying.
If we are to reduce the requirements from 3 per file to 3 total, my
view is that we are reducing tarball blessing to mindless
rubber-stamping, like granting a seal of approval because it is
something annoying users want, and not because it is supposed to help
overall quality.
What are people thoughts on this besides Justing and me? Perhaps we
should wait for the weekend to out, so that other people can voice
their opinion on this issue, as it seems we're both in quite
fundamental disagreement over what tarball signing is supposed to
convey.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/8/06, David Anderson <da...@calixo.net> wrote:
> For as long as I've been the release manager, I've never seen anyone
> advocate anything other than 3 signatures per file (with the provision
> that .tar.gz and .tar.bz2 can be both signed after testing one and
> comparing contents).
That policy was never Ben Reser's or my intention when we started
asking for multiple sigs on files. Asking for at least six committers
(3 Unix, 3 Windows) to sign off on a release is overkill that just
isn't warranted. It's nice-to-have when we have a hyper-active
committership; but there'll come a day when we need to push out a
release quickly and we don't have swarms of committers looking over
the RM's shoulder to get either 6 people to sign off on a release or
force people to go to heroic steps and test on *both* Win32 and Unix
in order for their votes to count. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by David Anderson <da...@calixo.net>.
* Justin Erenkrantz <ju...@erenkrantz.com> [2006-04-07 20:42:48]:
> I've seen you raise this point before, but I believe this is a
> misunderstanding of our intended release processes. I don't believe
> we should need three sigs on *each* file to release that file - we
> should need at least three sigs *in total* to release.
For as long as I've been the release manager, I've never seen anyone
advocate anything other than 3 signatures per file (with the provision
that .tar.gz and .tar.bz2 can be both signed after testing one and
comparing contents).
I believe that only 3 sigs per release is too low to hope to catch any
problems during the blessing phase. Sure, it would make the release
process faster, but having 2 unix sigs and one win32 sig does not
convince me that the packages are ready for release. What if the
win32 signer doesn't notice a problem because he doesn't do a full
6-way test (such is not required by our current policies, a single RA
method and a single backend is sufficient), which makes us release a
win32 package that has a severe bug elsewhere, in an untested region
of the code?
Furthermore, the RM's signature is not, in itself, blessing. It is
originally there so that other committers can verify that they are
testing tarball that wasn't tampered with since the RM uploaded
it. If it were any other way, I could not provide a signature for the
.zip, because I have no working win32 environment to run the tests
in. Granted, I associate my RM signature with a test run of the unix
tarball, but the primary intent of the RM sig is not to bless the
release, but to bless the release to bless, as it were.
> (The assumption is that the RM has signed all of the files as he
> created them.) Having as many sigs as possible is goodness, but we
> shouldn't need every file signed 3 times to issue a release. That's
> way overkill. -- justin
I find 3 to be most acceptable, and that the signature process is
quite speedy when there is a single flavor of Subversion to sign.
In short, I don't believe that compensating a larger number of
packages by lowering our standards is an acceptable option.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, David Anderson <da...@calixo.net> wrote:
> In reply to the rest of the thread, dependancies were indeed removed,
> in a dual package offering (with deps and without), for 1.3.0-rc1 and
> rc2. The observed effect, as was discussed at the time, was that
> those two tarballs didn't gather 6 signatures within about a working
> week. We reverted to the previous offering for rc3 and later, and
> those gathered sigs in a more timely fashion.
I've seen you raise this point before, but I believe this is a
misunderstanding of our intended release processes. I don't believe
we should need three sigs on *each* file to release that file - we
should need at least three sigs *in total* to release. (The
assumption is that the RM has signed all of the files as he created
them.) Having as many sigs as possible is goodness, but we shouldn't
need every file signed 3 times to issue a release. That's way
overkill. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Michael Sinz <Mi...@sinz.org>.
David Anderson wrote:
> * Nicol?s Lichtmaier <ni...@reloco.com.ar> [2006-04-07 18:09:30]:
>> Why not, instead of "base" and "full", doing this:
>>
>> subversion-1.4.0.tar.gz - Just Subversion
>> subversion-1.4.0-deps.tar.gz - Subversion dependencies.
>
> A very potent idea indeed, thanks for suggesting it!
Yes...
[...]
> And finally, as a tangential aside, it would make distributing an APR
> 1.x ready package much easier, if we want to: just provide two
> dependency bundles, one with APR 0.9 for backward compatibility, and
> one with APR 1.x for those who want a full APR 1.x ready dependency
> suite. And as far as blessing goes, there is still only one
> subversion source package to test, the basic one with no bundled deps.
The only question I have here is how does one say a Subversion tarball is
blessed unless there was some set of versions of dependencies use as part
of the blessing. Without including those you could have developers that
have some mix that is "unnatural" on their systems and thus the code
could end up depending on those features.
Yes, this is true for other libraries (glibc, zlib, etc) but they have
been much more stable in API (they are also much older)
I worry about the fact that APR and NEON tend to have major incompatibilities
between versions, even minor version changes (especially in NEON)
Thus, a split archive (deps and the core source) may make some downloading
smaller (since a fresh rolling of the Subversion code would normally not
change the deps versions) but the testing would still need to be done with
the deps in order to bless a specific combination. Without that, the
blessing process becomes less useful as the combinations needed to reproduce
the various developers blessed version gets unmanageable.
> Thoughts? The dist script can be adapted to perform all of this and
> more, so it's really down to what we feel is right. I'm:
>
> - +1 on shipping a slim tarball and a separate "deps only" tarball
> - +0 on keeping the status quo (and introducing serf for 1.4), and
> - -0 on providing two source code tarballs, with and without deps.
I think that is reasonable, albeit I would be -1 on the two source code
tarballs. The split tarballs works but we need to define the blessing
process relatively strictly such that there is some actual value to the
signatures beyond "some combination works on my machine."
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by David Anderson <da...@calixo.net>.
* Nicol?s Lichtmaier <ni...@reloco.com.ar> [2006-04-07 18:09:30]:
> Why not, instead of "base" and "full", doing this:
>
> subversion-1.4.0.tar.gz - Just Subversion
> subversion-1.4.0-deps.tar.gz - Subversion dependencies.
A very potent idea indeed, thanks for suggesting it!
In reply to the rest of the thread, dependancies were indeed removed,
in a dual package offering (with deps and without), for 1.3.0-rc1 and
rc2. The observed effect, as was discussed at the time, was that
those two tarballs didn't gather 6 signatures within about a working
week. We reverted to the previous offering for rc3 and later, and
those gathered sigs in a more timely fashion.
The fact that the tarballs had rolling problems that were detected
after about 5 days may have skewed this result, but I believe that
everyone who'd been around for previous minor releases noticed a
distinct slowing down of the blessing process at the time, before the
packages were recalled.
If we can get quick signing on 6 packages instead of 3, I'm happy to
oblige and produce tarballs with and without dependencies. However, I
am very much more +1 to nick's proposal of shipping a dep-free
tarball, which can be signed by the usual testing procedure, and a
separate "dependencies only" package, which can be verified by basic
diffing, if required.
I feel that this shifts the emphasis to the "light" tarball as being
our official code release, much more so than providing two flavors of
the Subversion source code.
I think this bundling also settles both sides of the "But I want ease
of source build!" vs. "I don't want to download useless bundled code
I'm not using!" quite elegantly.
And finally, as a tangential aside, it would make distributing an APR
1.x ready package much easier, if we want to: just provide two
dependency bundles, one with APR 0.9 for backward compatibility, and
one with APR 1.x for those who want a full APR 1.x ready dependency
suite. And as far as blessing goes, there is still only one
subversion source package to test, the basic one with no bundled deps.
Thoughts? The dist script can be adapted to perform all of this and
more, so it's really down to what we feel is right. I'm:
- +1 on shipping a slim tarball and a separate "deps only" tarball
- +0 on keeping the status quo (and introducing serf for 1.4), and
- -0 on providing two source code tarballs, with and without deps.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
> It is not always easy to find the right versions of packages to go
> along with Subversion and everything else on your system... It also
> means extra config steps to tell Subversion where to find all of the
> dependent libraries - /usr/local is not generally in the standard
> include or library paths, and that is the default prefix for all of
> the dependent libraries that Subversion uses...
Why not, instead of "base" and "full", doing this:
subversion-1.4.0.tar.gz - Just Subversion
subversion-1.4.0-deps.tar.gz - Subversion dependencies.
The second package wouldn't have subversion itself. It would have all
the dependencies in the expected subdirectories so that by doing:
tar xvzf subversion-1.4.0.tar.gz ; tar xvzf subversion-1.4.0-deps.tar.gz
..you get whay we have today.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dropping dependencies in tarballs
Posted by Michael Sweet <mi...@easysw.com>.
Peter N. Lundblad wrote:
> Justin Erenkrantz writes:
> > On 4/7/06, Eric Gillespie <ep...@pretzelnet.org> wrote:
> > > ra-serf seems to me like an excellent opportunity to stop
> > > bundling our dependencies. -0 to adding apr-serf to the
> > > subversion distfile, for 1.4 or any other release.
> >
> > For 1.4, I would really like us to implement the 'base' (no deps) and
> > 'full' (incl. deps) release variants. We talked about doing this for
> > 1.3, but it got dropped. -- justin
> >
>
> The reason it was dropped was that it effectively double the burden on
> tarball verifying, because you had to test it with and without dependencies.
>
> I'd rather like us to drop the shipping of dependencies. People will
> have to fetch some extra packages to build from source. What's the
> big problem with that?
It is not always easy to find the right versions of packages to go
along with Subversion and everything else on your system... It also
means extra config steps to tell Subversion where to find all of the
dependent libraries - /usr/local is not generally in the standard
include or library paths, and that is the default prefix for all of
the dependent libraries that Subversion uses...
I know, cry me a river...
FWIW, I don't care anymore - I now have to jump through those hoops
for OpenSSL, which is *so* braindead on systems without /dev/random
or /dev/urandom. One of these days I'll provide a patch for ra_serf
to support GNU TLS and we can be done with it...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Dropping dependencies in tarballs (was: Re: Branching for 1.4)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
Justin Erenkrantz writes:
> On 4/7/06, Eric Gillespie <ep...@pretzelnet.org> wrote:
> > ra-serf seems to me like an excellent opportunity to stop
> > bundling our dependencies. -0 to adding apr-serf to the
> > subversion distfile, for 1.4 or any other release.
>
> For 1.4, I would really like us to implement the 'base' (no deps) and
> 'full' (incl. deps) release variants. We talked about doing this for
> 1.3, but it got dropped. -- justin
>
The reason it was dropped was that it effectively double the burden on
tarball verifying, because you had to test it with and without dependencies.
I'd rather like us to drop the shipping of dependencies. People will
have to fetch some extra packages to build from source. What's the
big problem with that?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, Eric Gillespie <ep...@pretzelnet.org> wrote:
> ra-serf seems to me like an excellent opportunity to stop
> bundling our dependencies. -0 to adding apr-serf to the
> subversion distfile, for 1.4 or any other release.
For 1.4, I would really like us to implement the 'base' (no deps) and
'full' (incl. deps) release variants. We talked about doing this for
1.3, but it got dropped. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> If we decide bundling serf with 1.4 is the way to go, I'll go and add
> in APR 0.9.x support for serf. But, if we decide not to bundle, then
> I'll stick with the APR 1.0+ requirement in serf. -- justin
ra-serf seems to me like an excellent opportunity to stop
bundling our dependencies. -0 to adding apr-serf to the
subversion distfile, for 1.4 or any other release.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> See, you should have committed those patches for APR 0.9.x support in
> serf when I sent them in ;-)
Nyah. =)
If we decide bundling serf with 1.4 is the way to go, I'll go and add
in APR 0.9.x support for serf. But, if we decide not to bundle, then
I'll stick with the APR 1.0+ requirement in serf. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/7/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> (Garrett's probably going to laugh, but it'll mean that serf should
> then support APR 0.9. Grr.)
See, you should have committed those patches for APR 0.9.x support in
serf when I sent them in ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, David Anderson <da...@calixo.net> wrote:
> On a side-note, I haven't followed the progress of ra_serf. Does it
> now pass all tests, ie. can I build a ra_serf enabled svn and use
> that? If so, we may want to discuss whether to bundle Serf with the
> packages, in the same way that we currently bundle Neon.
ra_serf passes all regression tests except for lock and svnsync.
That's mainly because I haven't gotten around to writing those two yet
- those two aren't very high on my personal priority list. =) I can
have lock and svnsync implemented by the time we start the RC cycles.
So, yes, I feel ra_serf should be a go for 1.4 on a non-default basis.
I don't think it's prudent yet to talk about switching the default
from neon/ra_dav yet. An export of the serf tree is currently only
about 380KB (660KB after running buildconf - darn autoconf; in
contrast, neon-0.25.5 is 3.9MB), so we could think about bundling serf
to ease people trying it out. (Garrett's probably going to laugh, but
it'll mean that serf should then support APR 0.9. Grr.) I would like
at least one release cycle with actual users opt'ing-in before
considering switching the default; but that step isn't warranted yet.
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by David Anderson <da...@calixo.net>.
* Peter N. Lundblad <pe...@famlundblad.se> [2006-04-06 22:04:37]:
> It is now 3 months since we released 1.3.0 (and six months since we
> branched). I think we have enough on trunk to warrant branching for
> 1.4.
An here was I writing in the RM guide that the usual delay is around 4
months :-) (otoh, I also wrote it is feature and community driven, not
time driven).
> diff/merge/blame can ignore whitespace and eol-style only changes.
> svnsync/replay
> svnserve is a real service on Windows.
> wc replacements, bug fixes.
> Lots of client bug fixes in diff (referring to malcolm's work)
> wc propcaching and other speed and space improvements
> svndiff1 format
> The -c option to diff and merge (minor, but anyway)
> The sws feature (http://www.red-bean.com/sws)
> Use switch instead of recheckout when changing URLs of svn:externals.
> bdb 4.4 support (if it doesn't go into 1.3.x)
> Experimental serf support.
> svn diff --summarize
This is indeed, from the user POV, a worthy list of features for 1.4.
On a side-note, I haven't followed the progress of ra_serf. Does it
now pass all tests, ie. can I build a ra_serf enabled svn and use
that? If so, we may want to discuss whether to bundle Serf with the
packages, in the same way that we currently bundle Neon.
> So, I'm proposing to branch in two weeks, meaning April 21. The
> reasons I want to wait for two weeks is for people to have some time
> for stuff they want in before branching. (I, for example, have some
> things that will affect the WC format that I want to get into
> 1.4. I'll post separately about that.) Note that branching doesn't
> mean that we release an RC immediately, so the door won't be closed at
> that date.
I'm fine to branch and get pre-release stuff going by that date.
> If we branch at the proposed date, then give it some weeks to
> stabilize before RC, some more weeks for RC trouble (which we can hope
> we don't have:-) and a month for soak. Then, we might release in late
> June, making us roll 1.4.0 about 6 months after 1.3.0. Given the list
> of improvements and the timing, I think starting the release process
> soon is appropriate.
>
> Any opinions about this?
Good sense of timing :-)
Who still has features that they want to put in 1.4 ? Are we planning
to have a first-stage rename support (merging of the renames branch
rooneg is working on) in 1.4, or can we put that off until 1.5 ?
Preparing the RM hat to branch/stuff when people are happy with it,
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Branching for 1.4
Posted by Ivan Zhakov <ch...@gmail.com>.
On 4/7/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> Hi,
>
> It is now 3 months since we released 1.3.0 (and six months since we
> branched). I think we have enough on trunk to warrant branching for
> 1.4. Below is a list of some things that come to my head, others
> could probably fill in more.
>
> diff/merge/blame can ignore whitespace and eol-style only changes.
> svnsync/replay
> svnserve is a real service on Windows.
> wc replacements, bug fixes.
> Lots of client bug fixes in diff (referring to malcolm's work)
> wc propcaching and other speed and space improvements
> svndiff1 format
> The -c option to diff and merge (minor, but anyway)
> The sws feature (http://www.red-bean.com/sws)
> Use switch instead of recheckout when changing URLs of svn:externals.
> bdb 4.4 support (if it doesn't go into 1.3.x)
> Experimental serf support.
> svn diff --summarize
>
> So, I'm proposing to branch in two weeks, meaning April 21. The
> reasons I want to wait for two weeks is for people to have some time
> for stuff they want in before branching. (I, for example, have some
> things that will affect the WC format that I want to get into
> 1.4. I'll post separately about that.) Note that branching doesn't
> mean that we release an RC immediately, so the door won't be closed at
> that date.
>
> If we branch at the proposed date, then give it some weeks to
> stabilize before RC, some more weeks for RC trouble (which we can hope
> we don't have:-) and a month for soak. Then, we might release in late
> June, making us roll 1.4.0 about 6 months after 1.3.0. Given the list
> of improvements and the timing, I think starting the release process
> soon is appropriate.
>
> Any opinions about this?
>
I am +1 for proposed timeline. But I want fit ability to copy copied
files in 1.4.
Discussion was here http://svn.haxx.se/dev/archive-2005-12/0020.shtml
, but it ended without consesus: some people was for this feature,
some against. How I could push it in 1.4?
--
Ivan Zhakov
Re: Branching for 1.4
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/6/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> Hi,
>
> It is now 3 months since we released 1.3.0 (and six months since we
> branched). I think we have enough on trunk to warrant branching for
> 1.4. Below is a list of some things that come to my head, others
> could probably fill in more.
>
> diff/merge/blame can ignore whitespace and eol-style only changes.
> svnsync/replay
> svnserve is a real service on Windows.
> wc replacements, bug fixes.
> Lots of client bug fixes in diff (referring to malcolm's work)
> wc propcaching and other speed and space improvements
> svndiff1 format
> The -c option to diff and merge (minor, but anyway)
> The sws feature (http://www.red-bean.com/sws)
> Use switch instead of recheckout when changing URLs of svn:externals.
> bdb 4.4 support (if it doesn't go into 1.3.x)
> Experimental serf support.
> svn diff --summarize
>
> So, I'm proposing to branch in two weeks, meaning April 21. The
> reasons I want to wait for two weeks is for people to have some time
> for stuff they want in before branching. (I, for example, have some
> things that will affect the WC format that I want to get into
> 1.4. I'll post separately about that.) Note that branching doesn't
> mean that we release an RC immediately, so the door won't be closed at
> that date.
>
> If we branch at the proposed date, then give it some weeks to
> stabilize before RC, some more weeks for RC trouble (which we can hope
> we don't have:-) and a month for soak. Then, we might release in late
> June, making us roll 1.4.0 about 6 months after 1.3.0. Given the list
> of improvements and the timing, I think starting the release process
> soon is appropriate.
>
> Any opinions about this?
The one remaining issue I think needs to be resolved is the questions
about providing some mechanism for limiting access to thinks like
ra_replay (svnsync). I'll send another email about this later today,
but I really do think we need to have some sort of story for this
before 1.4.x is branched.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org