Feature Proposal: I am unclear on the whole svn thing (mostly)

Motivation

I know the key svn commands. What I need, however, is what I'm supposed to do when vis a vis releases, etc. I've apparently been doing a piss poor job of asking for help in this area, so I'll try once again.

Description and Documentation

For the most part, I've been working on plugins and some standard doc cleanup/refactoring. In the case of plugins, I've been checking plugins in via svn ci. What I don't know what the procedure is to test and "release" (whatever that means) each plugin. I'm testing them because I'm using them, of course, but that can't be all there is to it.

In the case of doc, I am unclear whether I should be editing twiki.org/TWiki, TWiki04, or my own web and then svn ci them. The fastest thing is to do is on my machine, given the load, and then svn ci, but I don't know if or how the docs will be reviewed and merged and, if merged, into what.

I'm sorry if I'm being very dense here, but I could really use some brief, specific guidelines about how this all fits together, especially when it comes to docs. The bits and pieces I've gotten from #twiki and the meetings just isn't enough.

Impact and Available Solutions

Well, the impact is to what extent I can and do contribute to the TWiki community, rather than just writing stuff for myself. The available solution is, I guess, Sven or someone who knows all about this stuff writing it up.

Implementation

Discussion

Hm, didn't Crawford just do this in MergingInSubversion? And what about BuildingARelease? -- If this isn't enough one could always read a book.

-- FranzJosefSilli - 08 Mar 2006

Unfortunately, that begs the question of when do I merge? I'm not doing bug fixes, so neither of those applies. And I don't know when they will apply to me.

-- MeredithLesly - 09 Mar 2006

First up, i'd suggest that you are asking for everything to be made clear, when we 'experts' haven't figured it out yet.

That said, up until the last few weeks, we were working on the DevelopBranch only, and trying very hard just to get a release happening at all.

Now that we are done there we're in flux, as we try to understand the consequenses of:

1. DevelopBranch is where the Next major release comes from, and thus will (actually already does) contain some refactorings that developers had saved up from middle of last year, but were considered too new to put into TWiki04 - and thus need testing asap
2. there is a TWikiRelease04x00 branch where we have built TWiki 4.0.1 from, and are intending to build 4.0.2 from as well.

The inevitable consequenses of having new development taking place (and not just bugfixes) is that there will be divergence between the DEVELOP codebase, documentation and plugins, and the ReleaseBranch.

This is one of the major driving factors for wanting Documentation and Plugins in SVN, in the branch for which it is appropriate, rather than the situation that we had in CVS, where there was only one branch. The CVS setup didn't give us the ability to manage patch and minor releases (and note how we never really did so without massive pain).

Understanding that nothing goes into a release unless it is in SVN should help you realise that (if you have svn commit access), the best place to put any (including docco) changes, is into SVN. If the TWiki04 web were an SVN checkout as I suggested, then it would be a trivial svn up to merge those changes with any made via the twiki.org web site. (that's a stop-gap solution pending an actual SVN based store module)

As to When do you merge?

That is an age old question, that in almost every workplace will be replied to with 'It depends'.

It depends on a large number of human determinable factors, including the current focus of patch releases; your, and others, confidence in those changes; the amount of testing; the amount that customers are screaming; and how much attention your co-workers are paying at the time.

Sorry, thats why I was expecting to discuss each Item at a meeting, and have those to be put into the release marked, and then I would merge them, let a small test window happen, and then release. The current proposal is more intensive, and much better, but still, "when to merge" is hard to pin down.

-- SvenDowideit - 09 Mar 2006

Sven said it all. Here's a simple decision checklist:

1. If you're working on an Item that has been reported as a bug by an end user then work on TWikiRelease04x00. If the fix affects the DEVELOP code/doc base as well, then merge the fix across to DEVELOP when you are finished.
2. If you are building a plugin that is designed to work with TWiki-4, then work on TWiki04x00, and ignore DEVELOP.
3. If you are writing code or documentation that is incompatible with TWiki-4, or raises risk in the next patch release for no other reason than it looks pretty, or you want to test your plugin in DEVELOP, then you should be working in DEVELOP.

-- CrawfordCurrie - 09 Mar 2006

This is an old out of date topic now. In case you bump into it by accident then note that SubversionReadme is the best starting point for use of Subversion (SVN)

• All code development now happens on the svn trunk. http://svn.twiki.org/svn/twiki/trunk
• All plugin development is now done on the svn trunk. http://svn.twiki.org/svn/twiki/trunk
• All major and minor releases are tagged off the trunk.
• After each major or minor release a TWikiRelease##x## branch is created from which patch releated are tagged. Very urgent bugfixes for core and default plugins are merged from the trunk to the release branch.
• DEVELOP and TWikiRelease04x00 are dead and blocked for further checkins.

Changes were fully implemented 08 Oct 2006, and further ones 17 Feb 2008. See SubversionReadme.

-- KennethLavrsen - 08 Oct 2006, and re amended SvenDowideit - 17 Feb 2008