Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote:
> http://www.cvsnt.org/archive
> It's linked in http://www.cvsnt.org/wiki/Download, which could probably
> be better advertised but is linked from the main wiki page.
Now that you say it... :) The way to get there goes through a link to a
"Development download page" (I wasn't looking for a development download)
and there it is located in the topic "Current versions". It could be better
advertised...
> There are release notes in every stable release. The history is kept
> largely up to date (http://paris.nodomain.org/blog/index.php/history at
> the moment... linked from the old wiki HistoryPage) but I don't do it
> for every interim release.
Now that you say it... :) There's no link to either the history page nor
the blog from the Wiki main page or any of the download pages, at least not
that I could find it. I could have found it searching the wiki for
"history", but I guess I thought (not really very consciously) if something
like this existed, there would be a link from the main page or the download
pages.
Why is all that information so scattered around, so badly linked? You have
the wiki already, can't you just put the history info there?
I personally find the blog format not very suitable. It has some nice
features, like the categories, but when I for example select the "Stable"
category, I do get the stable releases, but I think I don't get their
change history from one stable release to the next. (This supposedly would
be the addition of all incremental development builds between the two.) Or
do you compile this information into the change logs for the releases in
the "Stable" category? If so, this again is
> That'll be in the release notes, unless you're after more?
No, I'm not after more, I just didn't find it. It's fairly well hidden :)
> Glen's idea sounds useful if I can find a good implementation of it.
Maybe a wiki page "Release Information", linked from the main wiki page,
that contains links to the pages with the collected release information?
One page per stable release. You collect the things you do in a page
"Current Development" (like you are doing in the blog) and once that
becomes a stable release, you rename the page to "Release 2.1.15" or
whatever? And add a link to the release files to it?
>> But when the svn guys put out a stable version, they publish a list with
>> everything that has been changed in that version WRT the last stable
>> version.
> Sounds like a changelog... they're not that useful unless you are a
> developer normally. Comments may make sense when I commit, but don't
> always when I read them back a few days later...
Not really. It doesn't seem that different from what you have, it's just
collected in an IMO useful and immediately obvious way. See below (end of
message) for an example. They have a mailing list exclusively for release
information like that.
> I try to be as transparent as possible - for example I avoid private
> email conversations... everything happens on the list, good or bad. The
> checkins (including my somtimes frustrated comments) are all published
> as they happen.
Yes, I know, and that's really great. But my difficulties to get to any
structured information (this list is not really well structured) made me
feel like walking in the dark.
> They subsequently posted that 2.5.01 worked after all, and it was just a
> testing snafu.
I probably have missed that. I'd probably have a much easier time following
things like this in a bug database.
> 2.0.58d fixed this but had a problem with edit/watch and &. The fix was
> put in in November, which missed the release window for 58d, so it was
> in one of the 2.0.62 interim builds. The fix was pushed out
> individually to a couple of support customers but mosly people affected
> just went to the interim release (not that many people IIRC).
So there's no known problem with & (with or without watch/edit -- which I
also use) in any of the releases post 2.0.62?
> I'm sorry if you fell it's not transparent - that's one of the things I
> try to get right and I've obviously failed in your case.
Thanks a lot for going through this with me. I really appreciate your
patience here, and I hope that this conversation or the results of it may
help others also.
> The changelog has every commit since 2003. Something in a better format
> would be useful (the cvsnt-commits newsgroup isn't a lot better,
> readability wise).
>
> Something like a web page saying:
>
> Todo
> <list of tasks, est. time and/or release number>
> Finished
> <list of tasks, release number>
>
> Haven't seen anything like that that wasn't integrated with a huge
> framework though - I prefer simplicity.
It seems the wiki wouldn't be too bad for a simple list like that. Add to
my suggestion above a page with the todos, from where you move them to the
Current Development page once they're done.
Thanks,
Gerhard
-------------------------------------------------------------------
Attached: Release info email from Subversion
The third release candidate of Subversion 1.2.0 is ready and available
from:
http://subversion.tigris.org/downloads/subversion-1.2.0-rc3.tar.gz
http://subversion.tigris.org/downloads/subversion-1.2.0-rc3.tar.bz2
http://subversion.tigris.org/downloads/subversion-1.2.0-rc3.zip
The MD5 checksums are:
...
The SHA1 checksums are:
...
PGP Signatures are available at:
...
For this release, the following people have provided PGP signatures:
...
The term 'release candidate' means the Subversion developers feel that
this release is stable and ready for production use, so we encourage
people to test this release thoroughly. We believe rc3 is the last
release candidate and that this release will be released as 1.2.0
final in approximately one week.
The changes between 1.2.0-rc2 and 1.2.0-rc3 are listed below.
New 1.2 features are explained in detail in our release notes,
located at:
http://subversion.tigris.org/svn_1.2_releasenotes.html
You can find the list of the changes between 1.1.4 and the 1.2.0-rc3 at:
http://svn.collab.net/repos/svn/branches/1.2.x/CHANGES
Questions, comments, and bug reports to users_at_subversion.tigris.org.
Thanks,
-The Subversion Team
--------------------8-<-------cut-here---------8-<-----------------------
User-visible-changes:
- Client:
* fixed: 'svn commit' over ra_svn not unlocking grandchildren
(issue #2288)
* fixed: 'svn commit' over ra_dav fails on locked propchanges
(r14612, -14)
...
* update bash-completion script (r14479)
* continued improvement of localized message translations
- Server:
* fixed: possible lock-date overflows (r14482)
* fixed: clear leaked error objects (r14475, r14592)
- Both:
* fixed: 'svn info URL' shows incorrect lock owner over ra_dav
(r14493, -95)
* fixed: ra_local crashes with --enable-dso (r14174, 14177, 14509)
Developer-visible changes:
* fixed: javahl returning incorrect lockCreationDate (r14454)
* comment & API tweaks (r14583)
...
* redhat RPM build changes:
- packages renamed and more platforms detected (r14414-17, r14429)
- re-enable BDB builds for rhel4 RPM (r14431)
- do explicit BDB and FSFS tests (r14536)