cvs is source code management. You are proposing a policy of how
your site is going to develop ontop of cvs.
For what you are talking about creating specific branches for
new features and new design's is not a bad system.
I would create the branches off of the feature name and designname
parts.
For the rx and px I would use tags on the particular branches to
signify this.
You probably want to create some wrapper scripts that would
do the tagging and branching correctly for you.
donald
On Fri, Aug 11, 2000 at 01:52:13PM -0000, Tim Diggins wrote:
> Hi Carlos, Sean and list -
>
> I'm picking up on this thread rather late (looking around for info
> on ... using CVS in a web-shop). I'm just getting beginning to get my
> head around CVS, and also going to read Sean's useful document. If
> people are interested I'll post up our workings on this area.
>
> Part of the confusion with websites it seems to me, is that there is
> very little source & object code distinction, the main distinctions
> being in *binary* files like photoshop/fla flash --> gif-png-jpg/swf
> flash.
>
> Binary files
> ------------
> Does CVS handle binary files too? the notion of "source code control"
> seems to preclude binaries... I will also do a search on the list for
> using CVS with JSP, because the complexities of JSP->class->java
> seems interesting as well.
>
> My current ideal (before considering implementing CVS):
> -------------------------------------------------------
> I had been considering a system (manually managed! ouch!) for
> versioncontrolling with a version such as v1.2 r12 p4, where v1.2
> would be the client-facing version (major/minor changes to site -
> major being total design/purpose change - minor being feature
> addition, not just content change) and r12 would be a review number
> (each time client reviews site the number is incremented. Only some
> of these are then uploaded to a live site). the p4 is a production
> version number - freely changable by the internal project team to
> freeze.
> * As a new feature is added it would start as FEATURENAME.r1.p1 and
> then get incremented until it was merged into the source tree and
> becomes v1.3.rX.pY.
> * As a new design of the site is added it would start as
> NEWDESIGNNAME.r1.p1 (or as 2.0.r1.p1) and when uploaded to the live
> site would be merged in as 2.0.rX.pY).
> * The key here is that it is feasable that all the following could be
> going on at once:
> - ongoing content changes to the site (within 1.2 // timescale 1 wk)
> - new features to the existing site (within
> FEATURENAME=1.3 //timescale = 1 month)
> - new site design/logic/purpose (within NEWDESIGNNAME = 2.0 //
> timescale = 3mo)
>
> (a) can you see my logic here? am I making sense?
> (b) how much of this would one want to/could one implement in CVS -
> would these simply be multiple branches stemming off the tree and
> then reintegrating?
>
> Relevant Apache tricks:
> -----------------------
> It also may interest people to know the apache mod-rewrite / vhosts
> alias tricks for hosting multiple sites automatically:
>
> If you want to have a tree that looks like:
> serverroot/
> websitename/
> versionid/
> html/
> cgi-bin/
> source/ (not for website)
> and want to maintain root level links (esp to /cgi-bin/ etc)
>
> then you can use mod-rewrite (with pain) or vhosts-alias to map from:
> http://versionid.websitename.servername/
> without need for separate apache config stanzas for new
> websites/versionnames.
>
> I only mention because it took some time to work out THAT this was
> possible (thanks to magnus bodin www.x42.org).
>
> Best
>
> Tim
>
> --- In [EMAIL PROTECTED], Carlos Costa Portela <[EMAIL PROTECTED]> wrote:
> > > > Here at demasiado.com, we're using cvs to help us develop our
> > > > website.
> ....
> directory (http://172.16.100.99/~ccosta/).
> </snip>
>
