committing to source control

[JonathanKohl]

If you have made changes on trunk and are confident, feel free to
check in. We'll start making builds and testing. I prefer the open
source ideal of failing fast, so if something breaks, let's find out
early and fix it. I don't get upset about broken builds

If you are nervous about checking into trunk, I created a sandbox
branch for preliminary work if you prefer for now:
https://svn.openqa.org/svn/sessiontester/sandbox
View it with fisheye:
http://svn.openqa.org/fisheye/browse/sessiontester/sandbox

Later on, we could use it for experimental designs or things that are
radical departures from the current design. I am a big fan of
prototyping and having testers and designers try out the real thing.

All that said, I want to leave it up to the programmers on the team to
determine the best way to manage source control.

What are your thoughts on a source control strategy? For regular
commits? For releases? Thoughts on tagging and branching?

Thanks,

-Jonathan

[Louise Geijer]

Hi!
My thoughts on source control strategy:

- For smaller changes of the code and bug fixes, I think we should use the trunk as much as possible (always making sure that it builds properly, of course).

- For work packages, larger changes of the code or just testing out some new features, I prefer creating a new branch. When the functionality or parts of it is implemented and ready for testing, the possible changes in the trunk should be merged in, the function should be announced ready and can then be tested/demonstrated in the branch. If things look good, the changes should be merged back into the trunk and the branch should be deleted.

- I think commit messages should be more comprehensive than "Do a diff." ;)

//Louise

> --
> To unsubscribe, reply using "remove me" as the subject.

[Björn Lindberg]

Hello!

I second this.
Branch when needed; minor changes can be committed directly to the trunk.
When branches are obsolete we remove them from the HEAD.

Tag all major releases and any intermediate releases, if necessary.
(Tagging release candidates might be useful, sometimes.)

The sandbox sounds good. Perfect for experimental work, personal branches, insane stunts, etc.

/bjorn