|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
Hi Guys,
I just wanted to ask how people manage their own copy of the source for cuyahoga?
We, in the past, have kept the core CMS in its own repository and then taken a copy and compiled it for a client. Then this goes in it's own rpository where we change and control the CSS and what not specific to that installation.
We haven't really used tags or branching which i think has made it hard to manage as whenever we now makes changes to a previous version, we end up being forced to upgrade it to the latest version.
Can I ask how other manage their code in version control software for each client? Do you branch? or tag? or something else?
Many thanks
Matt
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/3/2007
Posts: 44
Points: 132
|
Similar issue came up for me when working on Webolize IssueTracker, which is a Cuyahoga module. What is the best way to upgrade or move your code to the next version. I'm still having issues, but you basically have to keep your code and the cuyahoga code in separate places and your build scripts will have to copy them to the correct places right at the end. If it's modules, cuyahoga has a pretty slick feature in the install script that it looks for ALL module directories and asks if you want to install it.
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
I guess module version control is another issue.
Do people just keep all the modules in the core repository? or should you seperate the modules into a) a single repository for all modules or b) a sperate repository per module.
Matt
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
Anyone else got any recomendations?
I know it's not stricktly about the CMS istelf, but still think it is valuble information on how to use the CMS effecitley.
Many thanks
Matt
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
The easiest solution I found so far is the following physical structure: Code:
MyCuyahogaSolution
|- Website (Plain vanilla Cuyahoga, not under source control, not in solution)
|- MyCuyahogaSolution.Web (templates, css, custom aspx pages)
|- MyCuyahogaSolution.Modules.Module1
|- MyCuyahogaSolution.Modules.Module2
|- ...
The trick here is that the Web project exactly mimics the structure of Cuyahoga.Web. A post-build step copies everything (web files and binaries) over the default Cuyahoga files in the Website directory. You have to use IIS as webserver in this scenario and use a virtual directory that points to the Website directory. This way, it's easy to customize Cuyahoga without having the need to put Cuyahoga itself under source control.
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
Hmmm, thats not too far from what we have been doing.
I think the major difference is that we have made quite a few changes to the Admin (so probably won't be able to upgrade that easily) which means it would make sense to put the actual core source under version control, to track these changes.
Maybe i need to look into linking the repositories (which i beleive you can do in SVN) to mimic something similar.
Quick question on the setup you've explained. Do you create your modules specific to a client? or do you create general ones which work from client to client? I ask because we have done the later, which are added to the core cuyahoga solution, which is another reason why we put the core source under version control at this time.
Many thanks
Matt
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
D3grade wrote:
Quick question on the setup you've explained. Do you create your modules specific to a client? or do you create general ones which work from client to client? I ask because we have done the later, which are added to the core cuyahoga solution, which is another reason why we put the core source under version control at this time.
The projects we've done so far didn't have a need for similar modules. If this were the case, we'd probably set up a new SVN repository and use svn:externals.
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
Hmmm, interesting. Looking into Subversion, i may have come across the perfect solution. Vendor Branches. http://svnbook.red-bean.com/en/1.1/ch07s05.htmlMatt
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
I'm begining to see how it might be best to set this up. I do have another question i could do with your advice on.
Say for the core CMS that we will have under version control, and any common modules. When you use svn:externals, would it best to create a branch specificaly for the client? That way if they come back for changes they are not forced to upgrade as they currently are.
Many thanks
Matt
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
When creating a specific customer branch so that you don't have to upgrade Cuyahoga, I'd suggest not using svn:externals, but including the Cuyahoga source in the branch.
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
Ok, I'm now thinking that i basically need 2 repositories. A vendor repository for cuyahoga itself, and then a repository for the modified CMS. In this repository, the trunk contains the source for the cms along with core / common modules. Each client then gets their own branch, where unused modules can be removed. It would look something like this.  What do you think? Matt
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/3/2006
Posts: 243
Points: 450
Location: the moon :)
|
D3grade,
this is exactly what i do.
i also use Git not SVN as its much lighter and easier to manage branches i find. But git does take a bit of getting used to. The windows version is super stable ans thee work going on to make the TortoiseSVN windows explorer shell stuff work with GIT too which is the icing on the cake. If i was thinking about using Git, i would wait for the explorer shell integration.
In Git you can pull and push to/from SVN server too.
if your doing it hard your probably doing it the wrong way....
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/17/2007
Posts: 168
Points: 387
|
Cheers gedw99,
I've only recently really heard of Git, but will definatley keep an eye on it (especialy if there is going to be TortoiseSVN integration).
Untill then, i'm really happy with subversion.
Many thanks
Matt
|
|
|
Guest |