I have a bunch of files that I've changed that I don't really want to commit, but I would like to back them up locally in case I would like to use them again. (Then I'll revert them.)
TortoiseSvn working status helps to view the modified files, but I want a way to save them all to a separate directory like Backups\, preferably with their folder heirararchy still in tact.
How can I do that?
UPDATE:
Apparently branching is the way to go.
But what I did was just copied the modified files paths to the clipboard (which is an option in tortoisesvn) then to a file, and created a program to copy them to a backup folder.
You can create a branch and commit those files only in that branch.
You can commit it inside a branch, so it doesn't affect your current 'trunk' or branch.
If you had a try with bazaar , that is compatible with SVN, there is a shelf command to temporarily store a set of modification and apply back them later.
Related
I have added a file (say SomeFile.cs) to a specific folder. I did not commit as I wanted to do commit at once after achieving the functionality. An svn update worked just fine on this until someone changed the folder name and changed the names of files under it.
Now the next day when I did svn checkout, resulted in tree level conflicts, so I copied my newly added files to this "new" location and did as "Resolve using theirs".
The resolve deleted all my local files and replaced with new folder and files. I could not find my local files (which were in my working copy) in my entire computer (includint recycle bin).
Now is there at least an option to retrieve the files which were added ("Add" option) to svn and NOT committed to svn using "Commit"?
Regards
AFAIK, only files committed to svn will be recoverable. But if you merge the conflict with theirs, then it would have overriden the changes locally.
Try to "Update to revision", but as your files were NOT committed it will most likely restore your directory structure in best case scenario.
Generally "Resolve using theirs" option is an equivalent of saying "I screwed up, they are right" -> whatever I have is wrong, and what they have is right -> overwrite my copy.
What you are asking for is pretty much against the workflow of SVN. Things don't get stored in the repository until they are committed, and are thus not "safe". You are supposed to commit often.
If you are trying to work but worried about other people's tree changes getting in your way, consider making a branch.
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html
However, SVN should never overwrite files in your local working copy that have modifications. If you do an svn update, and someone has added/changed something, you will get a "conflict", which you will have to resolve manually. You resolved these conflicts manually, and accidentally overwrote you work. This is why you should commit often. Anything you commit can be recovered.
I am trying to figure out svn:ignore. I am using:
svn propedit svn:ignore file://path/myrepository/project
Within there I am adding 'files' to that and then saving. It commits the revision fine. When I now go to a machine to SVN Update it, it downloads the files directory. How come that isn't applied? With SVN, do you need to apply things by doing some sort of restart? I am using a Red Hat Linux box.
Thanks.
EDIT:
Looks like I misunderstood ignore.
svn:ignore only works for untracked files. once you have added a file to your repository it cannot be ignored again (unless removed again). Why should you ignore a file that you initially wanted to track?
svn:ignore only saves you from accidentally adding garbage (build products, backup/swap-files, log files, etc.). It will not forbid downloading of files from the repository (if I understood your last sentence)
I've been using Tortoise SVN + Visual SVN for about a year since left the corporate world to do my own startup. There's one feature in Tortoise SVN that I've never figured out:
How can I bundle up a bunch of changes into a PATCH or DIFF file and either: A) share them with my co-founder; or B) archive them into a standalone change that I can either "apply" or "revert" on my dev box?
At my previous employer, we used an internal tool that let us build so-called DPK files that contained a set of local changes. You could add changed files to the DPK and then share it with colleagues. They could either review the changes in a Diff tool or apply all the changes from the DPK to test your change on their box. After the review was complete, you could then check in these changes. You could also have multiple DPK's applied at the same time (provided you didn't have overlapping changes).
I want to achieve the same thing with Tortoise SVN + Visual SVN in the VS2010 IDE.
My real-world scenario is that I have some extensive change pending but uncompleted on my box. I want to ZIP up these changes and store them in a DIFF file, revert the changes, move on to something else, work on that, and in a few days reapply my changes from the archived DIFF file.
Reluctantly answering my own question. This feature is available with Tortoise SVN. Basically, you make a PATCH file, distribute it or archive it, and then you apply the PATCH. The only trick is to make sure you're in the right location in the WC (Working Copy) when you do the "apply". When you apply, you'll get a popup menu to the left with a list of all files in the changelist. You can apply the patches one by one or in bulk. Seems to work great. I should have drilled into the docs more before posting this question.
Here's the text for picking the location:
"Patch files are applied to your
working copy. This should be done from
the same folder level as was used to
create the patch. If you are not sure
what this is, just look at the first
line of the patch file. For example,
if the first file being worked on was
doc/source/english/chapter1.xml and
the first line in the patch file is
Index: english/chapter1.xml then you
need to apply the patch to the
doc/source/ folder. However, provided
you are in the correct working copy,
if you pick the wrong folder level,
TortoiseSVN will notice and suggest
the correct level."
Be sure to pick the location carefully. If Tortoise SVN can't find it because you selected the wrong node in the VS file explorer, it will try to find a matching location and that might be wrong. In my tests, the Patch feature actually tried to map to a branch (!!) when I specified the wrong location.
Here's the relevant link:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html
I wish to check my changes into a different branch than the files were check out from. All the files there are the same “version” in each branch, Perforce should know this from tracking the integrations that have been done. (So no merging need to be done)
According to the Perforce Blog, the p4 move -f command will move your edit from one branch to the other. From the blog
This can be a real lifesaver if (as I did a few weeks ago) you start working on a fix in your mainline, and then decide that it needs to go into your release branch instead. Previously you would have needed to save a copy of your work, revert it, open the files in the release branch, and copy your edits back in manually — now you just “p4 move -f main/… rel/…” and all your edits go where you need them.
This is a new feature added in version 2010.1 (this year I believe) so that's probably why tech support didn't know about it.
Use "p4 move" if you have version 2009.1 or later. Just move to the new branch and revert from the old branch.
I just got an answer from support#perforce.com
You cannot check files into a branch
that they weren't checked out from.
You need to open those other files for
edit and copy your changed files over.
(I am now beginning to understand why pressure is building up from some the programmer I work with to to move to Mercurial)
I want to get files from Perforce without putting them into a workspace.
E.g.
I have made changes in 2 files.
file1.cs
file2.cs
Now I want to build the project using updated file1.cs, so I want to get latest files except for file1.cs.
I thought I will get another local copy of project and build it.
I'm not sure what you really want to do, but you can get the contents of a file from the depot without using a workspace definition by using "p4 print". Example:
>p4 print -o fileName.cs //depot/path/to/fileName.cs
As far as I am aware you cannot sync files from a Perforce depot without using a workspace since this is the way it tracks what version of files you have in your workspace and also where to put them on your local machine (as well as a few other things).
I'm not sure I entirely understand your problem but if what you need to do is get another copy of the file1.cs you have in the depot without removing the changes you have to it you can simply copy the changes to another location or shelve them and re-sync the file. The more complete and less dangerous solution is to create another workspace pointing to a different physical location on your machine but the same depot location.
This explains how to create a workspace if you need it:
http://www.perforce.com/perforce/doc.062/manuals/boilerplates/quickstart.html
Make sure the 'Root' path is different to that of your current workspace, you can check what your current workspaces root is by going to the workspace tab in P4V and viewing it.
Once you have created the new workspace create a new connection and select it then sync the file(s) you need.
So I want to get latest files except file1.cs
You shouldn't do that; you should update all files and resolve any conflicts with file1.cs
Consider the situation where someone else has made changes to file56.cs that relies on changes also made to file1.cs. If you take their changelist but overwrite (or do not take) their file1.cs, then your build will break.
Shelve file1.cs so you can safely revert your local change:
p4 shelve file1.cs
p4 revert file1.cs
Now you can do your build with whatever version of file1.cs you want (you can sync back to an older version or whatever).
When you're ready to return to your change:
p4 unshelve -s CHANGE
If you're in the UI you can use File->Export To... which will copy the selected file to any folder you want.
I found the workaround but not the solution.
I get another local copy of project then build the project and submit the change.
I found an easy way of doing this with git:
$ git p4 clone //depot/your/folder