Correct, Hari. I've already established the tag. Now someone has
edited one file and I want to associate just that one version of that
one file with the tag. I can't tag an entire revision, because other
developers have already checked in other changes that I do not want to
be part of this release.
This is very simple in CVS: "cvs tag -F RC index.php"
This is very complex in SVN. Unless someone can help me, I think it
would take four steps. I'm pretty sure I could write a script to
automate this, but this would not help my users who work using a gui
(tortoise).
1) You need to check out a sandbox with the RC tag, or update an
existing one
2) You need to figure out the before and after version numbers (i don't
even know how you do that)
3) You need to run a big long merge command, something like this:
svn merge -r x:y http://svn.interactivate.com/project/trunk/subdir/index.php
4) you need to commit your changes, providing a comment that i don't need
I'm beginning to come to the conclusion that SVN is not well-suited to
our development model, but I'd love to have someone prove me wrong --
I'm not a huge fan of CVS, either.
Now that I think of it, merging is probably NOT what I want to do; I
wouldn't get the "cheap copies" that makes SVN efficient. If there's a
way to do it with deleting and re-adding (as Hari suggested), that would
probably be better, but still probably too complex for my purposes.
-- Mike
Hari Kodungallur wrote:
> Nathaniel, what Michael is doing is to move a tag for a changed file.
> This is a very convenient feature when you have modified just a
> handful of files for the Release and all (s)he needs to do is to move
> tags for those particular files to the RC tag. There are multiple ways
> to do it in subversion, but all of them require at least two steps
> (merge and commit to tag, remove and add file to tag etc)
>
>
> On 5/5/05, Nathaniel Waisbrot <waisbrot@cs.umd.edu> wrote:
>
>>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
Received on Thu May 5 21:58:18 2005