You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/10/29 22:10:46 UTC
Subversion 0.14.4 released
This is just a bugfix release on the way to Subversion Beta. Grab the
tarball from:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260
Thanks to everyone who worked on this -- including the many who wrote
careful bug reports, which (as is apparent from the logs and issues
database) were essential to fixing a lot of the problems.
For more details, run
$ svn log -r3553:3200 http://svn.collab.net/repos/svn/trunk
...or see the CHANGES file below :-).
-Karl
--------------------------------------------------------------------------
Version 0.14.4 [Alpha Interim 4] (released 29 Oct 2002, revision r3553)
User-visible changes:
* new working-copy entry-caching: speeds many ops up to 5x (#749)
* new 'svnadmin recover', instead of db_recover
* client can now view & change server-side revision props (e.g. log messages)
* new --non-interactive switch for commandline client
* new --incremental option to 'svn log'
* new -r {date} syntax for specifying dated revs; works over network too.
* automatically set svn:executable prop when adding or importing (#870)
* initial $EDITOR text now ignores all log data below special token
* consistify behavior of text & prop columns in 'svn status' output.
* .svn/auth/* files now chmod 700, to stop scaring people. :-)
* improved labels in 'svn diff' output (#936)
* run-time adjustable neon timeout in newly renamed 'servers' config file
* big improvements to cvs2svn script: bugfixes and basic branch/tag support
* new python access-control hook script
* no more implicit dot-target for 'svn propedit' or 'svn propset' (#924)
* Win32 improvements:
- use system-wide config-file/registry
- run-time configurable diff/diff3 binary locations (#668)
* remove obsolete --xml-file support
* Handbook is now ported to Docbook, 2 new chapters.
Developer-visible changes:
* abstracted option/help-parsing code, now shared between svn and svnadmin
* require apache 2.0.42
* use neon 0.23.5: fix XML entity derefs, SSL server certs, HP-UX build, etc.
* support Berkeley DB 4.0 *or* 4.1
* many SWIG binding improvements:
- better overall coverage of apr and libsvn_* library symbols
- new 'make swig-py-ext' and 'make install-swig-py-ext' targets
* finish conversion of all editor/drivers to "new" style (#737)
* removed xml-delta editors and editor drivers and related tests
* new predicate-logic system added to automated-test system ("skip" support)
* more work on mailer.py
* no more lost commit messages (#761)
* eradication of misused stringbufs, obsolete code removal (#909)
* mem-leak fixes in libsvn_fs (#860)
* improved atomicity of working-file translations (#914)
* improve ./configure --help output (#949)
* MANY bugfixes, especially for entry-locks (#931, #932, #847, #938),
merges (#880, ), auth storage (#934); also #921 (svnadmin
segfault), #907 (xml quoting), #918 (post-commit processing), #935
(path canonicalization), #779 (diff errors)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> > * support Berkeley DB 4.0 *or* 4.1
>
> Unfortunately, I think rev 3550 broke BDB 4.1, I get
>
> $ ./config.nice
> [snip]
> checking for Berkeley DB in /usr/local/db4 (as db4)... no
> configure: error: Could not find Berkeley DB 4.0.14. with libname "db4"
> $ ls /usr/local/db4/lib
> libdb-4.1.a libdb-4.1.la libdb-4.1.so libdb-4.so libdb.a libdb.so
Hmmm. That's bad. Looking at the diff for 3550, though, it's totally
non-obvious (to me) why it would have that effect.
Ben, any thoughts?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Philip, does Brane's latest patch work for you?
Yes.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Nov 01, 2002 at 11:26:24PM +0200, Nuutti Kotivuori wrote:
>...
> - and that's really a big if - if such a level is needed, I think it
> would be best to reinstate the good old milestone system. Issues could
> be associated with a particular milestone - just like is done with
> revisions now - and when releasing versions, it could just be said
> which milestones were achieved and which were left to later
> version. Very straightforward and easy - and the amount of confusion
> caused by this should be very little.
>
> But - the current system is fine - just food for though if something
> is needed in the future.
The old milestone system was dropped for a couple reasons:
1) we needed a "standard" version numbering system
2) the numbers we chose were equal to the milestone: M6 was 0.6.0, M7 was
0.7.0, etc. Thus, the milestone was redundant
It is interesting to note that we had a 0.10.1 and 0.10.2.
The current problem is that we "locked into" 0.14.x being the alpha releases
and 0.15.x being the beta releases. That was the core mistake. We conflated
release state with the version number.
Now, they've been unlinked, and I think everything will be happy again...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > What d'y'all say? I'll wait for responses before updating the status
> > page & issue tracker appropriately.
>
> Good call. Totally +1 on that.
Cool. I'll update the status page and issue tracker appropriately,
then.
> Agreed. Just trying to say that people shouldn't be upset if we monkey the
> features around a bit between releases.
Absolutely. Complaining is grounds for being asked for patches
pronto, as always :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Oct 31, 2002 at 04:11:08PM -0600, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > * issue tracking: we could start using names rather than numbers, and then
> > just assign a name to a particular number. Adding this level of
> > indirection will work for the issue tracking, but it requires that we
> > clearly associate a name with a release.
>...
> Named levels of indirection *always* end up being confusing. People
Yup. I definitely agree -- that was buried in my text above, but not as
clearly as you spelled out.
>...
> I hate that whole system so much;
> let's please not go there. Everybody loses.
Hey... I'm not advocating it either.
/me turns Karl's Cranky Meter back down... :-)
> Dates are ordered, but the trouble is, they're dates :-). They can't
> be moved, they can only be overshot.
Nah. We can undershoot them, too!
We've been good with dates, as long as they have a +/- few days fuzziness to
them. Back during major feature building, some got quite ravaged, but I
think we're actually in a good place to put in a stake and meet it +/-.
That saiid...
>...
> In other words, instead of insisting that Beta is 0.15, let's just not
> specify what Beta is, and start number our next interim releases like
> this:
>
> 0.15.0 (and bugfix releases would be 0.15.1, 0.15.2, etc...)
> 0.16.0 (and bugfix releases would be 0.16.1, 0.16.2, etc...)
>
> I think that solves all of our problems.
>
> What d'y'all say? I'll wait for responses before updating the status
> page & issue tracker appropriately.
Good call. Totally +1 on that.
>...
> > Lastly, people should always be wary of "oh, issue #XYZ will be fixed in
> > SVN A.B.C". Unless and until the community gets a marketing department
> > making commitments to customers, then those markers are advisory rather
> > than toe-the-ine commitments.
>
> Sure, they're advisory, but they're not meaningless. Associating
Agreed. Just trying to say that people shouldn't be upset if we monkey the
features around a bit between releases.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Lele Gaifax <le...@seldati.it> writes:
> How would that be possible?? I'm surely loosing the point, or do you
> mean that it is after all possible to "svn co; edit something; tar
> -czf; rm -rf", ie without committing it?
I don't think we would ever do it, but technically one could build a
dist from a mixed-revision working copy, that's all.
It was an academic point, not really constructive in the conversation,
I admit :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Lele Gaifax <le...@seldati.it>.
>>>>> On 31 Oct 2002 23:28:49 -0600, Karl Fogel <kf...@newton.ch.collab.net> said:
KF> Lele Gaifax <le...@seldati.it> writes:
>> What about using a "virtual" fourth value that defaults to the
>> revision number? This, btw, augment the information kept in the
>> version number, and should solve the ambiguity noted by Karl. I
>> gives both the user and developer point of view of the sources
>> in one shot.
KF> Neat idea, though in extreme cases it's possible for a release
KF> not to even correspond to any single tree under a revision.
How would that be possible?? I'm surely loosing the point, or do you
mean that it is after all possible to "svn co; edit something; tar
-czf; rm -rf", ie without committing it?
KF> Nevertheless... I think it would be kind of weird.
KF> I mean, the revision numbers are moving along a whole different
KF> parallel axis. They'd always be increasing; and it's a lot of
KF> digits to have in the shorthand release number.
Yes, but I was thinking it from a slightly different pow, that is how
I use the four integer version id under Windows: the first three are
the actual revision number, while the fourth, that Delphi nicely bump
each time I rebuild the whole app, is simply a counter that helps to
disambiguate when the first three aren't enough. So I usually talk
about version X.Y.Z, that's the user perception of the matter. On the
repository (still using CVS there :() I diligently created a label for
X.Y.Z, the developer's pow, and then I usually reset the fourth
number, that is mainly for my own use to distinguish between various
stages of development before the actual release. But, given that under
svn with a simple integer I can point to the exact whole tree that
generated *that* version (say 0.14.4 but with this and that patch
applied) I would happily change my habit :)
So, the shorthand release number wouldn't change, but you'd be able to
be more precise and say 0.14.4@3456.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri
real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Lele Gaifax <le...@seldati.it> writes:
> What about using a "virtual" fourth value that defaults to the
> revision number? This, btw, augment the information kept in the
> version number, and should solve the ambiguity noted by Karl. I gives
> both the user and developer point of view of the sources in one shot.
Neat idea, though in extreme cases it's possible for a release not to
even correspond to any single tree under a revision. But still, in
general they *do* correspond to some revision, and probably always
will.
Nevertheless... I think it would be kind of weird. I mean, the
revision numbers are moving along a whole different parallel axis.
They'd always be increasing; and it's a lot of digits to have in the
shorthand release number. And after all, the revision number is
available in the dist's name, and posts here have proven that people
are aware of it and include it in their reports.
Dunno. I guess I'd like to try the more conventional solution first
and see if that works out.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Lele Gaifax <le...@seldati.it>.
>>>>> On Thu, 31 Oct 2002 13:49:52 -0800, Greg Stein <gs...@lyra.org> said:
GS> On Wed, Oct 30, 2002 at 02:06:39PM -0600, Karl Fogel wrote:
>> Next time, let's please call it "0.14.4b" or "0.14.4.2" (just
>> by tweaking the minor number in svn_version.h appropriately).
GS> svn_version.h defines three *integer* values so that
GS> versioning can be programmatically detected and managed. We
GS> don't have a system for ".4b" or ".4.2" types of
GS> numbering.
What about using a "virtual" fourth value that defaults to the
revision number? This, btw, augment the information kept in the
version number, and should solve the ambiguity noted by Karl. I gives
both the user and developer point of view of the sources in one shot.
just my .01 euro,
thanx&bye,
lele.
--
nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri
real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Nuutti Kotivuori <na...@iki.fi>.
Karl Fogel wrote:
> In other words, instead of insisting that Beta is 0.15, let's just
> not specify what Beta is, and start number our next interim releases
> like this:
>
> 0.15.0 (and bugfix releases would be 0.15.1, 0.15.2, etc...)
> 0.16.0 (and bugfix releases would be 0.16.1, 0.16.2, etc...)
>
> I think that solves all of our problems.
>
> What d'y'all say? I'll wait for responses before updating the
> status page & issue tracker appropriately.
Oh yes, this would be a lot nicer. It gives the additional leeway in
the patchlevel numbers - and it's much easier to talk to strangers
about status when the numbers are smaller.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Nuutti Kotivuori <na...@iki.fi>.
Karl Fogel wrote:
> Named levels of indirection *always* end up being confusing. People
> can't remember what name goes with what release; outsiders coming in
> for the first time are lost in a swirl of arbitrary names and no
> idea how they're ordered. Does "Woody" come before "Anaerobic
> Brachiator"? Does "Spotted Ungulate" come before "Dancing
> Arthropod", or is it the other way around? Who can say? I hate
> that whole system so much; let's please not go there. Everybody
> loses.
Hmm - I thought about this matter a little and came up to a conclusion
that seemed quite reasonable.
I don't think an additional level of indirection is needed, after the
switch to use minor revision numbers rather than patchlevels. But, if
- and that's really a big if - if such a level is needed, I think it
would be best to reinstate the good old milestone system. Issues could
be associated with a particular milestone - just like is done with
revisions now - and when releasing versions, it could just be said
which milestones were achieved and which were left to later
version. Very straightforward and easy - and the amount of confusion
caused by this should be very little.
But - the current system is fine - just food for though if something
is needed in the future.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> If you can reduce the external dependencies, then the numbers are right
> where they belong: cheap.
Understood -- I love cheap numbers too. But...
> * issue tracking: we could start using names rather than numbers, and then
> just assign a name to a particular number. Adding this level of
> indirection will work for the issue tracking, but it requires that we
> clearly associate a name with a release. After seeing a bunch of
> childish names associated with Open Source projects (I'll avoid pointing
> fingers, cuz I don't want to embarass some of the GNOME folks... oh...
> oops :-), I don't really enjoy naming releases. Especially patch-level
> releases. Maybe if we just stuck to simple things like "eagle" and
> "sparrow" and "robin", then we'd be okay.
>
> Without a level of indirection, the issue tracker is simply going to be
> messed up. Or... we could use dates. "mid-November" or "end-November".
> If we plan to stick to regular releases, then this will work fine. And
> since the actual date is fuzzy, then "mid-November" seems all right. Of
> course, if each release "slips" by a few days, we'll end up fixing
> "mid-December" issues in January :-)
Named levels of indirection *always* end up being confusing. People
can't remember what name goes with what release; outsiders coming in
for the first time are lost in a swirl of arbitrary names and no idea
how they're ordered. Does "Woody" come before "Anaerobic Brachiator"?
Does "Spotted Ungulate" come before "Dancing Arthropod", or is it the
other way around? Who can say? I hate that whole system so much;
let's please not go there. Everybody loses.
Dates are ordered, but the trouble is, they're dates :-). They can't
be moved, they can only be overshot.
> MAJOR.MINOR.PATCH. I think the change in number was quite fine for what we
> did. Since we haven't hit 1.0 yet, the versioning restrictions on API
> compatibility aren't really being applied, but that patch level *does* mean
> "just a bug fix; zero source/binary API changes".
Good point. Hmmm...
You know, I think I missed the obvious answer here: rather than add a
fourth number, why don't we start using the *third* number the way we
always said we would?
In other words, instead of insisting that Beta is 0.15, let's just not
specify what Beta is, and start number our next interim releases like
this:
0.15.0 (and bugfix releases would be 0.15.1, 0.15.2, etc...)
0.16.0 (and bugfix releases would be 0.16.1, 0.16.2, etc...)
I think that solves all of our problems.
What d'y'all say? I'll wait for responses before updating the status
page & issue tracker appropriately.
> Cool. Like I mentioned, leaving a marker that says that 0.14.4 was pulled
> would be good.
Check, thanks.
> Lastly, people should always be wary of "oh, issue #XYZ will be fixed in
> SVN A.B.C". Unless and until the community gets a marketing department
> making commitments to customers, then those markers are advisory rather
> than toe-the-ine commitments.
Sure, they're advisory, but they're not meaningless. Associating
issues with ordered milestones is less important for mature projects
like Apache, which are already in production use at many sites.
Subversion has an urgent need to prioritize, and tracking issues this
way has been a lifesaver, for all the extra burden it imposes. (But
+1 on reducing that burden if we can!)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Oct 30, 2002 at 02:06:39PM -0600, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > No... it needs to be called 0.14.5.
> >
> > It is quite possible that people grabbed the 0.14.4 tarball. We want to
> > ensure that when problems are reported, that we know which tarball they
> > grabbed.
> >
> > And yes, this also means that some of the changes since 0.14.4 will be
> > incorporated into the new 0.14.5 (e.g. xml logging and Karl's prop work).
> >
> > Release numbers are cheap. Use them. :-)
>
> <displeasure level="very mild">
Oh. Well, let me just turn up your Cranky Meter a bit :-)
> Next time, let's please call it "0.14.4b" or "0.14.4.2" (just by
> tweaking the minor number in svn_version.h appropriately).
svn_version.h defines three *integer* values so that versioning can be
programmatically detected and managed. We don't have a system for ".4b" or
".4.2" types of numbering. Adding such a thing would certainly be possible,
but I don't see that it is needed. We have a strong definition of versioning
(based on the APR definition), and adding the extra numbers isn't going to
help.
> Release numbers are only cheap when used like rational numbers :-).
The numbers *are* cheap. The root of the issue here is the *external* uses
of those numbers. Specifically, we have:
* issue tracking
* status/release page
* human discussion/perception
If you can reduce the external dependencies, then the numbers are right
where they belong: cheap.
* issue tracking: we could start using names rather than numbers, and then
just assign a name to a particular number. Adding this level of
indirection will work for the issue tracking, but it requires that we
clearly associate a name with a release. After seeing a bunch of
childish names associated with Open Source projects (I'll avoid pointing
fingers, cuz I don't want to embarass some of the GNOME folks... oh...
oops :-), I don't really enjoy naming releases. Especially patch-level
releases. Maybe if we just stuck to simple things like "eagle" and
"sparrow" and "robin", then we'd be okay.
Without a level of indirection, the issue tracker is simply going to be
messed up. Or... we could use dates. "mid-November" or "end-November".
If we plan to stick to regular releases, then this will work fine. And
since the actual date is fuzzy, then "mid-November" seems all right. Of
course, if each release "slips" by a few days, we'll end up fixing
"mid-December" issues in January :-)
Lastly, people should always be wary of "oh, issue #XYZ will be fixed in
SVN A.B.C". Unless and until the community gets a marketing department
making commitments to customers, then those markers are advisory rather
than toe-the-ine commitments.
* status/release page: concentrate on release date first, numbering second.
If the page says "Mid-November: Subversion 0.14.6", and the issue
tracker concurs, then people will not rely on the number as much.
* human discussion/perception: is this really a problem? People are aware
that we zoomed right past .4 and that .5 is the latest release. And
awareness can be enhanced by updating the web page to say "0.14.4 was
released, but pulled due to a problem with its logic for locating
Berkeley DB". Apache has skipped quite a few numbers in its release, and
it doesn't seem to cause much problem. Of course, there is no milestone
management in its issue tracker, nor a list of future releases :-)
All of this sort of requires answering the question "why do we want the
numbers to be 'cheap'?" Simplicity. Once you start tacking on letters or
additional parts, or this or that, then the rules surrounding those numbers
become much more difficult. And the tradeoffs for dealing with "lost
versions" is much less than the long-term effects of a more complex
versioning system. (this is why I was so hinky about Brane's initial version
numbering stuff; very flexible, but the interactions between all the bits
was hard to grok)
We get long term simplicity, and hard and fast rules/doc for the use of those
three numbers. But we get some exposure to "lost versions".
>...
> bigger. Also, it's a little misleading to increment the first minor
> number for such a small change -- that is, for a tiny bugfix to an
> interim release, rather than a full interim release.
MAJOR.MINOR.PATCH. I think the change in number was quite fine for what we
did. Since we haven't hit 1.0 yet, the versioning restrictions on API
compatibility aren't really being applied, but that patch level *does* mean
"just a bug fix; zero source/binary API changes".
>...
> Version number aside, I purposely waited until after the release to
> commit that prop work. Although it's probably fine this time, in
> general, we should look at the trunk commits between the inital
> release and the bugfix release, determine whether they are really 100%
> innocuous, and not hesitate to make a temporary branch for the bugfix
> release(s).
Ben and I were chatting on AIM while we he was rolling. Looking at the log
was part of that. If there was something ugly, then 0.14.5 would have come
off a branch :-)
> "Branches and tags are cheap. Use them. :-)"
"Branches and tags are cheap. Use them if necessary. :-)"
:-)
> P.S. I've shifted the milestones and will take care of
> project_status.html later.
Cool. Like I mentioned, leaving a marker that says that 0.14.4 was pulled
would be good.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> No... it needs to be called 0.14.5.
>
> It is quite possible that people grabbed the 0.14.4 tarball. We want to
> ensure that when problems are reported, that we know which tarball they
> grabbed.
>
> And yes, this also means that some of the changes since 0.14.4 will be
> incorporated into the new 0.14.5 (e.g. xml logging and Karl's prop work).
>
> Release numbers are cheap. Use them. :-)
Check. I'm testing r3564 right now, over both ra_local and ra_dav.
If all goes well, I'll roll a new tarball and post it as 0.14.5 very
soon.
I guess 0.14.4 will be the shortest release in history. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Brandon Ehle <az...@yahoo.com> writes:
> >Version number aside, I purposely waited until after the release to
> >commit that prop work. Although it's probably fine this time, in
> >general, we should look at the trunk commits between the inital
> >release and the bugfix release, determine whether they are really 100%
> >innocuous, and not hesitate to make a temporary branch for the bugfix
> >release(s).
>
> One of the things you guys might consider is to branch the code at the
> release and fix the bugs in the branch rather than in the trunk and
> release 1.4.1 from the branch rather than the trunk to avoid these
> types of issues.
Um, yes, that's what I was suggesting :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Brandon Ehle <az...@yahoo.com>.
>
>
>Version number aside, I purposely waited until after the release to
>commit that prop work. Although it's probably fine this time, in
>general, we should look at the trunk commits between the inital
>release and the bugfix release, determine whether they are really 100%
>innocuous, and not hesitate to make a temporary branch for the bugfix
>release(s).
>
>
One of the things you guys might consider is to branch the code at the
release and fix the bugs in the branch rather than in the trunk and
release 1.4.1 from the branch rather than the trunk to avoid these types
of issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> No... it needs to be called 0.14.5.
>
> It is quite possible that people grabbed the 0.14.4 tarball. We want to
> ensure that when problems are reported, that we know which tarball they
> grabbed.
>
> And yes, this also means that some of the changes since 0.14.4 will be
> incorporated into the new 0.14.5 (e.g. xml logging and Karl's prop work).
>
> Release numbers are cheap. Use them. :-)
<displeasure level="very mild">
Next time, let's please call it "0.14.4b" or "0.14.4.2" (just by
tweaking the minor number in svn_version.h appropriately).
Release numbers are only cheap when used like rational numbers :-).
Because we called it 0.14.5, a bunch of target milestones in the issue
tracker had to get shifted, and the change to the status page gets
bigger. Also, it's a little misleading to increment the first minor
number for such a small change -- that is, for a tiny bugfix to an
interim release, rather than a full interim release. 0.14.5 had a
definition before now, and we just released something that didn't meet
that definition. Not a huge deal, just makes it a little harder for
someone following the project to figure out what's going on.
Version number aside, I purposely waited until after the release to
commit that prop work. Although it's probably fine this time, in
general, we should look at the trunk commits between the inital
release and the bugfix release, determine whether they are really 100%
innocuous, and not hesitate to make a temporary branch for the bugfix
release(s).
"Branches and tags are cheap. Use them. :-)"
-Karl
P.S. I've shifted the milestones and will take care of
project_status.html later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 29, 2002 at 07:50:36PM -0600, Ben Collins-Sussman wrote:
> Blair Zajac <bl...@orcaware.com> writes:
>
> > This patch worked for me. I've built and passed a complete make test with
> > Berkeley DB 4.1 on RedHat 8.0.
> >
>
> Philip, does Brane's latest patch work for you? It works on my
> FreeBSD 4.7 system:
>
> checking for Berkeley DB in /usr/local/include/db4 and /usr/local/lib
> (as db4)... yes
>
> If everyone is happy, I'll commit the patch and re-roll a 14.4
> tarball. Just give the word.
No... it needs to be called 0.14.5.
It is quite possible that people grabbed the 0.14.4 tarball. We want to
ensure that when problems are reported, that we know which tarball they
grabbed.
And yes, this also means that some of the changes since 0.14.4 will be
incorporated into the new 0.14.5 (e.g. xml logging and Karl's prop work).
Release numbers are cheap. Use them. :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Ben Collins-Sussman <su...@collab.net>.
Blair Zajac <bl...@orcaware.com> writes:
> This patch worked for me. I've built and passed a complete make test with
> Berkeley DB 4.1 on RedHat 8.0.
>
Philip, does Brane's latest patch work for you? It works on my
FreeBSD 4.7 system:
checking for Berkeley DB in /usr/local/include/db4 and /usr/local/lib
(as db4)... yes
If everyone is happy, I'll commit the patch and re-roll a 14.4
tarball. Just give the word.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Blair Zajac <bl...@orcaware.com>.
Branko ?ibej wrote:
>
> Philip Martin wrote:
>
> >Blair Zajac <bl...@orcaware.com> writes:
> >
> >>Change
> >>
> >>+ $SVN_FS_WANT_DB_PATCH, "db4 db")
> >>
> >>
> >
> >This doesn't work.
> >
> >>to
> >>
> >>+ $SVN_FS_WANT_DB_PATCH, [db4 db])
> >>
> >>
> >
> >This works for me.
> >
> Cool. The updated patch is attached.
This patch worked for me. I've built and passed a complete make test with
Berkeley DB 4.1 on RedHat 8.0.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Blair Zajac <bl...@orcaware.com> writes:
>
>>Change
>>
>>+ $SVN_FS_WANT_DB_PATCH, "db4 db")
>>
>>
>
>This doesn't work.
>
>>to
>>
>>+ $SVN_FS_WANT_DB_PATCH, [db4 db])
>>
>>
>
>This works for me.
>
Cool. The updated patch is attached.
>>Also, I'm on RedHat 8 and installed a vanilla DB 4.1.24 and it installs
>>db into libdb-4.1, which isn't found by default.
>>
>>How about changing this to
>>
>>+ $SVN_FS_WANT_DB_PATCH, [db-4.1 db-4.0 db-4 db4 db])
>>
>>
>
>Hmm, I have BDB 4.1 installed from a tarball and I don't find that
>necessary. I have
>
>$ ls /usr/local/db4/lib
>libdb-4.1.a libdb-4.1.la libdb-4.1.so libdb-4.so libdb.a libdb.so
>
>and when I run configure (using $SVN_FS_WANT_DB_PATCH, [db4 db]) I get
>
>$ ./config.nice
>[snip]
>checking for Berkeley DB in /usr/local/db4 (as db4)... no
>checking for Berkeley DB in /usr/local/db4 (as db)... yes
>
In that case, I strongly recommend against searching for db-4.1 and
db-4.0 explicitly. Presumably, if both are on the system, they'll be
installed in different paths. We already have a mechanism for dealing
with that, and the soname thing should handle potential runtime linking
problems.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Subversion 0.14.4 released
Posted by Philip Martin <ph...@codematters.co.uk>.
Blair Zajac <bl...@orcaware.com> writes:
> Change
>
> + $SVN_FS_WANT_DB_PATCH, "db4 db")
This doesn't work.
>
> to
>
> + $SVN_FS_WANT_DB_PATCH, [db4 db])
This works for me.
>
> Also, I'm on RedHat 8 and installed a vanilla DB 4.1.24 and it installs
> db into libdb-4.1, which isn't found by default.
>
> How about changing this to
>
> + $SVN_FS_WANT_DB_PATCH, [db-4.1 db-4.0 db-4 db4 db])
Hmm, I have BDB 4.1 installed from a tarball and I don't find that
necessary. I have
$ ls /usr/local/db4/lib
libdb-4.1.a libdb-4.1.la libdb-4.1.so libdb-4.so libdb.a libdb.so
and when I run configure (using $SVN_FS_WANT_DB_PATCH, [db4 db]) I get
$ ./config.nice
[snip]
checking for Berkeley DB in /usr/local/db4 (as db4)... no
checking for Berkeley DB in /usr/local/db4 (as db)... yes
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Branko Čibej <br...@xbc.nu>.
Blair Zajac wrote:
>Branko ?ibej wrote:
>
>
>>Philip Martin wrote:
>>
>>
>>
>>>The top of ac-helpers/berkeley-db.m4 sets status to "required", then
>>>when the test fails the following code in ac-helpers/berkeley-db is
>>>run
>>>
>>> case "$found" in
>>> "not" )
>>> if test "$status" = "required"; then
>>> AC_MSG_ERROR([Could not find Berkeley DB $1.$2.$3. with libname $4])
>>> fi
>>> svn_lib_berkeley_db=no
>>> ;;
>>>
>>>
>>>I think AC_MSG_ERROR must be fatal, I don't know much about autoconf,
>>>but if I put an echo immediately after the AC_MSG_ERROR its output
>>>doesn't appear.
>>>
>>>
>>>
>>Yes, of course it's fatal.
>>
>>
>>
>>>So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
>>>people. Perhaps we should pull the 0.14.4 tarball?
>>>
>>>
>>>
>>>
>>I agree absolutely. In the meantime, Ben, please try the attached patch.
>>It moves the logic for testing several lib names from configure.in to
>>SVN_LIB_BERKELEY_DB in ac-helpers/berkeley-db.m4.
>>
>>
>>
>
>There's an expansion issue with the patch with the $4 in the macro.
>It's passing "db4 db" as $4 and the
>
> for db_libname in $4; do
>
>ends up as
>
> for db_libname in "db4 db"; do
>
>which of course doesn't separate the library names and you end up with
>this:
>
>checking for Berkeley DB in /opt/i386-linux/db-4.1 (as db4 db)... no
>
>Change
>
>+ $SVN_FS_WANT_DB_PATCH, "db4 db")
>
>to
>
>+ $SVN_FS_WANT_DB_PATCH, [db4 db])
>
Ah... that's what comes from mixing m4 and shell. Thanks, this change is
correct.
>Also, I'm on RedHat 8 and installed a vanilla DB 4.1.24 and it installs
>db into libdb-4.1, which isn't found by default.
>
>How about changing this to
>
>+ $SVN_FS_WANT_DB_PATCH, [db-4.1 db-4.0 db-4 db4 db])
>
We're still not recommending 4.1 for general use, because we haven't
tested it enough. We should at least search for db-4.0 before db-4.1,
then you can scratch your particular itch by using
--with-berkeley-db=/opt/i386-linux/db-4.1.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Blair Zajac <bl...@orcaware.com>.
Branko ?ibej wrote:
>
> Philip Martin wrote:
>
> >The top of ac-helpers/berkeley-db.m4 sets status to "required", then
> >when the test fails the following code in ac-helpers/berkeley-db is
> >run
> >
> > case "$found" in
> > "not" )
> > if test "$status" = "required"; then
> > AC_MSG_ERROR([Could not find Berkeley DB $1.$2.$3. with libname $4])
> > fi
> > svn_lib_berkeley_db=no
> > ;;
> >
> >
> >I think AC_MSG_ERROR must be fatal, I don't know much about autoconf,
> >but if I put an echo immediately after the AC_MSG_ERROR its output
> >doesn't appear.
> >
> Yes, of course it's fatal.
>
> >So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
> >people. Perhaps we should pull the 0.14.4 tarball?
> >
> >
> I agree absolutely. In the meantime, Ben, please try the attached patch.
> It moves the logic for testing several lib names from configure.in to
> SVN_LIB_BERKELEY_DB in ac-helpers/berkeley-db.m4.
>
There's an expansion issue with the patch with the $4 in the macro.
It's passing "db4 db" as $4 and the
for db_libname in $4; do
ends up as
for db_libname in "db4 db"; do
which of course doesn't separate the library names and you end up with
this:
checking for Berkeley DB in /opt/i386-linux/db-4.1 (as db4 db)... no
Change
+ $SVN_FS_WANT_DB_PATCH, "db4 db")
to
+ $SVN_FS_WANT_DB_PATCH, [db4 db])
Also, I'm on RedHat 8 and installed a vanilla DB 4.1.24 and it installs
db into libdb-4.1, which isn't found by default.
How about changing this to
+ $SVN_FS_WANT_DB_PATCH, [db-4.1 db-4.0 db-4 db4 db])
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
>
> Branko Äibej <br...@xbc.nu> writes:
>
> > Branko Äibej wrote:
> >
> > >Philip Martin wrote:
> > >
> > >
> > >>So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
> > >>people. Perhaps we should pull the 0.14.4 tarball?
> > >>
> > >I agree absolutely. In the meantime, Ben, please try the attached patch.
> > >It moves the logic for testing several lib names from configure.in to
> > >SVN_LIB_BERKELEY_DB in ac-helpers/berkeley-db.m4.
> > >
> > I just noticed right now on svn-breakage that the build is indeed broken
> > on platforms that _don't_ use -ldb4. This is a showstopper. Please let's
> > recall 0.14.4 until this is resolved.
>
> Dangit, what the heck?!
>
> Karl *tested* my berkeley-db.m4 changes on his redhat box before I
> committed. He's has BDB 4.0 installed /usr/local/BerkeleyDB.4.0/. I
> watched him run ./autogen.sh; ./configure, and saw four -ldb4 checks
> fail non-fatally, and then the third -ldb worked.
>
> How could this have happened? I still don't understand why the logic
> is failing. Maybe I'm distracted by the steam coming out of my
> ears. :-(
Which version of RedHat? I'm using 8.0 and couldn't force a link against
DB 4.1 easily until I uninstalled db4-devel.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Dangit, what the heck?!
>
> Karl *tested* my berkeley-db.m4 changes on his redhat box before I
> committed. He's has BDB 4.0 installed /usr/local/BerkeleyDB.4.0/. I
> watched him run ./autogen.sh; ./configure, and saw four -ldb4 checks
> fail non-fatally, and then the third -ldb worked.
"four -ldb4 checks"
I think that means you didn't use a --with-berkeley-db=/some/path, the
logic is different in that case.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Branko Čibej wrote:
>
> >Philip Martin wrote:
> >
> >
> >>So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
> >>people. Perhaps we should pull the 0.14.4 tarball?
> >>
> >I agree absolutely. In the meantime, Ben, please try the attached patch.
> >It moves the logic for testing several lib names from configure.in to
> >SVN_LIB_BERKELEY_DB in ac-helpers/berkeley-db.m4.
> >
> I just noticed right now on svn-breakage that the build is indeed broken
> on platforms that _don't_ use -ldb4. This is a showstopper. Please let's
> recall 0.14.4 until this is resolved.
Dangit, what the heck?!
Karl *tested* my berkeley-db.m4 changes on his redhat box before I
committed. He's has BDB 4.0 installed /usr/local/BerkeleyDB.4.0/. I
watched him run ./autogen.sh; ./configure, and saw four -ldb4 checks
fail non-fatally, and then the third -ldb worked.
How could this have happened? I still don't understand why the logic
is failing. Maybe I'm distracted by the steam coming out of my
ears. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
>Philip Martin wrote:
>
>
>>So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
>>people. Perhaps we should pull the 0.14.4 tarball?
>>
>I agree absolutely. In the meantime, Ben, please try the attached patch.
>It moves the logic for testing several lib names from configure.in to
>SVN_LIB_BERKELEY_DB in ac-helpers/berkeley-db.m4.
>
I just noticed right now on svn-breakage that the build is indeed broken
on platforms that _don't_ use -ldb4. This is a showstopper. Please let's
recall 0.14.4 until this is resolved.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>The top of ac-helpers/berkeley-db.m4 sets status to "required", then
>when the test fails the following code in ac-helpers/berkeley-db is
>run
>
> case "$found" in
> "not" )
> if test "$status" = "required"; then
> AC_MSG_ERROR([Could not find Berkeley DB $1.$2.$3. with libname $4])
> fi
> svn_lib_berkeley_db=no
> ;;
>
>
>I think AC_MSG_ERROR must be fatal, I don't know much about autoconf,
>but if I put an echo immediately after the AC_MSG_ERROR its output
>doesn't appear.
>
Yes, of course it's fatal.
>So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
>people. Perhaps we should pull the 0.14.4 tarball?
>
>
I agree absolutely. In the meantime, Ben, please try the attached patch.
It moves the logic for testing several lib names from configure.in to
SVN_LIB_BERKELEY_DB in ac-helpers/berkeley-db.m4.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Subversion 0.14.4 released
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > Karl Fogel <kf...@newton.ch.collab.net> writes:
> >
> > > * support Berkeley DB 4.0 *or* 4.1
> >
> > Unfortunately, I think rev 3550 broke BDB 4.1, I get
> >
> > $ ./config.nice
> > [snip]
> > checking for Berkeley DB in /usr/local/db4 (as db4)... no
> > configure: error: Could not find Berkeley DB 4.0.14. with libname "db4"
> > $ ls /usr/local/db4/lib
> > libdb-4.1.a libdb-4.1.la libdb-4.1.so libdb-4.so libdb.a libdb.so
>
> I'm not sure what the problem is. I added this snippet to
> configure.in:
>
> # Look for libdb4.so first:
> SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
> $SVN_FS_WANT_DB_PATCH, "db4")
> if test "$svn_lib_berkeley_db" = "no"; then
> # ...try libdb.so otherwise.
> SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
> $SVN_FS_WANT_DB_PATCH, "db")
> fi
>
>
> I tested this patch on Karl's machine before committing; it simply
> tried to find -ldb4 in 4 locations, and then attempted to find -ldb in
> the same 4 locations, one of which matched.
>
> Why is your ./configure script simply bombing out after the first
> failure?
The top of ac-helpers/berkeley-db.m4 sets status to "required", then
when the test fails the following code in ac-helpers/berkeley-db is
run
case "$found" in
"not" )
if test "$status" = "required"; then
AC_MSG_ERROR([Could not find Berkeley DB $1.$2.$3. with libname $4])
fi
svn_lib_berkeley_db=no
;;
I think AC_MSG_ERROR must be fatal, I don't know much about autoconf,
but if I put an echo immediately after the AC_MSG_ERROR its output
doesn't appear.
So I think it affects BDB 4.0 as well as 4.1, this will affect lots of
people. Perhaps we should pull the 0.14.4 tarball?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > * support Berkeley DB 4.0 *or* 4.1
>
> Unfortunately, I think rev 3550 broke BDB 4.1, I get
>
> $ ./config.nice
> [snip]
> checking for Berkeley DB in /usr/local/db4 (as db4)... no
> configure: error: Could not find Berkeley DB 4.0.14. with libname "db4"
> $ ls /usr/local/db4/lib
> libdb-4.1.a libdb-4.1.la libdb-4.1.so libdb-4.so libdb.a libdb.so
I'm not sure what the problem is. I added this snippet to
configure.in:
# Look for libdb4.so first:
SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
$SVN_FS_WANT_DB_PATCH, "db4")
if test "$svn_lib_berkeley_db" = "no"; then
# ...try libdb.so otherwise.
SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
$SVN_FS_WANT_DB_PATCH, "db")
fi
I tested this patch on Karl's machine before committing; it simply
tried to find -ldb4 in 4 locations, and then attempted to find -ldb in
the same 4 locations, one of which matched.
Why is your ./configure script simply bombing out after the first
failure?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 0.14.4 released
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> * support Berkeley DB 4.0 *or* 4.1
Unfortunately, I think rev 3550 broke BDB 4.1, I get
$ ./config.nice
[snip]
checking for Berkeley DB in /usr/local/db4 (as db4)... no
configure: error: Could not find Berkeley DB 4.0.14. with libname "db4"
$ ls /usr/local/db4/lib
libdb-4.1.a libdb-4.1.la libdb-4.1.so libdb-4.so libdb.a libdb.so
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org