Sync'ing cfm pages between repositories

[TimeTraveler]

Well, I've got a situation where I cannot really change the habits of a remote group of developers.

So the code migration model of dev -> beta -> production has turned into just fixing on production and copying back to each developer's local copy (only 2 thankfully) and hope there's no contention and and or hope someone can find a file if a roll-back is needed. My current employer runs a small shop and has me on board to try and correct some bad coding habits and so forth.

What I need is a way to sync my copy with production, and if a .cfm file on Prod is newer than mine, ask me what to do or download a copy with the datestring in the file or something. It would be nice to get a text file report of the files that change on some periodic basis.



Any Cold Fusion specific suggestions? I'm looking at possibly using Eclipse with the CFPlug-in as a possible part of this solution.

What about MS SyncToy?

Thanks in advance.

-Sean/TimeTraveler

 

[FALCONSEYE]

you must try some sort of version control something like subversion or visual source safe.

http://www.jetansolutions.com

 

[Sarky78]

I agree with falconseye. no matter how few developers are working on the project you will find a version control system invaluable. We use a system called NGSource, which allows all the usual functions (checkout, checkin, rollback, mile stoneing and versioning) quite cheap as well in my opinion.

Hope this helps!

Tony

 

[TimeTraveler]

First, let me thank you for taking time to reply. It means a lot.

Second, I suspect I may have not have explained my situation in the way that would suggest the type of solution I was looking for.

I would *LOVE* to version this stuff from a commonly accessible repository, but that's not going to happen, or at least not near-term.

What's needed is a bandage, not a perfect-world solution.

The remote team uses Dreamweaver for HTML/CFML authoring. I use 'vi' (for Windows), or sometimes even just plain old (gasp) notepad. So far, their use of Dreamweaver (or at least HOW they are using it) hasn't supported current business requirements. It certainly doesn't document or add any versioning number to the individual .cfm files.

Here's what I need:
* version numbers or some sort of date string inside the file
* Use the Beta box to poll the .cfm pages on Prod
- archive any newly changed pages that didn't come from Beta
- and push the original file as recorded on Beta back onto Prod
* Then, if I determine the archived rogue file is indeed an improvement on the Beta version, swap it in both Beta and Prod.

I know that's pretty specific, but someone has had to have gone through this middle step before getting to the "version-control" holy grail of Source Safe et al.

Lastly, I'm predisposed to freeware or hand-coded solutions.

Thanks again, and thanks in advance.

Sean/TimeTraveler

 

[philhege]

1. Yank the permissions of every developer to write to production.
2. Make sure you do #1.
3. Make sure you do #1.
4. Re-point the DW sites to development (local files on the dev's box, the "site" on the dev Web server).
5. Institute a release policy. One person (yourself, the manager, the production Web admin, whoever) should be the gate keeper for promotion to production. The policy should include testing, version incrementation, and rollback/revert guidance.
6. Do not bargain with #5. Without a version control package, this is your only hope.



Phil Hegedusich
Senior Programmer/Analyst
IIMAK

http://www.iimak.com

-----------
Not NULL-terminated yet.

 

[NorthStarDA]

yeah i'm gonna agree with Phil- if it is your responsibility to fix this then it's your responsibility to put in processes that make your software less vulnerable.

i've heard this argument a thousand times and i'm also in the middle of it with a client of mine- it's always the same:

"We're too small for something like that" or "Thats too complicated", believe me- the first time a paying client sees some developers debug code on a production site you will regret the decision to allow developers to continue touching those prod boxes. That boss that always says not to do source control is usually the first one to come ream you a new arse cuz a client called up screaming mad.

you won't find many people with suggestions on how to do what you want because the process is inherently flawed and most people have already learned that lesson.

=========================================
Don't sweat the petty things and don't pet the sweaty things.