commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml-js] GSoC project update
Date Fri, 11 Jun 2010 23:00:04 GMT
On Fri, Jun 11, 2010 at 6:29 PM, Jacob Beard <jbeard4@cs.mcgill.ca> wrote:
> Hi,
>
> Thanks for the critiques. I'm almost done with this development cycle,
> and so I'll commit my changes soon to SVN. After that, I'll use
> branches and standard SVN workflows to version-control my code.
>
<snip/>

OK.


> I have a quick question about use of Apache SVN: in the places I've
> worked where we've used SVN, it has been heavily discouraged to check
> in broken or unfinished code. We didn't do much branching, but mostly
> worked out of trunk. I think that breaking a branch is not as bad as
> breaking trunk, but I wanted to check with the community: are broken,
> intermediate commits to branches considered poor practice? What about
> to trunk?
>
<snap/>

Right, the patterns and conventions can change in various communities.
Commons is somewhere along these lines:

Trunks are generally expected to work. Its not recommended to break
the trunk of a Commons Sandbox component. Breaking the trunk of a
Commons Proper component with prior releases is even worse.

Branches can be of various types. SVN itself attaches no semantics to
the act of creating a branch (beyond a copy). The type of the branch
is decided by documented intent of developer at creation time.
Branches that serve as lines of development are to be treated with
similar criteria as trunks. Here [1] is such an example. There is
leeway for branches that are experimental in nature, when clearly
marked as such. It is OK for experimental branches to be broken where
the breakage may need to be introduced as part of a convenient roadmap
to get from some known working state to another anticipated
(presumably better, for some definition of better) working state. Such
experiments may not always succeed. Here [2] is such an example of an
experimental branch. The intent of the developer may be documented by
using a BRANCHINFO file which I use by convention, here [3] is the
corresponding example.

That is to say, in the specific case of [scxml-js] and this
discussion, I wouldn't worry if a branch is temporarily broken as part
of some refactoring or architectural overhaul. Until such a
refactoring or overhaul is completed the trunk serves as the last
known working state of the code. If the refactoring is successful, the
changes are merged to trunk (effectively, the branch becomes the
trunk).

-Rahul

[1] http://svn.apache.org/repos/asf/commons/proper/digester/branches/1_X_LINE/
[2] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/BETWIXT_IO/
[3] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/BETWIXT_IO/BRANCHINFO.txt



> Thanks,
>
> Jake
>
> On Tue, Jun 8, 2010 at 11:37 AM, Ted Dunning <ted.dunning@gmail.com> wrote:
>>
>> Making your code public early also saves you lots of effort because others
>> can jump in and help.  That sort of community is a lot of what Apache is all
>> about.
>>
>> On Tue, Jun 8, 2010 at 8:24 AM, Rahul Akolkar <rahul.akolkar@gmail.com>
>> wrote:
>>>
>>> Also, in the last paragraph you mention waiting till you finish
>>> porting more before checking into the Apache SVN -- whereas I'd
>>> actually suggest that you even do all your experimentation in the
>>> Apache SVN
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message