You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/03/12 20:40:11 UTC
Subversion 1.0.1 released.
Subversion 1.0.1 is ready. Grab it from:
http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.gz
http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.bz2
The MD5 checksums are:
80c5980c3402c160b9d62c7b4a288599 subversion-1.0.1.tar.gz
50ca608d260b76d99ed85909acb7ae92 subversion-1.0.1.tar.bz2
This is a bugfix release following 1.0.0. Note that it includes fixes
for bugs discovered during the six-week code freeze that led up to
1.0.0. None of these bugs were severe enough to hold up 1.0.0, so we
decided to put their fixes in 1.0.1.
In other words, don't read over the changes list and think "Wow, they
discovered all those bugs in just the three weeks since 1.0.0!"
That's not what happened :-). We knew about them well before 1.0.0,
but chose to test the fixes a bit longer before shipping. If you're
running 1.0.0, we recommend you upgrade to 1.0.1.
Questions, comments, and bug reports to users@subversion.tigris.org.
Thanks,
-The Subversion Team
--------------------8-<-------cut-here---------8-<-----------------------
Changes between 1.0.0 and 1.0.1:
User-visible changes:
* allow anonymous access checking in mod_authz_svn
* fixed: mod_authz_svn now works with SVNParentPath (issue #1588)
* fixed: potential segfault in mod_dav_svn.
* fixed: improper BDB cursor shutdown in libsvn_fs, which can wedge repos.
* fixed: allow checkout of repository with space in path. (issue #1694)
* fixed: make 'svn propget URL' work correctly over svn://. (issue #1752)
* fixed: failed 'svn merge URL' when URL contains user@host. (issue #1759)
* fixed: invalid REPORT response when updating a deleted wc. (issue #1721)
* fixed: allow deletes below copied wc dirs.
* fixed: merge --dry-run bug on added-files with props. (issue #1738)
* fixed: svnlook no longer requires write access to '.'
* fixed: ensure 'svn blame' fails on files marked as binary. (issue #1733)
* fixed: make failed direct-URL commits clean up their fs txns. (issue #1726)
* fixed: obscure bugs in time/date string formatting. (issue #1692)
* fixed: svn export doesn't export svn:externals. (issue #1750)
* fixed: svn import doesn't handle EOL or keyword translation. (issue #1756)
* fixed: svn status -v shows unwanted status of externals (issue #1741)
* fixed: allow revert of schedule-replace file that has no props (issue #1775)
* fixed: svnserve segfault on invalid --listen-host argument.
* fixed: switch bug which caused wrong URL to be left in wc.
* detect invalid UTF8 filenames when native locale is UTF8.
* improve presentation of directory property conflicts.
* improve presentation of errors from svnadmin & svnlook.
* clarify output of 'svnadmin help deltify'.
* augment copyright notice to --version output.
* more book updates.
Developer-visible changes:
* remove obsolete auth provider examples.
* prevent potential ra_dav commit race-condition.
* fix svn_io_dir_walk 'dot-first' ordering required by 'svnadmin hotcopy'.
* fix error leaks in dav_svn_convert_err()
* upgrade win32 innosettup tools and redhat RPMs.
* fix compile warning: compressed streams on LP64 architecture.
* use cpio to generate tarballs instead of GNU tar.
* tweaks to dist.sh.
* fix bindings on win32.
* fix perl bindings build on OS X.
* fix perl bindings: bug which rejects string revnums.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Branko Cibej <br...@xbc.nu>.
Quoting "Jostein Chr. Andersen" <jo...@josander.net>:
> On Tuesday 16 March 2004 15.09, Branko Cibej wrote:
>
> > I stand corrected.
>
> Oops, I hope I haven't said anything to hurt you. If so, then I
> pologise.
Not at all! :-)
I should've said: "Thank you for correcting my mistake."
Serves me right for ignoring the ambiguity.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Tuesday 16 March 2004 15.09, Branko Cibej wrote:
> I stand corrected.
Oops, I hope I haven't said anything to hurt you. If so, then I pologise.
The term "stand corrected" can be understood as I try to put you in place
in my wordbook. I did not think about that at all.
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Branko Cibej <br...@xbc.nu>.
Quoting "Jostein Chr. Andersen" <jo...@josander.net>:
> On Tuesday 16 March 2004 03.27, D.J. Heap wrote:
> > Branko Cibej wrote:
> > > Quoting Sander Striker <st...@apache.org>:
> >
> > [snip]
> >
> > >>Do you normally build with VC6 or VC7? Anything else I should be
> > >> aware of?
> > >
> > > VC6, but it really shouldn't matter. The directory structure
> > > in the zip files doesn't "just happen"; I think I could send
> > > you the dist script I use tomorrow.
> > >
> > >
> > > -- Brane
> >
> > The C runtime libraries will be different (msvcrt.dll vs msvcrt71.dll)
> > which would affect the installer, at least, wouldn't it? Unless it is
> > already smart enough to handle that.
>
> The installer checks if msvcp60.dll is present. If not, then the
> installer offers to download it and install it during the installation.
I stand corrected.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Tuesday 16 March 2004 03.27, D.J. Heap wrote:
> Branko Cibej wrote:
> > Quoting Sander Striker <st...@apache.org>:
>
> [snip]
>
> >>Do you normally build with VC6 or VC7? Anything else I should be
> >> aware of?
> >
> > VC6, but it really shouldn't matter. The directory structure
> > in the zip files doesn't "just happen"; I think I could send
> > you the dist script I use tomorrow.
> >
> >
> > -- Brane
>
> The C runtime libraries will be different (msvcrt.dll vs msvcrt71.dll)
> which would affect the installer, at least, wouldn't it? Unless it is
> already smart enough to handle that.
The installer checks if msvcp60.dll is present. If not, then the
installer offers to download it and install it during the installation.
If the user do not want to do that, then a menu item for downloading the
msvcp60.dll are created. This means that the user can continue the
installation but must download the dll if (s)he wants to use Subversion.
So, it would be nice if the maker of the binaries can compile with VC6
and not VC7 :-)
Jostein
--
http://www.josander.net/kontakt/ ||
http://www.josander.net/en/contact/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Branko,
Branko Cibej wrote:
>Quoting Sander Striker <st...@apache.org>:
>
>
>
>>I could, but not until late this w-e.
>>
>>
I have everything already build but the python binding for building the
javahl bindings. The python bindings should not pose a problem.
>
>Thanks!
>
>
>
>>Do you normally build with VC6 or VC7? Anything else I should be aware
>>of?
>>
>>
>
>VC6, but it really shouldn't matter. The directory structure
>in the zip files doesn't "just happen"; I think I could send
>you the dist script I use tomorrow.
>
>
If you send me the script today, I think I will have the distribution
ready by tonight.
>
>-- Brane
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Branko Cibej <br...@xbc.nu>.
Quoting "D.J. Heap" <dj...@shadyvale.net>:
> Branko Cibej wrote:
> > Quoting Sander Striker <st...@apache.org>:
> [snip]
> >
> >>Do you normally build with VC6 or VC7? Anything else I should be
> aware
> >>of?
> >
> >
> > VC6, but it really shouldn't matter. The directory structure
> > in the zip files doesn't "just happen"; I think I could send
> > you the dist script I use tomorrow.
> >
> >
> > -- Brane
> >
>
> The C runtime libraries will be different (msvcrt.dll vs msvcrt71.dll)
> which would affect the installer, at least, wouldn't it? Unless it is
> already smart enough to handle that.
>
> DJ
We don't install the runtimes, they should already be installed on the system
(and if not, they're available from MS).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Ben Reser <be...@reser.org>.
On Tue, Mar 16, 2004 at 09:22:22AM -0500, Greg Hudson wrote:
> I didn't review the patch carefully, but this jumped out at me:
>
> + char buf[strlen(svnroot)+strlen(local_dir)+1];
> + sprintf(buf, "%s/%s", svnroot, local_dir);
>
> You've made use of a gcc extension here; in regular old C, arrays must
> have constant length. Use apr_psprintf() instead.
Actually that's in C99 now. But we're using C89 as our target so we
shouldn't use such things as you pointed out.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> So, I don't really agree with this feature, but here is some advice on
> presenting patches in this community:
[...]
Tom, since I haven't noticed your name here before, I thought I ought to say that Greg is only being helpful here. Please don't be put off by the batch of comments. All patches are reviewed very carefully and critically. If you would like to read the file "HACKING" in the root of the source tree, and fix all of those points, and then re-submit your patch with "[PATCH]" at the beginning of the Subject line, it will be better received.
Also, please see if there is a corresponding issue in the issue tracker (http://subversion.tigris.org/servlets/ProjectIssues) and, if so, mention its number in the log message and the Subject line.
Note that Greg's comment "I don't really agree with this feature" might turn out to be shared by a majority of Subversion developers; we will have to see what reasons are given for and against it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
>
> + char buf[strlen(svnroot)+strlen(local_dir)+1];
> + sprintf(buf, "%s/%s", svnroot, local_dir);
>
> You've made use of a gcc extension here; in regular old C, arrays must
> have constant length. Use apr_psprintf() instead.
And the length allocated was one byte too short.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Greg Hudson <gh...@MIT.EDU>.
So, I don't really agree with this feature, but here is some advice on
presenting patches in this community:
* To post a message to this list, don't respond to an existing message
and change the subject, as convenient as that may be. That leaves
behind references headers which (in some people's mail-readers) will
mis-thread your message.
* Don't tar up the patch and log message and send it as an
attachment. Either send one text attachment with the log message and
one with the patch, or send a single text attachment with both.
(Inlining the patch as plain text is also okay if your MUA won't mangle
it.)
* Your log message does not conform to the standards in HACKING, even
a little bit. (It's just a two-line description of the change; no
description of how it modifies symbols in the source code.)
* Give more information in the message body about what your patch does
to the command-line syntax, so we don't have to read the source patch to
figure out what you're trying to do.
* By hook or by crook, do not send patches which include unrelated
whitespace changes. I suggest turning off ws-trim in xemacs when
working on other people's code, but "svn diff --diff-cmd=diff -x -uw"
might also work for you.
* We don't really make much use of #if 0'd debugging code, so don't
include that in your patches.
I didn't review the patch carefully, but this jumped out at me:
+ char buf[strlen(svnroot)+strlen(local_dir)+1];
+ sprintf(buf, "%s/%s", svnroot, local_dir);
You've made use of a gcc extension here; in regular old C, arrays must
have constant length. Use apr_psprintf() instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Brian Denny <br...@briandenny.net>.
Nuutti,
That's a great answer to my concern.
I hope all prospective patch-submitters read your post.
:) brian
On Wed, Mar 17, 2004 at 05:49:19AM +0200, Nuutti Kotivuori wrote:
>
> I believe there's a bit of oranges and apples here - and definitely
> the "submit a patch" is a confusing comment and your woes are rightly
> placed here. I believe HACKING might require some clarification.
>
> The difference comes in the nature of the discussion.
>
> When some issue is discussed in the mailing list in general terms, the
> answers that contain the message "This is *so* low on my priority list
> that I don't even want to discuss it right now." are sometimes given
> with the comment "submit a patch".
>
> The proper response to that is "I am willing to code this feature by
> the guidelines in HACKING and iterate the patch into Subversion, and
> this is my proposed design, please give feedback on it."
>
> And I can guarantee people will discuss it then - if nothing else,
> then putting into words their reasons why it shouldn't be done - and
> possibly voting on it if it comes to that.
>
> So the actual message is not ever "if you come back with a patch,
> maybe I'll consider spending my time on it" - but it is "show your
> willingness to actually work this problem through its iterations, and
> I'll spend time commenting it."
>
> So, on the actual matter - SVNROOT patch - I think the first step
> would be to post a detailed proposal on how to handle the interface
> and get that approved.
>
> -- Naked
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Nuutti Kotivuori <na...@iki.fi>.
Brian Denny wrote:
> On Tue, Mar 16, 2004 at 11:51:38PM +0200, Nuutti Kotivuori wrote:
>>
>> And unless the extent of the functionality was already discussed
>> (like I assume it wasn't from the patch), I strongly would urge you
>> to discuss the actual semantics of SVNROOT on the list first, get a
>> consensus on what would be sane behaviour, and hopefully start
>> coding after you've got a green light that this indeed is a wanted
>> change.
>
> I want to make a remark about this.
>
> I have observed a number of times on this list that a user comes to
> the list with a feature request, and they get a response something
> like "I don't really think this feature is worth the effort, but
> you're welcome to submit a patch".
>
> Which, if said before the actual semantics have been worked-out on
> list, may encourage the sort of "code-first, ask questions later"
> pattern that you (Nuutti) are trying above to discourage.
>
> Furthermore, I fear a kind of subtext-misunderstanding. "You're
> welcome to submit a patch" sounds like encouragement, but I feel
> like sometimes people say this when what they really mean is "This
> is *so* low on my priority list that I don't even want to discuss it
> right now. If you come back with a patch, maybe I'll consider
> spending my time on it." -- Which is a perfectly valid attitude,
> but I just hope the potential patch submitter is hearing the right
> message.
>
> I'm not necessarily saying that either of the above comments applies
> to this particular case.
I believe there's a bit of oranges and apples here - and definitely
the "submit a patch" is a confusing comment and your woes are rightly
placed here. I believe HACKING might require some clarification.
The difference comes in the nature of the discussion.
When some issue is discussed in the mailing list in general terms, the
answers that contain the message "This is *so* low on my priority list
that I don't even want to discuss it right now." are sometimes given
with the comment "submit a patch".
The proper response to that is "I am willing to code this feature by
the guidelines in HACKING and iterate the patch into Subversion, and
this is my proposed design, please give feedback on it."
And I can guarantee people will discuss it then - if nothing else,
then putting into words their reasons why it shouldn't be done - and
possibly voting on it if it comes to that.
So the actual message is not ever "if you come back with a patch,
maybe I'll consider spending my time on it" - but it is "show your
willingness to actually work this problem through its iterations, and
I'll spend time commenting it."
So, on the actual matter - SVNROOT patch - I think the first step
would be to post a detailed proposal on how to handle the interface
and get that approved.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Brian Denny <br...@briandenny.net>.
On Tue, Mar 16, 2004 at 11:51:38PM +0200, Nuutti Kotivuori wrote:
>
> And unless the extent of the functionality was already discussed (like
> I assume it wasn't from the patch), I strongly would urge you to
> discuss the actual semantics of SVNROOT on the list first, get a
> consensus on what would be sane behaviour, and hopefully start coding
> after you've got a green light that this indeed is a wanted change.
I want to make a remark about this.
I have observed a number of times on this list that a user comes to
the list with a feature request, and they get a response something
like "I don't really think this feature is worth the effort, but you're
welcome to submit a patch".
Which, if said before the actual semantics have been worked-out on list,
may encourage the sort of "code-first, ask questions later" pattern that
you (Nuutti) are trying above to discourage.
Furthermore, I fear a kind of subtext-misunderstanding. "You're welcome
to submit a patch" sounds like encouragement, but I feel like sometimes
people say this when what they really mean is "This is *so* low on my
priority list that I don't even want to discuss it right now. If you
come back with a patch, maybe I'll consider spending my time on it."
-- Which is a perfectly valid attitude, but I just hope the potential
patch submitter is hearing the right message.
I'm not necessarily saying that either of the above comments applies to
this particular case.
-brian
(thinking much more about psychology than about code, lately)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Nuutti Kotivuori <na...@iki.fi>.
tbrowder@cox.net wrote:
> I previously asked about a feature like CVSROOT (to be called
> SVNROOT).
>
> I have attempted to add that feature and have attached proposed code
> changes in the form of diffs from the latest subversion tree.
I probably wasn't around for the earlier discussion on SVNROOT (but I
probably were for some previous incarnation of it in the past), but in
any case, it would be very good to explain the usage of the new
feature in the mail - and not just inside the patch in code comments.
And unless the extent of the functionality was already discussed (like
I assume it wasn't from the patch), I strongly would urge you to
discuss the actual semantics of SVNROOT on the list first, get a
consensus on what would be sane behaviour, and hopefully start coding
after you've got a green light that this indeed is a wanted change.
Right now, the patch changes only 'checkout' and 'import' to use
SVNROOT, and even there the use cases are a bit odd. If something like
this is implemented, it needs to be with a clean and consistent
interface.
Other comments on the patch (aside from the ones already said):
* There should be more description on the command-line help, and
descriptions on all changed commands.
* As by HACKING, you should not put your name in a comment.
* Consider using apr_psprintf instead of sprintf.
* Consider providing test cases for the new functionality.
Please do not be put off by the commentary received if you indeed are
serious about getting SVNROOT functionality into Subversion. Instead
let's work out the issues together so everyone will benefit.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Proposed New Feature (SVNROOT)
Posted by TBrowder <tb...@cox.net>.
I previously asked about a feature like CVSROOT (to be called SVNROOT).
I have attempted to add that feature and have attached proposed code changes
in the form of diffs from the latest subversion tree.
Tom Browder
P.S. Is there any way to get 'svn diff' to ignore changes in whitespace? I
use 'ws-trim' in my xemacs, and the pristine subversion files I modified all
have an extra space at line endings.
Re: Subversion 1.0.1 released.
Posted by Branko Cibej <br...@xbc.nu>.
Quoting Barry Scott <ba...@barrys-emacs.org>:
> If you wish to support python it has to be VC6 until Python 2.4 ships
> which will be built with VC71 (or better). Then the win32 subversion
> must be built with VC71 to support python.
>
> This is because its not supposed to be possible to share FILE objects
> between VC6 and VC71 runtimes.
Subversion doesn't use any FILE* objects in its public API, so that shouldn't be
a problem.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Barry Scott <ba...@barrys-emacs.org>.
If you wish to support python it has to be VC6 until Python 2.4 ships
which will be built with VC71 (or better). Then the win32 subversion
must be built with VC71 to support python.
This is because its not supposed to be possible to share FILE objects
between VC6 and VC71 runtimes.
Barry
At 16-03-2004 02:27, D.J. Heap wrote:
>Branko Cibej wrote:
>>Quoting Sander Striker <st...@apache.org>:
>[snip]
>>
>>>Do you normally build with VC6 or VC7? Anything else I should be aware
>>>of?
>>
>>VC6, but it really shouldn't matter. The directory structure
>>in the zip files doesn't "just happen"; I think I could send
>>you the dist script I use tomorrow.
>>
>>-- Brane
>
>The C runtime libraries will be different (msvcrt.dll vs msvcrt71.dll)
>which would affect the installer, at least, wouldn't it? Unless it is
>already smart enough to handle that.
>
>DJ
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Branko Cibej wrote:
> Quoting Sander Striker <st...@apache.org>:
[snip]
>
>>Do you normally build with VC6 or VC7? Anything else I should be aware
>>of?
>
>
> VC6, but it really shouldn't matter. The directory structure
> in the zip files doesn't "just happen"; I think I could send
> you the dist script I use tomorrow.
>
>
> -- Brane
>
The C runtime libraries will be different (msvcrt.dll vs msvcrt71.dll)
which would affect the installer, at least, wouldn't it? Unless it is
already smart enough to handle that.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Branko Cibej <br...@xbc.nu>.
Quoting Sander Striker <st...@apache.org>:
> I could, but not until late this w-e.
Thanks!
> Do you normally build with VC6 or VC7? Anything else I should be aware
> of?
VC6, but it really shouldn't matter. The directory structure
in the zip files doesn't "just happen"; I think I could send
you the dist script I use tomorrow.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Sander Striker <st...@apache.org>.
On Mon, 2004-03-15 at 21:52, Branko Cibej wrote:
> Quoting kfogel@collab.net:
>
> > Subversion 1.0.1 is ready.
>
> I won't be able to buuld Win32 binaries for this release anytime soon. Could
> someone else step in this time?
I could, but not until late this w-e.
Do you normally build with VC6 or VC7? Anything else I should be aware of?
Sander
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Branko Cibej <br...@xbc.nu>.
Quoting kfogel@collab.net:
> Subversion 1.0.1 is ready.
I won't be able to buuld Win32 binaries for this release anytime soon. Could
someone else step in this time?
Thanks,
-- Brane
P.S.: The next person to send me private mail about when these binaries will be
ready will end up at the top of my "Redirect-Spam-To:" list. :-\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Ben Reser <be...@reser.org>.
Mandrake packages of 1.0.1 have been availble for a few days on my site:
http://mirror.brain.org/linux/breser/mandrake
The source is urpmiable for setup instructions go to:
http://ben.reser.org/mandrake/breser/
The packages available there match the packages in cooker contrib which
should be available eventually but have to wait due to the freeze. The
cooker contrib packages are also the Mandrake 10.0 packages, so they are
blocked as well.
Packages are built for 9.1/ppc, 9.1/i586, 9.2/i586, and 9.2/amd64.
Any necessary dependencies not in Mandrake main or contrib for those
package are available in the same location.
Enjoy.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Ben Reser <be...@reser.org>.
Mandrake packages of 1.0.1 have been availble for a few days on my site:
http://mirror.brain.org/linux/breser/mandrake
The source is urpmiable for setup instructions go to:
http://ben.reser.org/mandrake/breser/
The packages available there match the packages in cooker contrib which
should be available eventually but have to wait due to the freeze. The
cooker contrib packages are also the Mandrake 10.0 packages, so they are
blocked as well.
Packages are built for 9.1/ppc, 9.1/i586, 9.2/i586, and 9.2/amd64.
Any necessary dependencies not in Mandrake main or contrib for those
package are available in the same location.
Enjoy.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.0.1 released.
Posted by Benoit des Ligneris <be...@revolutionlinux.com>.
Hello,
Did a "firewall" mistake ;-)
The urpmi source is in fact the following :
urpmi.addmedia --update subversion https://compta.revolutionlinux.com/subversion/
Then you can "urpmize" subversion, subversion-client, etc.
Ben
* Benoit des Ligneris <be...@revolutionlinux.com> [04-03-14 19:02]:
> Hello,
>
> I did some packages for Mandrake 10.0 and 9.2
>
> You can grab them there :
> https://compta.revolutionlinux.com/subversion/
>
> The src.rpm is there :
> https://compta.revolutionlinux.com/subversion/src/subversion-1.0.1-1mdk.src.rpm
>
> If you want a subversion urpmi source, here you are :
> urpmi.addmedia --update subversion \
> https://cvs.revolutionlinux.com/subversion/
>
> Ben
> * Marcin Gil <mg...@vernet.pl> [04-03-14 07:24]:
> > kfogel@collab.net wrote:
> > > Subversion 1.0.1 is ready. Grab it from:
> > >
> > > http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.gz
> > > http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.bz2
> > >
> > > The MD5 checksums are:
> > >
> > > 80c5980c3402c160b9d62c7b4a288599 subversion-1.0.1.tar.gz
> > > 50ca608d260b76d99ed85909acb7ae92 subversion-1.0.1.tar.bz2
> > >
> > Custom Slackware package (9.1) for AthlonXP here:
> > http://marcin.gilusiowy.net/files/subversion-1.0.1-athlon_xp-1.tgz
> >
> > --
> > Marcin Gil
> > email# mgil : vernet pl | GaduGadu ID# 185057
> > JID# dentharg : chrome pl | http://marcin.gilusiowy.net
>
>
>
> --
> Benoit des Ligneris Ph. D.
> President de Revolution Linux http://www.revolutionlinux.com/
> OSCAR Chair http://oscar.openclustergroup.org/
> Chef de projet EduLinux http://www.edulinux.org/
--
Benoit des Ligneris Ph. D.
President de Revolution Linux http://www.revolutionlinux.com/
OSCAR Chair http://oscar.openclustergroup.org/
Chef de projet EduLinux http://www.edulinux.org/
Re: Subversion 1.0.1 released.
Posted by Benoit des Ligneris <be...@revolutionlinux.com>.
Hello,
I did some packages for Mandrake 10.0 and 9.2
You can grab them there :
https://compta.revolutionlinux.com/subversion/
The src.rpm is there :
https://compta.revolutionlinux.com/subversion/src/subversion-1.0.1-1mdk.src.rpm
If you want a subversion urpmi source, here you are :
urpmi.addmedia --update subversion \
https://cvs.revolutionlinux.com/subversion/
Ben
* Marcin Gil <mg...@vernet.pl> [04-03-14 07:24]:
> kfogel@collab.net wrote:
> > Subversion 1.0.1 is ready. Grab it from:
> >
> > http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.gz
> > http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.bz2
> >
> > The MD5 checksums are:
> >
> > 80c5980c3402c160b9d62c7b4a288599 subversion-1.0.1.tar.gz
> > 50ca608d260b76d99ed85909acb7ae92 subversion-1.0.1.tar.bz2
> >
> Custom Slackware package (9.1) for AthlonXP here:
> http://marcin.gilusiowy.net/files/subversion-1.0.1-athlon_xp-1.tgz
>
> --
> Marcin Gil
> email# mgil : vernet pl | GaduGadu ID# 185057
> JID# dentharg : chrome pl | http://marcin.gilusiowy.net
--
Benoit des Ligneris Ph. D.
President de Revolution Linux http://www.revolutionlinux.com/
OSCAR Chair http://oscar.openclustergroup.org/
Chef de projet EduLinux http://www.edulinux.org/
Re: Subversion 1.0.1 released.
Posted by Marcin Gil <mg...@vernet.pl>.
kfogel@collab.net wrote:
> Subversion 1.0.1 is ready. Grab it from:
>
> http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.gz
> http://subversion.tigris.org/tarballs/subversion-1.0.1.tar.bz2
>
> The MD5 checksums are:
>
> 80c5980c3402c160b9d62c7b4a288599 subversion-1.0.1.tar.gz
> 50ca608d260b76d99ed85909acb7ae92 subversion-1.0.1.tar.bz2
>
Custom Slackware package (9.1) for AthlonXP here:
http://marcin.gilusiowy.net/files/subversion-1.0.1-athlon_xp-1.tgz
--
Marcin Gil
email# mgil : vernet pl | GaduGadu ID# 185057
JID# dentharg : chrome pl | http://marcin.gilusiowy.net