I am new to SVN , we are using SVN version controller in eclipse (Lunar), We have a module,that module code's may go to Release or may not go to release depends on the business approval, is there any way in SVN to commit/rollback set of changes(different File changes) on single action ?
Thanks & Regards
S.Sathiya
To roll back changes in Subversion while maintaining the history of all events, you need to perform what's known as a reverse merge. You're essentially applying a patch which reverses the changes that were done between "now" and the state you want to roll back to.
You can apply a reverse merge to a whole tree/subtree, or individual elements (files/directories). To make things easy, work in the largest chunks you can manage.
Simply check out the version of the file you would like to have and commit it to the repo. Reverting is a feature to undo accidental whole commits (so it would have an effect on other files too, which is probably undesired). If the whole thing you want to undo is a complete commit, then yes, reverting under the Team context menu or in the history is what you are searching for.
Related
I need preview like in IntelliJ IDEA. Strange that this is not the default behaviour.
Yes very strange. I solved that using the Git Staging view.
Go to Window -> Show view -> Other, and select Git Staging.
There you can see all you need in order to do a proper commit, unstaged changes, changes, even conflicts. And of course you can do a commit or commit and push directly.
I think the idea in Eclipse is to do commits from synchronization view and to be consistent between different team providers. The former comes from old times when CVS and SVN ruled. Nowadays it seems to be a cumbersome way to do it.
Heck, even SVN team providers allow you to revert changes from the Java view while from EGit you can either reset the whole working copy or you need to go to Synchronization view and use cryptic Overwrite option for a single element. Of course changes in files that you're asking about are there.
In my repository I needed to revert to an older revision. I did reverting and made the changes I needed to. How do I push the new revision upstream?
I was on rev 17 when I needed to revert back to rev 13. Now that I've made my changes, I'm on rev 18. Thing is, when I go to push these changes up (I'm using TortoiseHG), I get an error "abort:push create new remote head.
I don't want to do a merge. Do I want to do a force with the --force command or do I need to delete rev 14-17. If I need to delete, how do I delete 14-17.?
Proper solution is to actually merge with option Discard all changes from merge target (other) revision. But sometimes life is harder on us and we really need to drop some changes (eg. we committed nuclear launch codes or some other security sensitive data). Is that your case? If yes then follow.
Assuming that original changes were not published you could:
enable mq extension
r-click on offending changes and execute Modify history->Strip.
This will permanently remove changes from your local history.
You don't want to delete revisions and therefore destroy history. That goes against the reason version control exists.
You can do a merge and discard.
You can also do this in tortoiseHG.
I'm fairly new to Mercurial, but one of the advantages I see using Mercurial is that while writing a feature you can be more free to experiment, check in changes, share them, etc, while still maintaining a "clean" repo for the finished feature.
The issue is one of history. If I tried 6 different ways to get something to work, now I'm stuck with all of the history for all my mistakes. What I'd like to do is go through and clean up my changes and "collapse" them into one changeset that can be pushed into a shared repository. This is complicated by the fact that I might pull in new changesets from the shared repository, and have those changesets intermingled with my own.
The best way I know of to do that is to use hg export to create a patch of my changes since cloning, clone a fresh repository, and apply the patch to the fresh repository.
Those steps seems a little bit cumbersome and easy to mess up, particularly if this methodology is rolled out to the whole dev team, some of whom are a little resistant to change (don't get me started). TortoiseHg makes the process slightly better since you can highlight the changesets you want to be included in an export.
My question is this: Am I making this more complex than it needs to be? Is there a better workflow I can use to ease my troubles? Is it too much to expect a clean history where entire (small-ish) features are included in one changeset?
Or maybe my whole question could be summed up this way:
Is there an equivalent for this in mercurial? Collapsing a git repository's history
Although I think you should reconsider your use of branches in Mercurial (as per my comment on your post), using named branches doesn't really help with your concern of maintaining useless or unnecessary history - it just organizes them a bit.
I would recommend a combination of these tools:
mercurial queues
histedit (not distributed with Hg)
the mq changeset strip feature
to rework a messy history before pushing to a blessed or master repo. The easiest thing would be to use strip to permanently remove any changeset with no children. Once you've done that you can use mq or histedit to combine, relocate, or modify existing commits. Histedit will even let you redo the comment associated with a changeset.
Some pitfalls:
In your opening paragraph you mention sharing changesets during feature development. Please understand that once you've shared a changeset it's not a good idea to modify using mq or histedit, or strip. Using these extensions can result in a change to the revision hash, which will make them look like a new changeset to everyone else.
Also, I agree with Paul Nathan's comment that mq (and histedit) are power features and can easily destroy a history. It's a good idea to make a safety clone before using these extensions.
Named branches are the simplest solution. Each experimental approach gets its own branch.This retains the history of the experiments.
The next solution is to have a fresh clone for each experiment. The working one gets pushed back to the main repo.
The next solution - and probably what you are really looking for - is the mq extension, which can "squash" a series of patches into a single commit. I consider mq to be "advanced", and "subject to accidently shooting yourself in the foot". I also don't care to squash my commits - I like having my version history present for reference.
Is it possible to have different development "paths" from a given point in Mercurial, without having to clone my project? I currently have 2-3 different implementations options for a project and I'd like to try them out. If I could just use one and at any point come back and start in another "path" without losing data from the older one that would be nice, but I am not even sure it is possible.
Thanks
This is exactly what branching is designed for:
https://www.mercurial-scm.org/wiki/Branch
The easiest way to create a branch in Mercurial is to simply checkout an older version, and then commit again with something different from what you committed after it the first time. You won't lose the old following commit, the new commit will simply branch out into a new line of development and the original commit(s) will remain on the previous line of development.
Yes, you probably want bookmarks for this - they're a lightweight way of marking various heads without recording the names forever in the revision (which branches do.) See BookmarksExtension for more details.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ may also be helpful - it's essentially the canonical document on branch management strategies in Mercurial.
I once ran across a commercial tool for Windows that allowed you to "stash" code changes outside of source control but now I can't remember the name of it. It would copy the current version of a document to a backup location and undo your checkout in source control. You could then reintroduce your backed up changes later. I believe it worked with multiple source control systems. Does anyone know what program I'm trying to describe?
The purpose of my asking is twofold: The first is to find a good way to do this. The second is because I just can't remember what that darn program was and it's driving me crazy.
Git: http://git-scm.com/
You can use git stash to temporarily put away your current set of changes: http://git-scm.com/docs/git-stash . This stores your changes locally (without committing them), and lets you reintroduce them into your working copy later.
Git isn't commercial, but is quickly gaining many converts from tools like Subversion.
I think the product you're thinking of is "CodePickle" by SmartBear Software. However, it appears to be a discontinued product.
The term that seems to be used for the type of functionality you're looking for seems to be 'shelving'.
Microsoft's Team system has a 'shelve' feature.
Perforce has several unsupported scripts, including p4tar and p4 shelve
There are several 'shelving' tools for Subversion, but I don't know how robust they are.
I'm no git user myself, but several of my colleagues are, and they seem to like it precisely for this purpose. They use the various git wrappers to commit "real" changes to the SCM system used by their company, but keep private git repositories on their drives which they can keep their changes which they don't necessarily want to commit.
When they're ready to commit to the company's SCM server, then they just merge and commit upstream. Is that what you're looking to do?
Wouldn't it be a better idea to store your private changes in private branch, using e.g. svn switch to change to main branch whenever you need to?
Mercurial has the Shelve Extension which does what you want.
You can even select which changes from a single file that you want to shelve if you really want.
In Darcs, you either don't record the changes you want stashed (it asks you about including each change independently when you record a new patch), or put them in separate patches that you don't push upstream.
There's no need to fully synchronize your local private repos with public/upstream/other ones. You can just cherry pick the patches you want to push elsewhere. Selecting patches can also be done with patterns, so if you adopt a naming convention for your stashed patches you can push everything but them easily.
That way, your private changes are still in revision control, but they aren't shared until you want them to be.
I found an excellent article about obtaining similar functionality using Subversion branches:
Shelves-in-subversion
And then there's the old fallback... 'patch', or even the old "copy everything to another location, then revert".
Both of these are less convenient than using tools that are part of most VCS systems, though.