I want to replace my working copy to a tagged version, I choose replace with > tag, but then in the popup menu, there is no tag to choose, just revision.
if I only know the tag but not the version, then no method to replace with?
also, many criteria is undocumentated, like the "Depth:" combo box, what is its use?
The dialog you displayed is used when attempting to replace a file or subdirectory of the working copy (local project files) with files from a branch or tag (the difference between branches, trunk and tags internal to Subversion is minimal). Since each file and directory of each branch and tag in the SVN repostitory has a unique URL, that is the URL you'd enter into the "To URL" box of the dialog. In other words, update your working copy "To URL xxxxx" - it doesn't mean sending the working copy "to a URL".
Mostly you can leave the other items at their default values. I've never had to change them myself.
There are also project-wide ways of pulling a tag release in to work with, instead of just plundering selected files from it. You can either:
1. Use the Subclipse Team/Switch to Branch/Tag/Revision menu option to replace your entire project working copy with a working copy of whatever branch, tag or revision you select.
2. Check out completely new project from that Branch, tag or revision. If you do that, you'll end up with 2 independent copies of the project in your workspace (the original plus the copy you just checked out), each with its own unique name.
An IDE is no substitute for an Intelligent Developer.
Joined: Mar 15, 2008
Use the Subclipse Team/Switch to Branch/Tag/Revision menu option to replace your entire project working copy with a working copy of whatever branch, tag or revision you select.
if using these method and I replace my entire project working copy with a tag, then when I commit again, will it be in trunk or in where? (I want it will commit to trunk)
If you "switch" to branch/tag, it will commit back to that branch or tag. To commit to the trunk, "update" from a branch or tag, instead (assuming that your working copy commits to the trunk.)
You can always tell where the commits will go - the archive's name lists next to the project name in the Project Explorer.
As far as direct commits to the trunk go, I'm not too keen on that these days. I do production builds from the trunk, and when another worker committed code that hadn't cleared Beta, I ended up having to do painful things to keep the production updates coming until we can get Beta back in line. So I favor having people work on branches and then getting someone to co-ordinate all the branches into a single trunk merge.
Joined: Mar 15, 2008
"update" from a branch or tag
I right click the project and select team, there is no "update from a branch/tag", just update to HEAD or update to version, and if choose "update to version", the popup screen only allow me to update from a version in trunk, but not a tag in tags folder.
What I want to do is copy the source in tag to my working copy and later I can commit it to trunk, I think this task is quite usual, but why seems so difficult in svn?
First, define "copy to". It makes a major difference.
If you literally want to replace everything that's in your current working copy with what's in a branch, then effectively you have to delete the current working copy, then download the branch copy. You can do this in a single step by using the Team/switch menu. It may prompt you to commit (or discard) any currently uncommitted changes to the current branch or tag.
On the other hand, if you have stuff that you want to keep that's in your working copy, but you want stuff that's in a branch or tag, you have to merge the two because typically, there will be 2 versions of most of the files and you need to determine what code you want to keep from which file. Which might be to retain the original working version, to mix and match changes from the 2 versions, or to replace the original version completely. That's a decision that has to be made by you separately for each file according to your needs.
Once you do a merge, it's a good idea to commit those changes to a branch before doing any new updates, just in case you lose something and don't want to do it all from scratch again. In that case, you'd use the Team/Branch/Tag... menu to create new branch/tag version. Tell the wizard that you want to create this branch (or tag) from your working copy - the default is that it will just clone the HEAD version that's in the repository. Finally, on the last page of the wizard sequence, there's a checkbox to tell Eclipse that it should switch to that newly-created branch/tag. That will switch the Eclipse project's backing SVN branch (whose name appears next to the project name in the Navigator). Whenever you do a SVN commit, it commits by default to the branch/tag that the Navigator indicates.
Joined: Mar 15, 2008
literally want to replace everything that's in your current working copy with what's in a branch
yes, this is what I want, I want to replace everything in my current working copy with a version in TAG
but that I want the working copy can commit back to TRUNK, not TAG, is it possible?
think a case, assume after I create a tag and then I still work on my working copy in trunk, and after several change I want discard all these thing and work back from the tag version, I copy all things from the tag version to my working copy and then after I start work back from tag version, I want commit the new change to trunk.
trunk is the developing version, tag is a snapshot of a build version, right?
I think it is quite normal to want work back from a build version (tag) and then continue commit to trunk.
but from the attachment, it show that after I switch to a tag, then the commit will also to that tag, not trunk.
Well, in my case, trunk is the production version, but it's also used for mainline development.
The thing to remember is that in SVN, "branches", "tags" and "TRUNK" are not magical objects. They're all just directories. It's only usage convention that makes the difference. Although the subclipse plugin figures that you're following the usual convention and operates under that assumption.
You could go for a brute-force approach, but here's a process that, while a little more complicated, is more of a best practice:
1. If you have uncommitted changes in your working copy, commit them to the branch in SVN so that you have a permanent archive that's in sync with what's on your local system.
2. If you have enough disk space, you can check out a copy of the TRUNK under an alternate project name so that you have both projects on local disk. OR, simply use the Eclipse Team/Switch menu to replace the current project with TRUNK.
3. Use the SVN MERGE to update the checked-out TRUNK with your tagged version.
4. Once you've dont that (resolving any conflicts), you should be able to commit the merge changes back into the TRUNK
5. From that point on, work with the newly-updated trunk in the usual way, As long as the SVN project indicator in your Project Explorer points to the TRUNK, that's what will get updated.
6. If you kept the original tag project on disk back in step 2 and you don't want it anymore, delete the working copy of that tag from Eclipse.