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 incorporat
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 <[EMAIL PROTECTED]> wrote:
>
> Hi Fusioneers,
>
> I have finally set up
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 considere
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 <[EMAIL PROTECTED]> wrote:
>
> I think this is what I am after
>http://ariejan.net/2006/11/22/svn-how-to-fix-bugs-prope
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
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
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 guilt
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.
*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 look
Someone made a huge deal about "request" vars. And it was not moi lol!
--~--~-~--~~~---~--~~
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 fr
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 cre
On 4/24/07, Zac Spitzer <[EMAIL PROTECTED]> 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 tha
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
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?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"cfaussie" gr
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
If you SWITCH between the trunk and branches with out doing a commit, wont
you loose your changes?
On 4/25/07, Andrew Scott <[EMAIL PROTECTED]> 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 b
yes that is correct.
On 4/26/07, AJ Mercer <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> wrote:
> >
> > Peter,
> >
> > At least with my expereince and knowledge
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 ser
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 dev
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 matc
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 quick
lto:[EMAIL PROTECTED] On Behalf
Of Pat
Sent: Friday, 27 April 2007 10:50 AM
To: cfaussie
Subject: [cfaussie] Re: OT: Subversion
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,
> -Original Message-
> From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf
>
> Of Pat
> Sent: Friday, 27 April 2007 10:50 AM
> To: cfaussie
> Subject: [cfaussie] Re: OT: Subversion
>
> in our experience of using shared development the downtime
23 matches
Mail list logo
