[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with tagging files
Re: Problems with tagging files
Sat, 24 Jul 2010 09:19:10 -0400
Thunderbird 126.96.36.199 (Macintosh/20100228)
-----BEGIN PGP SIGNED MESSAGE-----
> To checkout the new release we just do this
> cvs checkout –r “LIVE-REL-2.5” moduleName
> There is a bit of a confusion as to whether this process actually
> We've suddenly had people complain that they cant check in any new
> files if
> they check out by tag. The error that is generated is shown below
> sticky tag `LIVE-REL-2.5' for file `DatabaseFacade.java' is not a
This exactly proves the other email I just sent - you must use branches
to do what you want. There's no way around it.
> I wish i can do this but i cant seem to be able to convince any of my
> that we should support branching. We dont support it because it
> makes things a lot more complicated than they need to be.
Any scheme you come up with to avoid using branches will be far more
complex, tedious and error-prone than creating and using branches
effectively. Branches are like making left turns while driving (or right
turns, if you normally drive on the left). The turns are more
complicated, but unless you want to be going around in circles your
whole life, you have to use them.
Branches exist to simplify software development. They are a basic, core
concept of any version management software.
CVS has been around for over 20 years, and RCS who knows how long before
that. If branches were the bane of developers' lives, then *nobody*
would use them, and support for branching would have been dropped long
ago. The fact that every major version management tool supports branches
(and some software, such as ClearCase, automatically creates branches)
is a pretty strong testimony to their effectiveness.
Find out what /specific/ objections your bosses have, and feel free to
post them here so we can provide you with effective counter-arguments to
> - Prevent people from checking in files that are not ready to be
> in the next release.
> This might work as i would then be able to just checkout from 'HEAD'
> everytime there is a new release.
That is a bad idea. That means developers can go weeks (or even months)
before checking work into the repository. The longer developers wait to
check in, the harder it becomes to merge changes between different
developers. Not to mention the risk of losing data in the event of a
hard drive failure.
It also does not address the issue of a critical bug that gets
discovered after you have created the release. Even with the most
diligent testing, sooner or later you *will* encounter a bug that slips
through, and absolutely has to be fixed NOW, even though developers have
checked in their work for the next release.
> Now my questions are as follows,
> - Is there some way i can checkout using the above procedure without
> across the "sticky tag is not a branch" error?
> - Is there a better way i can achieve the same steps above without
> having to
> use branching?
> - This sounds to like its one of the most common situations in a
> environment. How do other people do it without using branching?
They don't. They use branches.
> - And finally if you have any knowledge of subversion, do you know if
> works the same way and i will have the same problems if i change to
I haven't used subversion, but I strongly suspect it will have the same
issues. Branches are a core concept of any version management system.
Dreampossible: Better software. Simply. http://www.dreampossible.ca
Consulting * Mentoring * Training in
C/C++ * OOD * SW Development & Practices * Version Management
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----