Colin,
(Reply inline)
On 26-Jan-09, at 7:35 PM, Colin Clark wrote:
Blake,
On 26-Jan-09, at 7:19 PM, electBlake wrote:
- Short Version: I need to get the 0.6 framework - CakePHP - into
the SVN but I want to preserve the VULab 0.5 in SVN as well.
The Problem
- VULab 0.5 is not going to be changed until further notice, BUT it
may be in the future - this makes me learn away from tagging the
version.
- VULab 0.6 is nothing like the original version and will be an
import rather then a patch. I understand a branch as making a copy
of the trunk (or a release) and developing it independently of the
version in the trunk.
Do we tag? Do we branch?
Good question. Here's my two cents; hopefully others will contribute
their thoughts.
In SVN, tagging also makes a copy of the code. That said, it's not
typical to modify the tag once you've cut it.
In this case, I might actually do both: cut a tag representing the
0.5 release, create a branch for legacy 0.5.x development, and start
working on the 0.6 line in trunk.
Colin
This approach makes a lot of sense to me and it seems to cover all of
our bases. As long as svn storage space isn't a concern I think this
is a good plan. On the other hand, If we are considering hard-drive
space as an issue, I should note that that if we tag and branch 0.5,
there is a good chance that in 2 months we will see another 0.5.x tag
cut from the 0.5.x branch.
I have a feeling that hard-drive space isn't a major concern in these
sort of dilemmas as the priorities are: having milestone versions of
our code isolated within the svn as well as having a strong code
revision history to dive back into.
If there are no other thoughts or red flags that anyone sees, tomorrow
(after some final commits are done) I'm going to recommend that we
take the tag & branch approach with vulab 0.5, and do a svn import of
the latest stable CakePHP code into the trunk.
( http://cakeforge.org/frs/?group_id=23&release_id=434 )
- Blake
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
