Subject:*
Name/Email:*
Message Icon:*
Message:*
url email imgsrc image php hide code quote
SAMPLE
alignleft aligncenter alignright bold italic underline linethrough   


 [more...]
Options:*
 

 

 
View requirements*
Reply No requirement
Confirmation Code*
  The code is case-insensitive  Click the image for a new code. | Maximum attempts: 8
   
Re: ImpressCMS SVN Repository

by skenow on 2007/12/5 15:55:14

Now that I am starting to understand svn a little more, this makes a lot of sense.

+1
Re: ImpressCMS SVN Repository

by Dave_L on 2007/12/5 12:49:03

I can do that, but before finalizing our rules, we should probably wait until more developers have had a chance to provide feedback here.
Re: ImpressCMS SVN Repository

by marcan on 2007/12/5 11:38:46

+1

Dave, would you have time to put those rules on a page at reboot group so it will become our "official" rules, which we could improve as the time go by.

We would make this page available publically in our soon to come wiki.

Let me know !
Re: ImpressCMS SVN Repository

by Dave_L on 2007/12/5 8:49:14

I agree with Rules 1-3, and would like to propose another one:

- Rule #4: All committed code must be fully documented.

In part, that means that every function has a phpDocumentor-compliant header comment, which is both correct and understandable, states the purpose of the function and describes the parameters and return value. The same applies to class properties. The header comment for a function (or a class) is intended to be a "mini user manual" for the function that provides all the information needed to call that function, without having to examine the body of the function.

I suppose this won't apply to existing code that you're modifying and don't understand well enough to add missing documentation. Ideally we could review it and figure out together how to document it, but time may not permit that.
Re: ImpressCMS SVN Repository

by marcan on 2007/12/5 6:35:07

Thanks Dave, excellent link.

I suggest every one involved in coding should read this bes practice summary.

About branching

So I now realize that XOOPS was using the Always branch system and I understand now that it has pros, but I feel more cons...

I very like the "Branch-when-needed" system :

- Users commit their day-to-day work on /trunk.

- Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.

- Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.

- Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Can we all agree on this ?