cool I never used maven before, I will definetely have a look at it... On Oct 15, 10:12 am, Haikal Saadh <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
