Talk:Subversion: Difference between revisions
New page: ~~~~ For the new vdf-guidance subversion server we are discussing setup details, we figured it would be useful to continue the discussion in the open and do it here. Unfortunately that mea... |
No edit summary |
||
| Line 7: | Line 7: | ||
#How to setup the default project structure | #How to setup the default project structure | ||
##Should we use trunks and branches? | ##Should we use trunks and branches? | ||
===Why trunks and branches=== | |||
Seems to me that this is only useful to apply to the bigger projects like "The Hammer", cWindowsEX, etcetera. where you actually will end up having multiple active branches (the alternative is to use compiler directives *yuck*) as not all projects are always used in the latest vdf version only. | |||
I really do not wish to push developers to the last version, it is _their_ choice, something that is deemed important with open source. Besides that, not every company wants to have the overhead of having to bring your application to the next dataflex version on a yearly bases. | |||
Remember this -usually- small step means that you must retest everything when taking Q&A seriously. | |||
OTOH bogging down the code with compiler directives makes the code harder to manage, read and understand. | |||
So for the moment my suggestion is to only use branches for the bigger projects. | |||
I suppose we can always add a branch later on if a package needs it? | |||
[[User:kga|kga]] 21:43, 21 February 2008 (CET) | |||
Know I actually think about it - I don't think there will be any issues in setting up the default structure of the svnserver to allow for branches for all projects | |||
- I mean you _have_ to actively choose to make a branch if you don't codily happily along in the trunk . So for me it could be a good - clean approach to support branches for all projects pr. default. | |||
It will be harder to make a branch somewhere in the future if we don't support it from the start - so maybe we should give it some more thought. Maybe have a vote? | |||
Revision as of 21:47, 21 February 2008
Wil 21:43, 21 February 2008 (CET) For the new vdf-guidance subversion server we are discussing setup details, we figured it would be useful to continue the discussion in the open and do it here. Unfortunately that means you are dropping in the middle of a discussion. will try to make it readable a bit.
The current setup questions are:
- What to put on the global ignore list
- No parts that can easily be generated
- How to setup the default project structure
- Should we use trunks and branches?
Why trunks and branches
Seems to me that this is only useful to apply to the bigger projects like "The Hammer", cWindowsEX, etcetera. where you actually will end up having multiple active branches (the alternative is to use compiler directives *yuck*) as not all projects are always used in the latest vdf version only.
I really do not wish to push developers to the last version, it is _their_ choice, something that is deemed important with open source. Besides that, not every company wants to have the overhead of having to bring your application to the next dataflex version on a yearly bases. Remember this -usually- small step means that you must retest everything when taking Q&A seriously.
OTOH bogging down the code with compiler directives makes the code harder to manage, read and understand. So for the moment my suggestion is to only use branches for the bigger projects. I suppose we can always add a branch later on if a package needs it?
kga 21:43, 21 February 2008 (CET) Know I actually think about it - I don't think there will be any issues in setting up the default structure of the svnserver to allow for branches for all projects
- I mean you _have_ to actively choose to make a branch if you don't codily happily along in the trunk . So for me it could be a good - clean approach to support branches for all projects pr. default.
It will be harder to make a branch somewhere in the future if we don't support it from the start - so maybe we should give it some more thought. Maybe have a vote?
