[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svk 0.21 Released

From: Chia-liang Kao <clkao_at_clkao.org>
Date: 2004-09-20 01:20:29 CEST

Hi all,

I'm pleased to announce svk 0.21, the second beta release of svk, and
the first release natively ported to Microsoft Windows.

Performance is also a highlight from this release; "svk checkout" for
large trees from local repositories is now 300% faster than "svn
checkout", and only 3% slower than "svn export"; the full change log
is available at the end of this message.

This release also marks the first anniversary of svk:

  r923@chopin: clkao | 2003-09-20T13:44:41.157170Z
  virgin import of svk

It has been a year, and I cannot quite believe that I have been
concentrating on the same thing for such a long time, with 20 releases
in the past year.

For this occasion, I considered writing a state of onion (or mushroom,
or whatever vegetable you like), but it will probably bore you; hence
I'd like to simply post an update of some of my plans for the next

As some of you may be aware, I promised myself an one-year sabbatical
for developing svk, and it is drawing to an end. Fortunately, I have
been kindly offered a job on open source software development, so I
can spend part of my working hours on svk. This is still pending some
administrative confirmation, but I think it is likely to happen, and
you can rest assured that svk will still be supported and actively
developed in the near future.

Currently I am targeting svk 1.0 around the end of this year, one year
after svk first started self hosting. Since the core of svk is now
quite stable, most of the issues are trivial UI and usability
improvements. Please join us on irc.freenode.net #svk if you'd like
helping out.

Also, I have implemented a prototype of svkup/svkupd in the "svkup"
branch; it is a proof-of-concept for a Perforce-like, thin-client
version control system, performing svk's advanced merge facilities on
the server side. Finishing up this facility will be one of the major
post-1.0 goals.

Some of you might have read the recent "distributed development"
thread on the svn-dev mailing list, where some have classified svk as
a kluge. Personally, I think svk's API layers are strategically and
carefully chosen, to maximize immediate usability and minimize code
duplication. All I can say is that svk is the most non-kludgy system
I have ever designed, although your mileage may vary. :-)

Truth to be told, svk's code is still undergoing refactoring, as it
can still make use of some cleaning up. However, with its nearly 90%
unit test coverage, refactoring is not a daunting task.

Some have complained the code does not contain enough comments, as
only the more complicated code blocks are commented. I have been
thinking about this myself; it is probably because English is not my
native language, such that I often understand code faster than
comments. This is my shortcoming, but patches are welcome and I will
be delighted to explain any chunk of the code to anyone who would like
to help document it.

Finally, I want to say "thank you" again to the people who have
contributed, sponsored, and/or complained enough to make svk happen.
Meanwhile, as a testament to its robust support for offline operation,
svk has been developed in some of the loveliest places in the world
over the past year, where there are not always with the best
connectivity: Pinglin, Taiwan; Hualien, Taiwan; Namur, Belgium;
Cologne, Germany; London, UK; Scotland, UK; Abisko, Sweden; Lofoten,

Many thanks to all the nice people in these places. I hope that you,
too, will use svk to hack interesting things offline. Not only during
a lunch break, but also in some beautiful places of your own.


[Changes for 0.21 - 20 Sep, 2004]

* svk now runs natively on win32. [Autrijus]

* New: svk ls -v. [Plasma]

* New: svk propget (pg). [Autrijus]

* Use D::H->store_fast. This makes checkout 5% faster.

* Ignore checksum in Editor::XD when they are alrady checked by
  Editor::Merge. This makes update and merge to copath 25-30% faster.

* SVNFSTYPE default to bdb with svn 1.0.x, otherwise fsfs.

* Authentication prompts are now handled. [Autrijus]

* For internal differ, Don't output diff for binary nodes. [Plasma]

* Use IO::Digest to get the md5 while reading the merged file, instead
  of reading it again.

* Add support to use SVKMERGE on win32, in particular
  p4winmrg, guiffy. [Autrijus]

* Error messages are now printed to STDERR.

* "svk sm --base" and "svk sm --baseless" now always do what
  they are documented to do, overriding existing merge
  tickets. [Autrijus]

* Prepend depot name before svk mi --list. [Autrijus]

* Fix delete_entry in diff editor for external diff tool.

* Delay SVN::Mirror loading. This makes startup time faster.

* Make SVK::Editor::Delay also delays open_file and discard no-op opens.
  This optimized the consumed bandwidth when committing/merging to

* Fix merge ticket parsing and generation for paths mirrored with vcp.

* Make describe work on current copath, otherwise fallback to '//'.
  [Ruslan U. Zakirov]

* Fix a scary but harmless message after committing copied nodes with
  messages from editor.

* Add expand_copy option to checkout_delta. This allows diff works
  correctly (in terms of what svn does) with copied checkout.

* Allow checking out a file with differet name.

* Eliminate repeating mimetype() calls. [Autrijus]

* Fix tests for File::MimeInfo not installed.

* full zh_tw and zh_cn translation. [Autrijus]

* Transaction errors are now reported nicely.

* Many checkout_delta cleanups.

* Many documentation improvement. [Autrijus]


  • application/pgp-signature attachment: stored
Received on Mon Sep 20 01:55:56 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.