OT: Subversion

0 views
Skip to first unread message

AJ Mercer

unread,
Apr 24, 2007, 2:54:27 AM4/24/07
to cfau...@googlegroups.com
Hi Fusioneers,

I have finally set up a subversion server and have imported the web site.

Just want to get an idea of how people go about bug fixes and then deploying them.

As I understand it, you make branches for major work that may break the site, and minor bug fixes stay in the trunk.

But when it comes time to deploy the bug fixes, I only want to release the ones that have been tested and signed off.
So I need away to identify certain files - with a job number; then export just those files.

And it may be even more complicated if there are multiple bug fixes in one file - and I only want to release one.

Any suggestions would be greatly appreciated.

Mark Mandel

unread,
Apr 24, 2007, 3:00:36 AM4/24/07
to cfau...@googlegroups.com
Honestly, I don't actually ever do any branching.

Everything pretty much goes on in trunk.

If I ever do branching, it's because I've got a stable build of
something that people are bug fixing, and i want to keep a series of
new features separate from that build.

Then bug fixes can be incorporated into the trunk, and released off
the core code base.

When the core code base is ready again for new development, I just
merge my branch with my trunk, and continue developing from trunk.

Make sense?
(Honestly, that rarely ever happens tho)

Mark


--
E: mark....@gmail.com
W: www.compoundtheory.com

AJ Mercer

unread,
Apr 24, 2007, 3:26:06 AM4/24/07
to cfau...@googlegroups.com
I think this is what I am after
   http://ariejan.net/2006/11/22/svn-how-to-fix-bugs-properly/

Basically, it say to create a pre and psot bug fix tag, then merge changes from pre to post into the trunk.


On 4/24/07, AJ Mercer <ajme...@gmail.com> wrote:



--
If you are not living on the edge,
You are taking up too much space.

Andrew Scott

unread,
Apr 24, 2007, 3:28:29 AM4/24/07
to cfau...@googlegroups.com
 
Ok here is how it should be used, as per the documentation that Subversions recommends. But there is no fast and hard rules for this.
 
Now with the following, it would be so nice that I could do this with databases as well:-(
 
Anyway, trunk is the absolute repository of all changes and is considered the head revision. Tags, are used for actual releases, previous and is more commonly used for past zipped up archives.
 
Branching is a little more complex only if you let it, but lets say in our case we have 5 different versions of our application and we are supporting all of these current versions we have these in the branch.
 
Now what this means is that it becomes independant of the trunk, hence it is a branch from a point in time and can be maintained as such. The best thing is if you use eclipse, or any client that plugin/application you can just do a switch and it swaps the 2 versions that you are working on.
 
I love eclipse for this reason, because when I switch I am then working on the version that I switched in my IDE with magic happening in the background.
 
Now the important thing to also remember here, is that it is just that a branch and the code you modify WILL not be placed in the trunk. So if you think that the change / fix you make needs to be incoporated in the trunk / current release then you are going to have to merge that code.
 
It is a little more complicated than I have described, when it comes to maintaining more than one version, but if you understand how switching works then it isn't so hard to use.
 
I suggest reading the documentation on branching/merging for a more detailed explanation on this.
 
 
 


 
On 4/24/07, AJ Mercer <ajme...@gmail.com> wrote:
Phone: +613  8676 4223
Mobile: 0404 998 273

Andrew Scott

unread,
Apr 24, 2007, 3:34:08 AM4/24/07
to cfau...@googlegroups.com
Actually it says if you think the bug might effect the current release. Thats a different thing.
 
But yes merge and diff is you friend in those cases.


 
On 4/24/07, AJ Mercer <ajme...@gmail.com> wrote:
I think this is what I am after
   http://ariejan.net/2006/11/22/svn-how-to-fix-bugs-properly/

Basically, it say to create a pre and psot bug fix tag, then merge changes from pre to post into the trunk.


On 4/24/07, AJ Mercer <ajme...@gmail.com > wrote:
Hi Fusioneers,

I have finally set up a subversion server and have imported the web site.

Just want to get an idea of how people go about bug fixes and then deploying them.

As I understand it, you make branches for major work that may break the site, and minor bug fixes stay in the trunk.

But when it comes time to deploy the bug fixes, I only want to release the ones that have been tested and signed off.
So I need away to identify certain files - with a job number; then export just those files.

And it may be even more complicated if there are multiple bug fixes in one file - and I only want to release one.

Any suggestions would be greatly appreciated.




--
If you are not living on the edge,
You are taking up too much space.

Toby Tremayne

unread,
Apr 24, 2007, 4:26:56 AM4/24/07
to cfau...@googlegroups.com
Hi AJ,

depends on what you're doing.  If you're talking about an application that is in production yet has ongoing development as well as maintenance, something like this is good:

Ongoing normal development is done in the trunk.  When you have a stable release, tag it, and create a branch (IE release_10).

Now you *know* that the code on the live server is what's under release_10.  The reason we create a branch is so that we can make maintenance fixes on that branch.  For example if you have some ongoing development that's not finished, but you need to make an urgent patch to the live version of the application, then you make the patch on the relevant branch, make sure it works, then re-release (or you make X number of fixes and do weekly releases etc).

When you've done this, you take a look at the fix and see if it's still relevant to the main trunk which has now moved ahead of that release.  If not, you ignore it - if it's still needed in the trunk then you merge it in.

If you have a very large team and you have one or two people doing experimental stuff on your app for example, you may want to create separate branches for them to work on to keep their changes away from the trunk.  

The big caveat here is that part of your release management NEEDS to ensure that changes to maintenance branches are always merged into the trunk, and that ongoing trunk developments are merged into experimental branches / forks where applicable.

Toby


-----------------------------------

Life is poetry, write it in your own words

-----------------------------------

Toby Tremayne
Senior Technical Consultant
Lyricist Software
0416 048 090


AJ Mercer

unread,
Apr 24, 2007, 4:41:43 AM4/24/07
to cfau...@googlegroups.com
Thanks Everyone - starting to get it a bit more now.

Getting stuff into subversion is easy - getting it out is a bit more trickier than I imagined :-)

All the developers will be developing locally (on their own PC).
The is a test server were developers deploy their mods for user testing.
Once the users have signed of the mods can go to the production server.

The production release will be behind the dev and test servers

The mods on the test server may take weeks to sign off and be be release in any order.

Quick / important fixes may be pushed through to the production server straight away. These would then be merged into current branches. I read in the svn book that you need to make sure theses are not merged again - but I don't understand why not.

I will mess around with my local subversion server and nut it all out.

Andrew Scott

unread,
Apr 24, 2007, 5:18:35 AM4/24/07
to cfau...@googlegroups.com
AJ,
 
This is going to open up a lot of debate......
 
My first question to you would be this, what methodolgy do you use for development and I would seriously think about this before you go any further.
 
There is a reason I say this, and it is all down to your team / individual and I have been guilty of this in the past.
 
Branches, as said can be used for a variety of things but the most common is a branch from the main development life cycle. This is usually different versions, or you might need to create a specific version for a client that will not be used by other clients.
 
I serioulsy would NOT and I repeat WOULD NOT use branches for a developer to use as a separate repository for each developer, this will really incur a nightmare for the person responsible for the merging of the code back into the trunk or branch.
 
Now this is the reason I a know this is going to create a deabte, but here we have just gone through this and it works but it takes a strong understanding, and I will repeat myself a very strong understanding of TDD (Test Driven Development) and Agile / Scrum programming.
 
The idea is simple, each developer is allowed to work off the trunk (As this is the latest code revision) with locking and management for build breaking tools you can ensure a stable build.
 
Now when someone is happy with there changes, fixes or whatever they migrate the change back to the branch / trunk whichever they are working on. This will also ensure that the merging from can be versioned from and reverted more easily. If you have 5 different branches for developers, then they have seperate changes to the trunk and should not be done this way.
 
For example, Bransh/developer1 might have made changes to there branch. But when he/she needs to compare revisions, they have to compare across branches and this can and will become very messy.
 
So what is the ideal situation. As I explained, and the docs mention. branches are called branches, because it is a branch or snapshot of that code at that time. So as also mentioned V1.0 has been released and has gone live, you branch this and then continue on with developement on V1.1 with the trunk. now the client comes along and says there is a problem with the release, which means I now have to switch to that branch to fix the problem. So when I use eclipse to switch, the enitre project is switched to that branch. I make the changes, and do the testing and if all is ok commit it back to the SVN and deploy it live.
 
Now did you notice, I said if all is ok to then commit it. The svn repository should be looked upon as it is intended, a repository for Source Revision not a repository that every change, bug or no bug is commited to the svn.
 
Now if the fix that was made to V1.0 does also effect V1.1 you can do a code compare and merge the changes, if it doesn't then good you don't need to do anything.
 
So to cut a long story short, Agile / Scrum development is a perfect example as is milestones because they are usually a point in time when you expect a stable build and with so many tools to check for this its easy to slap someone for not doing the right thing.
 
So DO NOT treat the SVN for just checking files in and out willy nilly, this is not what SVN is all about. Thats what backups are for, not SVN. So if a component written with TDD is completed you can stick that into SVN because you can be assured that it is functional.
 
But to use a branch for each developer, I am glad I am not your project manager I would fire your ass for mentioning it.
 
If you have any further questions I am glad to help.

 
On 4/24/07, AJ Mercer <ajme...@gmail.com> wrote:

AJ Mercer

unread,
Apr 24, 2007, 5:33:52 AM4/24/07
to cfau...@googlegroups.com
I didn't mean to give the impression that each developer had their own branch - they have their own ColdFusion environment with code checked out from the trunk (or switched to a branch).

Thanks for the tip on when to check in files - that makes things a lot simpler. Only check in completed work.

Andrew Scott

unread,
Apr 24, 2007, 6:33:46 AM4/24/07
to cfau...@googlegroups.com
*lol* After re reading your post, how the hell did I come to that conclusion:-(
 
Anyway, I sugest really reading that manual for Subversion it is worth the read on how branches / merging. I am still reading it myself for the 3rd time as there is a lot to take in.
 
But I will say if you haven't looked at TDD then I suggest taking the time to see how it will benefit you, since switching to this it makes life easy I just wish that CF had better tools for it:-(


 
Aegeon Pty. Ltd.

Peter Tilbrook

unread,
Apr 24, 2007, 6:48:28 AM4/24/07
to cfau...@googlegroups.com
Someone made a huge deal about "request" vars. And it was not moi lol!


Zac Spitzer

unread,
Apr 24, 2007, 7:20:04 AM4/24/07
to cfau...@googlegroups.com
branches / tags (they are same thing in svn) are cheap and fast in
subversion, they are just a refernce in the svn db until you make any
changes, this is a big advantage over cvs

as long as you know the commit number ( subversion use a single
counter to track all the changes), you can always create a branch from
any point in time if you/ know the revision number

one thing to watch is creating too many tags/branches, coz checking
our the root of the repository will have many copies

i've always found not branching unless you have to is a lot easier

svn integration with a project database is really good too, it
encourages people to write decent comments on their commits.. jira
for $$, trac for free, jira is better IMHO

On 4/24/07, Peter Tilbrook <peter.t...@gmail.com> wrote:
> Someone made a huge deal about "request" vars. And it was not moi lol!
>
>
>
>
> >
>


--
Zac Spitzer
+61 405 847 168

Andrew Scott

unread,
Apr 24, 2007, 7:38:33 AM4/24/07
to cfau...@googlegroups.com
On 4/24/07, Zac Spitzer <zac.s...@gmail.com> wrote:
 
one thing to watch is creating too many tags/branches, coz checking
our the root of the repository will have many copies
 
Hmmm, not true. thats just badly setup.
 
i've always found not branching unless you have to is a lot easier
 
yes thats true and unless you have too, or need to maintain diferent versions then one would actually not ever use this feature.
 

svn integration with a project database is really good too, it
encourages people to write decent comments on their commits..   jira
for $$, trac for free, jira is better IMHO
 
Here, here.... jira is the bees knees and when you have mylar for Eclipse, it makes entering tickets etc a breeze because you can also SVN mylar as well.
 



Senior Coldfusion Developer

Peter Tilbrook

unread,
Apr 24, 2007, 7:51:17 AM4/24/07
to cfau...@googlegroups.com
Andrew must be the bees knees and lifelong expert for CFML development.

Can I still extend my MyLar sails, catching the solar winds and saving the planet?


Simon Haddon

unread,
Apr 24, 2007, 9:14:56 AM4/24/07
to cfau...@googlegroups.com
Hi,

I think that when to check in a file is a deveopers choice.  Sure you want to check in working units of work but it is also good for placing a checkpoint of your code.  Or even for placing a CFC in with just the API defined.  It doesn't realy matter.  It is your change/release management that is the important bit and how you set that up.

Just my 2 bits worth

Cheers,
Simon
--
Cheers
Simon Haddon

Andrew Scott

unread,
Apr 25, 2007, 3:16:46 AM4/25/07
to cfau...@googlegroups.com
Peter,
 
At least with my expereince and knowledge I earn more than $21 an hour.
 
I also did say it will open a debate...
 
The reason being is that people do their development differenlty, and I stand by by my comments on this matter.
 
If I as a developer was to make changes to the code, and its not finished on what I am doing why would you commit to SVN, that is just not common sense.
 
We here have deployed strict development methodologies, and believe me when I say it works. And if a developer commits code that breaks all build checks etc then they are questioned as to why the code is broken. This has come from the Java side to make sure that builds are as stable as possible when commiting to SVN.
 
And Peter, if you want to learn this methodology and practice, you just might ern yourself more than $21 an hour.
 
I don't claim to be a guru at anything, but when it comes to common sense SVN is not just to commit into willy nilly, and a developer should take the care to make sure that the code they are committing is considered final code is that so hard to understand?
 
What do you think Version Control is all about Peter?


 
On 4/24/07, Peter Tilbrook <peter.t...@gmail.com> wrote:
Andrew must be the bees knees and lifelong expert for CFML development.

Can I still extend my MyLar sails, catching the solar winds and saving the planet?

AJ Mercer

unread,
Apr 26, 2007, 3:31:48 AM4/26/07
to cfau...@googlegroups.com
If you SWITCH between the trunk and branches with out doing a commit, wont you loose your changes?

Andrew Scott

unread,
Apr 26, 2007, 5:34:59 AM4/26/07
to cfau...@googlegroups.com
yes that is correct.

Pat

unread,
Apr 26, 2007, 8:10:18 PM4/26/07
to cfaussie
I have another take on this subversion issue...

1. we use a shared development server instead of each developer
having their own working copy.

why ?
a. designers & project managers have no idea about subversion. they
want to see what the current state of development is by looking at the
dev server.

b. when you work on a large nubmer of sites that can have over 7000
coldfusion templates and integrates with X number of 3rd party web
services, java components and databases, the sheir amount of
configuration required to get developers machines configured is too
large.

its easier to tackle the problem from a project management perspective
and breakdown the work into descrete sections so developers don't work
on the same files.

2. we branch when the change is large enough to span more than a day
and will prevent other devs working on the site at the same time. Our
branches become separate working copies on the same dev server.

once the branch is deployed we merge back into the trunk.

3. we pre and post tag updates to the trunk when bug fixes occour and
when a release is deployed to a testing or production server. testing
and production are not working copies but releases of the codebase.


while this method isnt the traditional svn model, and you may or may
not get all the benefits that SVN offers it still gives you some
version control, it does minimise configuration and merging issues.

my 2c

Pat

ps. does any1 know of any educational institutions that do ANY kind of
version control courses ? tafe, uni, pvt training compaines ? this
seems like such a critical element of being a commercial developer and
i have never heard of it being taught. everyone seems to just have to
pick it up on the run when they start working - its a little sad.

On Apr 26, 7:34 pm, "Andrew Scott" <andrew.sc...@aegeon.com.au> wrote:
> yes that is correct.
>

> On 4/26/07, AJ Mercer <ajmer...@gmail.com> wrote:
>
>
>
>
>
> > If you SWITCH between the trunk and branches with out doing a commit, wont
> > you loose your changes?
>

> > On 4/25/07, Andrew Scott < andrew.sc...@aegeon.com.au> wrote:
>
> > > Peter,
>
> > > At least with my expereince and knowledge I earn more than $21 an hour.
>
> > > I also did say it will open a debate...
>
> > > The reason being is that people do their development differenlty, and I
> > > stand by by my comments on this matter.
>
> > > If I as a developer was to make changes to the code, and its not
> > > finished on what I am doing why would you commit to SVN, that is just not
> > > common sense.
>
> > > We here have deployed strict development methodologies, and believe me
> > > when I say it works. And if a developer commits code that breaks all build
> > > checks etc then they are questioned as to why the code is broken. This has
> > > come from the Java side to make sure that builds are as stable as possible
> > > when commiting to SVN.
>
> > > And Peter, if you want to learn this methodology and practice, you just
> > > might ern yourself more than $21 an hour.
>
> > > I don't claim to be a guru at anything, but when it comes to common
> > > sense SVN is not just to commit into willy nilly, and a developer should
> > > take the care to make sure that the code they are committing is considered
> > > final code is that so hard to understand?
>
> > > What do you think Version Control is all about Peter?
>

> > > On 4/24/07, Peter Tilbrook < peter.tilbr...@gmail.com> wrote:
>
> > > > Andrew must be the bees knees and lifelong expert for CFML
> > > > development.
>
> > > > Can I still extend my MyLar sails, catching the solar winds and saving
> > > > the planet?
>
> > > > Aegeon Pty. Ltd.
> > > >www.aegeon.com.au
> > > > Phone: +613 8676 4223
> > > > Mobile: 0404 998 273
>
> > --
> > If you are not living on the edge,
> > You are taking up too much space.
>

> --


>
> Senior Coldfusion Developer
> Aegeon Pty. Ltd.www.aegeon.com.au

Andrew Scott

unread,
Apr 26, 2007, 8:18:10 PM4/26/07
to cfau...@googlegroups.com
Pat,

That is very bad and here is why!!

First of all, it isn't very hard to setup up a staging server, and when that
is done and your happy that the build is stable you can export to the
staging server.

But the biggest headache for this model is down time, every time I have come
across this development scenario I have quickly changed it there is nothing
worse than another developer with broken code that effects you from doing
your work. And how are you going to explain the downtime due to another
developer breaking a stable build?

There are no excuses for not having a separate development (developer
workstation) and a separate staging/testing server.

Andrew Scott
Senior Coldfusion Developer

Haikal Saadh

unread,
Apr 26, 2007, 8:47:30 PM4/26/07
to cfau...@googlegroups.com
Good god. You've brought back nightmares of what our setup was like 2 or
3 years ago. Someone would run a big query, bring the server down, and
it was time for a coffee break while the server rebooted. Or worse.
Someone would get confused and overwrite someone else's changes, and
shouting matches would ensue.

We eventually switched to having separate JRun instances. Then, 'bad'
developer's instances could be restarted without impacting on others.
Then we got SeeFusion (If I could name one CF tool worth paying for,
this would be it). We could kill just 'bad' requests then. It was nice.

It breaks my heart to see technical people have to suffer because
management don't get it. It a techie didn't 'get it', their ass would be
out on the streets. But I digress...

Don't know if proper version control is being taught at formally at
unis. I used rather primitive version control, in the form of zipped up
directories when at uni. Eventually that got replaced by Eclipse's built
in history. When I started work, jumping over to CVS was quite a natural
progression. (Although the software, wincvs, was still painful). Now,
I'm happily using subversion from within eclipse.

To branch and tag with with the sort of convoluted assignments they give
at uni would be a bit of overkill. Now, if Aussie unis got students more
involved in real software projects, ala Google Summer of Code, that
would be a different story.

There are a number of 'how to do it right' documents for various version
control systems out there, for those who care to look.

/Waffle on, Australia.

Pat wrote:
> I have another take on this subversion issue...
>
> 1. we use a shared development server instead of each developer
> having their own working copy.
>

> *snip*

Pat

unread,
Apr 26, 2007, 8:49:59 PM4/26/07
to cfaussie
in our experience of using shared development the downtime is minimal.
and who do you have to explain it to ? downtime on testing and
production servers is another issue, but while your in development if
someone changes something that breaks what your working on, they will
know about it very quickly.

The difference is in the time to integrate changes. Your delaying your
integration to (usally) daily we are doing our integration instantly.
If your having major integration issues its usually a symptom of
project management and a problem with work breakdown structure.

maybe this model doesn't work in every development scenario, but it
appears to work for us. I wouldn't dismiss it just because its not the
standard approach.

Pat

Andrew Scott

unread,
Apr 26, 2007, 8:57:22 PM4/26/07
to cfau...@googlegroups.com
Pat,

The downtime is when you try to fix a bug in your code, that was introduced
by another developer piss farting around in the same code. Trust me, I do
not care what you think this is the worst way of developing in a team
environment than you can imagine.

Ok, let's say a developer needs to go in and modify some code that is stored
in the Application scope. But to reset the application will mean everyone
has to stop what they are doing or suffer problems, interruptions like this
is downtime.

Or a developer makes a change to something that works for him, but when it
comes to you that code breaks before your code can execute, so you either
have to wait till he fixes that code or you go and fix it yourself, more
downtime.

If you strongly believe it works, then good for you. But those of us who
have been around long enough know better, and we know that this is the worst
thing you can ever do.

Pat don't preach to us, we have been in that scenario and we WILL NOT
recommend it.

Andrew Scott
Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613  8676 4223
Mobile: 0404 998 273

Pat Branley

unread,
Apr 26, 2007, 9:07:35 PM4/26/07
to cfaussie
not preaching, just offering an alternative. You might not like it,
but it works for us.

and you would have to admit that it is better than NO version control.


On Apr 27, 10:57 am, Andrew Scott <andrew.sc...@aegeon.com.au> wrote:
> Pat,
>

> The downtime is when you try to fix a bug in your code, that was introduced
> by another developer piss farting around in the same code. Trust me, I do
> not care what you think this is the worst way of developing in a team
> environment than you can imagine.
>
> Ok, let's say a developer needs to go in and modify some code that is stored
> in the Application scope. But to reset the application will mean everyone
> has to stop what they are doing or suffer problems, interruptions like this
> is downtime.
>
> Or a developer makes a change to something that works for him, but when it
> comes to you that code breaks before your code can execute, so you either
> have to wait till he fixes that code or you go and fix it yourself, more
> downtime.
>
> If you strongly believe it works, then good for you. But those of us who
> have been around long enough know better, and we know that this is the worst
> thing you can ever do.
>
> Pat don't preach to us, we have been in that scenario and we WILL NOT
> recommend it.
>
> Andrew Scott
> Senior Coldfusion Developer

Reply all
Reply to author
Forward
0 new messages