I'm confused by your description of the tagging process.
A tag can be viewed as a branch where no development is ever done.
Subversion implements it like that:
1) Everybody checks in their code. Now the trunk is at RC 1.1
2) svn cp http://path/to/rep/SomeProject/trunk
http://path/to/rep/SomeProjects/tags/RC_1_1
How is this different from your CVS procedure?
On May 5, 2005, at 1:17 PM, Michael Muller wrote:
>
> I'm considering moving from CVS to subversion, but I'm having trouble
> making subversion work with my company's development process.
>
> My company builds a lot of small-to-medium web sites, mostly in PHP.
>
> In CVS, a developer can mark a file in his sandbox as a "release
> candidate" by tagging it "RC": cvs tag -F RC index.php
>
> This is a pretty simple command, and it's really easy to execute with
> tortoise as well, simply right-mouse on the file, select "tag" and
> enter "RC" in the dialog box.
>
> When we're ready to do a release, we update our staging sandbox
> (everything tagged "RC"), test, tag it as "release 1.1", and push it
> to production.
>
> Here are my problems:
>
> 1) The syntax to perform the equivalent in subversion is too complex.
> I'm under the impression that I need figure out the version numbers
> involved, merge, and then commit. I could write a script that does
> this, but that still doesn't help the people that use tortoise.
>
> 2) It introduces the possibility for error. Before we had version
> control, our developers used to drag and drop files from their work
> areas into the staging docroot. Often, they'd goof and drag an
> "index.php" into the wrong folder. Using tags to move files to
> staging solved this problem, but with subversion you have to enter the
> path name twice re-introducing the possability of promoting a file
> into the wrong place.
>
> The former is the largest problem for me. I need an easy way to say
> "this version of the file that's in my sandbox should be promoted to
> release candidate status".
>
> I'm a total subversion novice, so I'm hoping that there is a simple
> way to use subversion that doesn't involve radically changing the
> development process at my company. Does anyone have any suggestions?
>
> Thanks,
>
> -- Mike
>
> P.S. To complete the thought that I started in my subject line, I
> really like subversion's branching; it's much simpler conceptually
> than CVS's model.
>
> --
> Michael Muller
> Senior Application Developer, Inter@ctivate, Inc.
> 2503 Walnut Street, Suite 301 Boulder, CO 80302
> http://www.interactivate.com
> phone: 303-442-1740
> fax: 303-442-1750
>
> This message is intended only for the use of the Addressee and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are
> not the intended recipient, dissemination of this communication is
> prohibited. If you have received this communication in error, please
> erase all copies of the message and its attachments and notify us
> immediately.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 5 20:58:10 2005