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
Phone: +613 8676 4223
Mobile: 0404 998 273
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.
Aegeon Pty. Ltd.
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
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
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?
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
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
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*
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
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
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