[wpkg-announce] Announcement: WPKG 1.1.0 release

[Rainer Meier]

Hi Daniel,

Daniel Dehennin wrote:
> Tag is a way to identify a particular revision, for example:
> revision 74 tagged as 1.1.

As I wrote a tag is a logical label on a specific revision. In SVN there is a
counting number for each checkin which cleanly identifies the current state
after each commit.


> What will be the next diff? A complete checkin, or a diff to the
> previous development?

WPKG 1.2 will be a new check-in. As I plan to do some wider changes in WPKG most
of the code will be changed. In addition WPKG 1.1 will be supported in parallel.

Actually for WPKG project it does not matter a lot if I am going to branch WPKG
1.1 and create WPKG 1.2 or if I create a new WPKG 1.2 tree and check in a new
revision. After finishing development it will be moved to the stable tree as
well. In case WPKG 1.2 will completely replace 1.1 I will move 1.1 to the
end-of-life tree then. In case WPKG 1.1 will still need support (bugfixing) then
I will keep it in stable/.


> I'm not familiar with SVN, I personally track you SVN with bzr-svn, this
> permit to make some tests and commit locally (well, if I had some things
> to do ;-)).

OK. You're free to use any tool on the repository you like to - that's why I
keep it public.


> Don't you loose some history? (bzr-svn tell my I can not merge the 1.1
> into my local branch because there is not common ancestor).

It's true that I will lose the "common ancestor" for WPKG 1.2 if I am not going
to branch WPKG 1.1 but check in a new WPKG 1.2 version. Mabe at the beginning of
WPKG 1.1 development it could have been an advantage to merge 1.0 and 1.1 code -
but after a while the code was much different. I expect it to be even more
different in WPKG 1.2. So from my point of view it is undesirable to merge 1.1
and 1.2 code then. But remember it's still possible to do diffs between these
two files.

A branch would make sense in larger projects. For example if multiple developers
would work on WPKG 1.2 on different topics. Then I would create WPKG 1.2 main
and then create different branches for different projects. Then having the teams
to work on their implementation allowing to keep track of the changes in regards
to the initial WPKG 1.2 branch. However at the end of development all branches
would have to be re-merged to the main WPKG 1.2 branch.

In our case here there is no merging of multiple projects. WPKG 1.2 is not a
sub-project of WPKG 1.1 but it is a new development.

It's pointless to merge it with WPKG 1.1 because the first checkin of version
1.2 will most probably be much different to what we have in WPKG 1.1.


> I'm reading the SVN Book[1], it seems that tagging[2] and branching[3] is more
> common than moving.

As I wrote above. I think this is appropriate for larger projects _within_ a
specific version. But not if a new sub-project like a completely new version is
started.

However I admit that I mainly worked with CVS and CVS does not support moving of
files without losing the history. In SVN you can. So wpkg.js within
stable/1.1/wpkg.js now still contains the full history of the file which allows
it to be tracked back to the initial WPKG 1.1 checkin.

I also looked at some SVN books and some of them do not get the point of SVN at
all - SVN versioning different from the basic principle compared to CVS and lots
of books/articles use SVN the same way they were used to do it in CVS.


> One problem of moving, is that I can not do:
> --8<---------------cut here---------------start------------->8---
> svn log https://wpkg.svn.sourceforge.net/svnroot/wpkg/wpkg/stable/1.1/
> --8<---------------cut here---------------end--------------->8---
> 
> and expect to have something like with:
> --8<---------------cut here---------------start------------->8---
> svn log -l 10 https://phpmyadmin.svn.sourceforge.net/svnroot/phpmyadmin/tags/RELEASE_2_11_0/phpMyAdmin
> --8<---------------cut here---------------end--------------->8---

Here the RELEASE_2_11_0 tree is a simple (versioned) copy of the phpMyAdmin
folder at a specific point in time. In CVS this was done using "cvs tag
RELEASE_2_11_0".

In WPKG we could also create such release-copies within the stable/ branch. In
our case it would not add much value since always the latest version is the one
which is published.


Well, I have to admit that I did a mistake when moving the current-development
folder to the stable/ folder. I moved just the content and created the 1.1
folder from scratch. So if you run the command (svn log) above on the folder it
displays only the folder history. Try running

svn log https://wpkg.svn.sourceforge.net/svnroot/wpkg/wpkg/stable/1.1/wpkg.js
(or look at
<http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/1.1/wpkg.js?view=log>)

and you will notice that SVN still maintains the full history of the file.
I will try to avoid this mistake with creating a new folder in the future.
I should have moved the current-development folder directly to stable/1.1
instead of creating stable/1.1 and moving the contents.

For WPKG 1.2 I will create a sub-folder at current-development/1.2 and then I
can move it anywhere without losing the folder history.

That's actually one of the main differences between SVN and CVS - SVN adds
version-tracking for the folders. And I am still an SVN newbie ;-)


> For me, history of a project is a line of the trunk (current-development
> for WPKG), and some branch where reeleases are made, etc.

There are usually multiple branches from which releases are made - in WPKG we
have a development and a stable branch. At a certain point in time development
becomes stable and stable becomes end-of-life. This is perfectly reflected
within the SVN tree. The full history of each branch (no matter in which state
it is, dev, stable or end-of-life) is maintained. [well, except for the mistake
I did, my apologizes again].


br,
Rainer