[Soc-2005-dev] Creating a CVS repository

[Jiří Hnídek]

Hi Chris,
we could have 10 repositories and everybody could do cvs merge in his 
own branch every week. I guess, that everybody will be familiar very 
good with changed code and will be able to solve any problem without 
bigger problem ... less work for you ;-), more for us :-), but it will 
be new good experience for us (I would like to know, how to do cvs merge 
;-) ).

Of cource, you would have to write some tutorial/doc about cvs merge or 
point at some existing tutorial :-).

Best regards,

Jiri

> Hey gang,
> 
> Alright, I think I am almost ready to create
> the cvs repository for the SoC sources.
> Since we don't really know you guys too well
> yet, it wouldn't be sensible to just give
> you commit rights to the official blender
> cvs repository.
> 
> I am planning to implement one of these two
> possible schemes:
> 
> ---
> 
> 1) Create a 'soc' repository with one branch
> that all of the SoC developers work on.
> I do weekly merges from the official blender
> tree to keep our tree in sync with current
> blender development.
> 
> Benefits: I know how to do this already (I do this
> for another tree); this gives 'real world' experience
> of working on a collective source repository.
> 
> Drawbacks: Developers might get in each others way;
> making a patch of any one developer's work becomes
> more difficult.
> 
> ---
> 
> 2) Create a 'soc' repository with ten branches,
> one per developer. I do ten weekly merges (one per
> branch) to keep each branch in sync with current
> blender development.
> 
> Benefit: Less conflict with other SoC-er's; easy to
> make a patch at the end.
> 
> Drawbacks: Isolated development may not reflect
> 'real world' conditions; I've never done this before
> so it's a bit experimental; might be quite a bit
> of administrative work; the cvs commands that the
> developers are required to use are more advanced.
> 
> ---
> 
> So each scheme has it's benefits and drawbacks.
> I am thinking that scheme one might be the way
> to go (I think it would be less error-prone and
> easier to administer), but I thought I would ask
> if anybody else had an opinion on this? Is there
> a better scheme not listed here?
> 
> Regards,
> Chris