IMO, the age of designers who only do photoshop or html is long gone... maybe they could be trained to write their presentation layer stuff as coldfusion pages and/or custom tags?
That aside, if you think option 3 will break your post-commit scripts, why not use maven instead of ant, and have that push code out to your staging server? If you know ant, it's not a big jump to using maven, from what I hear. Andrea wrote: > I have currently installed subversion on our server and trying to find > out the best solution for our developers and designer. > > The idea is to have > > - each developer working locally on a "local.xxx.dev" and committing > to the svn xxx repo. Each dev will be using coldfusion developer ed + > local apache ( a shared conf will be copied by dev every time they > need a new site, etc) + shared dsn to database servers... (if needed > then a local copy of the db too) > > - a single "xxx.dev" testing server not modified by anyone which > always contains the latest revision (visible by project managers/ > designers/etc) > > - a post-commit script which export/or update the site "xxx.dev" on > the testing server. (this server will not be modified directly, but > only via this post commit script) > or alternatively > - using ant with a build.xml script to rebuild the "xxx.dev" site when > required. > > > this works perfectly fine in an ideal world... > > > The problem arise when designers need to access the xxx.site and do > not know anything about configuring their machines....... eh eh > > in our case designers usually change html files or images, mainly > doing cutups which then needs to be incorporated or modified by > developers. But sometimes they can change html layout on coldfusion > templates too ! > > > >>>> solution 1: training the designers ??? mmmhhh >>>> > > >>>> solution 2: having a separate folder on the server (eg /xxx.dev/html/ >>>> where they can do the dirty works... :) which is not included in our svn >>>> repository ) then developers will go to that folder and pickup what they >>>> need. >>>> > But this won't work when they change any cf templates... (cause they > are not in that folder...) > > >>>> solution 3: having the site "xxx.dev" shared on the newtwork and using >>>> tortoise svn, the designers will be able to commit their changes and see >>>> the websites as well. >>>> > > solution 3 seems the only one working for me, the only problem will be > that the actual xxx.dev site will be a checked out version of the > repository (with all the pro and cons) > > Which means : > ----no post-commit script (even if the svn server see the shared > folders it would not be able to manage merging in case of file > conflicts) > ---no ant build.xml as it could override files and have the same > problems as the post-commit script > > the only way to update the site "xxx.dev" in that case will be to > checkout other changes manually (to be sure...) > when needed. > > all this involves a lot of extra work for developers while the ideal > world was soo easy !!! > > > any extra ideas/ best practice ???? I guess everyone has sort of > similar issues.... > > cheers, > Andrea > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
