[DUG] CVS Software - Suggestions?

[Todd Martin]

Hi Max

Thanks for the example. I know what you mean about the pain of copying 
changes across branches or back into the main development trunk in a 
multi-developer environment.

In case you're unaware, Subversion increments the revision number of all 
files in the repository after a commit. You might find this works just as 
well.

>From the documentation:

In Subversion, a global revision number N names a tree in the repository: 
it's the way the repository looked after the Nth commit. It's also the name 
of an implicit changeset: if you compare tree N with tree N-1, you can 
derive the exact patch that was committed. For this reason, it's easy to 
think of "revision N" as not just a tree, but a changeset as well. If you 
use an issue tracker to manage bugs, you can use the revision numbers to 
refer to particular patches that fix bugs-for example, "this issue was fixed 
by revision 9238.". Somebody can then run svn log -r9238 to read about the 
exact changeset which fixed the bug, and run svn diff -r9237:9238 to see the 
patch itself. And Subversion's merge command also uses revision numbers. You 
can merge specific changesets from one branch to another by naming them in 
the merge arguments: svn merge -r9237:9238 would merge changeset #9238 into 
your working copy.

Todd.

----- Original Message ----- 
From: "Max Nilson" <max at accredo.co.nz>
To: "'NZ Borland Developers Group - Delphi List'" <delphi at ns3.123.co.nz>
Sent: Friday, November 24, 2006 3:13 PM
Subject: RE: [DUG] CVS Software - Suggestions?


>> Max, when are change sets superior to file deltas?
>
> A good question!
>
> Thje main difference is that a change set is a set of deltas to one or 
> more
> of files. The reason you need this is so that merging changes that are
> dependant on multiple files you get all you want and nothing else. Also a
> change set is an atomic unit, and so all the files changes are applied in
> one operation, preventing any partial merges into a source tree.
>
> An example will make this more clear. Suppose that you fix a bug in your
> application that requires some library changes to a couple of files and 
> some
> changes to your main forms and data modules. You pass the bug report back 
> to
> the testers and get on with life, and fix more bugs/make additions some of
> which are in the same files you changed before.
>
> Now the testers report back and say that things are sweet and its time to
> merge the changes into the release branch version the tree.
>
> Using perforce you simple merge the change set from the development branch
> into the release branch and rebuild the release.
>
> If you are using a files based system (aka most others) then you have to
> manually try and figure out which deltas to the file(s) are for that bug,
> and which are later changes for other bugs/features. This causes much pain
> and suffering, especially if there are dependant changes.
>
> Now all this is not so much of a problem if you don't run separate
> development and release branches, but that has its own problems. Like when
> its release tim and you need to get a stable build created you either have
> to stop the team working and simply try and fix bugs for a release, or you
> have to branch the source and try and create a stable tree by fixing or
> removing stuff you don't want released.
>
> It gets worse if you make stability fixes to a release branch, and then 
> try
> and merge those changes back into the main development branch, when these
> collide with on going development. Been there and suffered that.
>
> Its basically a scaling issue, where CVS et al work OK for single 
> developers
> or very small teams, but can't be scaled to a large teams, or teams that 
> do
> RAID development and submit a lot of changes.
>
> Our team has created 14810 change sets over the last few years, and we 
> work
> on a minimum of four branches at once, with 5 plus developers, some of 
> which
> work from home a lot of the time. We have had to figure out how to make 
> this
> work and Perforce is in the only product on the market that lets uus work
> this way with minimal pain.
>
> Cheers, Max.
>
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.14.14/547 - Release Date: 
> 22/11/2006
> 



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.14/547 - Release Date: 22/11/2006