Checking in to Experimental branch

[Ted Young]

My DateTimeAssert is ready for check-in, but I'm not sure how "experimental" vs. "release" works in Subversion. Do I just check it in normally, or do I have to do something special? Once it's in, I'll create a Crucible review for it.

;ted

[Ansgar Konermann]

Hi Ted, hi Alex,

at work, we're exercising a versioning technique called "agile version
control". You can read about it here:
http://www.infoq.com/articles/agile-version-control

I suggest we use a similar scheme here. Maybe we can even borrow more
from this article than just the versioning scheme.

At work, we introduced this way of versioning more than a year ago and
we're very satisfied with it. We simply create one new branch for each
new feature we want to develop, which lives under
$repo/branches/sprints/sprint<n>/<Ticket#>-ShortName

Since we don't use the scrum process here, we probably don't need the
.../sprints/sprint<n> part of the SVN path. So I suggest the following
svn structure:

fest-assert
fest-assert/trunk
fest-assert/branches
fest-assert/branches/issues
fest-assert/branches/issues/000/FEST-1/
...
fest-assert/branches/issues/000/FEST-99/
fest-assert/branches/issues/100/FEST-101
fest-assert/branches/issues/200/FEST-199

and so on.

Below each of the fest-assert/branches/issues/<n>/FEST-<m> svn paths, we
find the usual project directories/files like src, pom.xml etc.

The directory level containing only directories named after numbers are
intended to allow for "scalability": we'd rather not search for a
development branch for FEST-791 in a list of 800 branches, but limit the
search space to something smaller. We could also chose to put 50 FEST
issues into one directory, or 20, or whatever.

Whenever one wants to start a new development branch, he has to branch
it from the current version of the trunk. He can then check out this new
branch and commit all changes into this branch. Just before the changes
should be copied into the trunk (after the review has taken place and
all findings are committed to the branch), all changes which might have
happened in the trunk need to be merged into the development branch.
After this, the actual merge of the changes into the trunk will work
without conflicts (its merely a "copy").

The article is really worth reading. I recommend it to everybody who
wants to develop software in a team and desires a potentially very short
release cycle.

We probably need to prepare our repository structure a bit, but that
should be the easiest part. The harder parts of this mechanism are: make
sure you merge down changes from the trunk regularly (otherwise you'll
be in a scrape when trying to copy your changes into the trunk) and:
become acquainted with the merge functions of your IDE.

Suggestions/comments welcome.

Kind regards

Ansgar

[Ted Young]

Hey folks,

That versioning sounds interesting, though I wonder if it's a bit too much overhead for a project that has few contributors? But then, I'm used to branch-per-release in Perforce, so I'm open to trying it. I'll leave it up to Alex since it's his job to handle the releasing and I don't know if this makes things hard for him or not.

;ted

[Alex Ruiz]

I agree, pretty interesting article. Thanks Ansgar :)

Ted, I haven't worked this way before, but it seems pretty useful.
Would you like to be the first to try it out? :)

If it doesn't workout (e.g. releasing gets too complicated,) we can
try something else.

Cheers,
-Alex

On Aug 30, 12:34 pm, Ted Young <tedyo...@gmail.com> wrote:
> Hey folks,
>
> That versioning sounds interesting, though I wonder if it's a bit too much
> overhead for a project that has few contributors? But then, I'm used to
> branch-per-release in Perforce, so I'm open to trying it. I'll leave it up
> to Alex since it's his job to handle the releasing and I don't know if this
> makes things hard for him or not.
>
> ;ted
>
> On Sat, Aug 29, 2009 at 1:34 PM, Ansgar Konermann <
>

[Ted Young]

Uh, sure, I'll try it out...but someone will have to guide me: I'm a Subversion novice (and rely on IntelliJ IDEA to do the right thing). 

;ted

[Ansgar Konermann]

Ted Young wrote:

Uh, sure, I'll try it out...but someone will have to guide me: I'm a Subversion novice (and rely on IntelliJ IDEA to do the right thing).

No problem.

I'm going to prepare the SVN folder structure on the server and probably set up a little wiki page describing how to branch and merge. Since we use IDEA at work, it'll be no problem to include some detailed screenshots.

Regards

Ansgar

[Ted Young]

Great! Thanks Ansgar!

;ted

[Ansgar Konermann]

Ansgar Konermann wrote:
> Ted Young wrote:
>> Uh, sure, I'll try it out...but someone will have to guide me: I'm a
>> Subversion novice (and rely on IntelliJ IDEA to do the right thing).
> No problem.
>
> I'm going to prepare the SVN folder structure on the server and
> probably set up a little wiki page describing how to branch and merge.
> Since we use IDEA at work, it'll be no problem to include some
> detailed screenshots.

BTW, do we have a wiki space somewhere which can be used for this kind
of developer documentation?

Regards

Ansgar