How can I rename a committed branch in tortoise SVN without loosing history. My senior has come up with the new naming convention and he wants me to follow it throughout on all committed branches. Can anyone suggest?
Rename the branche:
$ svn move https://server/repos/myrepo/branches/oldbranch\
https://server/repos/myrepo/branches/newbranch
Do an update:
$ svn update
Don't forget to switch any working copies of the old branch with:
$ svn switch URL of the new branche
Related
I reverted the committed files using svn command
svn merge -r:73:68 http://my.repository.com/my/project/trunk
svn commit -m "Reverted to revision 68."
I have to recommit the revision number 73 changes again, is that possible?
I have to recommit the revision number 73 changes again, is that
possible?
You can't and you don't have to. One of the key features of SVN is that revision history in Subversion repository is immutable.
You can't rewrite the history of changes, but there should be no problems to commit this change as a new revision.
Read SVNBook | Undoing Changes.
Its not really needed to re-write the history and there is no real feature in svn too. Its always good to maintain the entire history. So the possible solution would be, Modify the changes and commit back which will create one more revisions.
When I need to save my changes from one branch before checking out to another branch, git sometimes says: stage or commit the files before you can checkout to another branch. But I have been recommended to use stash option so:
Stage the files is not enough to save my files before checking out to another branch?
What are the differences between stage and stash files?
Thanks
1.- More than "save" your files, is act as Git expect to according their flow. (Advice, Git knows :) )
2.- Stash will move your modified files into a stack. So, later in the same or in another branch, you will be able to bring them back and see those modifications in your project.
Stage is the step before to make a commit, you add modified files to "Staged files" to create your next commit.
Now, you stash your files with
$git stash
and you add files (stage) with
$git add
Now, why is better stash your changes than staging them?
Maybe this part of the documentation can solve your doubts:
From documentation:
Stashing:
Often, when you’ve been working on part of your project, things are in
a messy state and you want to switch branches for a bit to work on
something else. The problem is, you don’t want to do a commit of
half-done work just so you can get back to this point later. The
answer to this issue is the git stash command.
See the links below :
Git Stashing Doc
Git Add Doc
Staging example
Git Basics
It's better to ask difference between stash vs commit and not stash vs stage.
You can not checkout to another branch before commit or stash current changes.
Therefore, if you want to not commit your changes, and also want to checkout to another branch, solution is to stash current changes, checkout to another branch. And after returning to first branch, you can apply stashed changes.
First, sorry for such a confusing pesky title, I really can't find a better way to describe this (would appreciate any changes suggested to post).
The problem
I synced a github repo. And also modified some files and codes inside according to my needs. But if I want to resync and update my tree to latest commits.
will my changes be overwritten?
Or will repo simply ignore modified files and move on to other files?
Or will there be patching process (I dont think this would be case since chances of problems with auto-patching are quite high)?
My guess is that it skips over modified files. And I may need to manually get the new commits from repo. But how to determine which files that have been modified have new commits? I just want to determine it, then probably manually fetch and modify them manually.
To clarify:
Consider files named "abc" and "def" which I modified.
The repo owner updated his repo with a lot of new commits.
I ran repo sync and it synced all files to newer commits except those I modified. Now how do I determine if the files that repo owner updated include "abc" and/or "def" too (assuming I myself modified a lot of files, so I can't manually check if each file has new commit or not)?
I don't want to see what files I have modified or a complete list of files with new commits, I just want to see if the files that I modified have new commits or not.
Is there any such possible way?
I do know how to determine files that are changed using `git status,
but how do I want to check if those changed files have any new commits.
When running repo sync, Repo will rebase any non-published topic branches (i.e. branches you haven't uploaded to Gerrit with repo upload).
Or will there be patching process (I dont think this would be case since chances of problems with auto-patching are quite high)?
Git will try, but if there's a conflict that it can't resolve by itself you have to step in and help out.
Consider files named "abc" and "def" which I modified. The repo owner updated his repo with a lot of new commits. I ran repo sync and it synced all files to newer commits except those I modified.
No. Either Repo rebases your branch (and updates/merges all files) or it doesn't do anything and it's up to you need to rebase or merge from the upstream. Git never does partial updates.
I dont want to see what files I have modified or a complete list of files with new commits, I just want to see if the files that I modified have new commits or not.
I think you're asking the wrong question, but sure, you can list the commits that modify a particular set of files or compare two commits and only display the differences in a particular set of files. Both git diff and git log accept one or more paths to files that you want to restrict the output to. To find the files you can use git ls-files -mo to obtain dirty files and untracked files in your workspace, git diff-tree --name-only -r HEAD~..HEAD to get the files modified by the most recent commit, and so on.
Putting it all together, the following command fetches the most recent state from the upstream and shows the new commits (git log HEAD..origin/master) that touch upon files that you yourself have modified on the current branch since the last update from the upstream (git diff-tree --name-only -r origin/master..HEAD):
git fetch
git log HEAD..origin/master -- $(git diff-tree --name-only -r origin/master..HEAD)
A Unix-like shell is assumed. On Windows things may look differently.
You can use git hook to track the list of files.
In your post-receive hook search for the given file and do what ever you need to do.
Another option is to track it manually using the follow flag
git log --follow <path>, it will print out the list of changes made to the given file in each commit
My project directory inside trunk has been accidentally deleted by another user.
I can see my project when browsing it through the web at one revision (364), but the top of the tree it is missing (370)
How do I undo those commits and get my source tree back using the command line subversion client?
EDIT:
Thanks for all the hints. It was a combination of answers that helped me solve it. Although Avi's answer is the closest to the one that allowed me to restore the source tree. So I'll accept that. Although to be totally correct, below is what worked for me since even the trunk directory was eventually removed!
Final solution was:
svn cp https://xxx.xxx.xxx/url/trunk#364 https://xxx.xxx.xxx/url
I then checked this out locally:
svn co https://xxx.xxx.xxx/url/trunk
Copied my changes into this. Double check it builds without issues.
Followed by:
svn up
svn commit
You can copy it back to the current revision:
svn cp -r<revision where it existed> <project-url> <project-url>
EDIT:
Note that if you have changes to your working copy, you need to take care that they don't get overwritten when updating the working copy.
In this case, I suggest you copy them somewhere safe, then doing the svn cp I suggested above, and doing svn up to update your copy, before copying your local changes back in and committing.
svn up -r[revision]
Find the revision number first by doing svn log
I'm using TortoiseSVN without an external Subversion server to manage LabView source (i.e. a large collection of ever-changing binary files).
I'd like to have a "beta" branch of the repository that anyone can subscribe to and get daily updates. I guess this is different from a usual beta release series with separate branches, but it's right for this project.
What is the best/easiest way to copy the contents of a particular revision of the trunk branch over to the beta branch? Essentially what I want to do is delete the old contents of beta and insert new contents. Delete+add would work, I suppose, but it's clearly suboptimal. Merge is not an option unless I can get Tortoise to automatically resolve all conflicts in the trunk's favor, including deleting files.
Update: a couple people have asked why I don't want delete+add. I'd like a cleaner alternative.
This method leads to half the updates to the beta tree being "wipe out last rev."
The updates are not atomic so someone could pick up an empty release.
I haven't tried and seen, but beta wouldn't be a proper branch. Would the revision log even track multiple revisions at all, since it's a "new" file each time?
Update 2: svn allows any arbitrary commands before a commit, but I couldn't get Tortoise to work this way. After selecting "Delete," stub directories were still left over until I committed, at which point I could repopulate the branch. There needs to be a way to unmark a directory for deletion when it exists in both the old and new tag revisions.
Merge is not an option unless I can
get Tortoise to automatically resolve
all conflicts in the trunk's favor,
including deleting files.
I don't know about TortoiseSVN, but if you install the command line client you could do the following to merge the latest trunk changes to a beta branch:
cd c:/path/to/my/working/copy/of/beta/branch
svn merge file:///c:/path/to/my/repository/trunk --accept theirs-full
svn commit -m "merged latest trunk changes to beta branch"
The --accept theirs-full option resolves all conflicts by using the trunk's version like you want.
This has some advantages: subversion will do representation sharing, so files stored on both branches will not take extra space in the repository. Also, when users update their beta working copy, only the files that were changed need to be pulled over the wire.
SVN is transactional - a delete and copy (not add!) would not be problematic. And beta would be a proper branch (or better a tag)
Why not delete beta/* and then copy trunk/* to beta/ ?