I am working in a small organisation, only two developers and we use Mercurial version control tortoisehg-2.2.2-hg-2.0.2-x86. I am new to mercurial.
Consider programmerA, programmerB.
In programerA machine I created a repository and a client with name "EFSL".
programmerB is simply a client with name "Uthaya Kumar" pointing at programmerA machine repository.
When I am pulling change set in programmerA machine it creates a new branch,
and it also shows "Not a head revision!" error in both working directory and repository.
In programmerB it is fine.
Please see the screenshots below.
Thanks in advance.
Examine the first screen shot and see that the top line says 8+ in the Rev column. This means that your working copy is based off revision 8. You can follow the line down and also see that it joins at revision 8 which indicates the same thing.
There are two ways to solve this depending upon whether you have made any changes or not.
If you have not made any changes then you would right click on revision 13 and select Update.... to update to the latest change.
If you have made changes then you need to commit those changes and then right click on revision 13 and select Merge with local... which brings up a wizard to handle the merge.
In your last screenshot it seems like you've not got a working copy at all so you need to use the update procedure above to update to revision 13.
You can have the update happen automatically by changing a setting in TortoiseHg:
Select File > Settings from the Workbench
Choose where you want to make the setting change by selecting the appropriate tab at the top. The choices are global to the user or just for this repository
Select Workbench in the left list
In the section on the right, look for a drop down list labeled After Pull Operation
Select update from the list
This will do an update to latest every time you do a pull which will avoid the problem in your first screenshot. You will still have to do a manual merge when you and another developer have made changes.
The other options in that list are rebase and fetch which both rely on the appropriate extension being enabled and are for advanced use only.
This is perfectly normal and correct behavior of Mercurial. Your working directory is currently updated to changeset 8 "Merge 2". The pull operation will not change the contents of your working directory. It simply gets missing changesets and adds them to your history graph. After pulling you are still working on changeset 8. Now the "Not a head revision" appears to warn you, that if you now make any changes and commit them, you will create a new changeset derived from Revision 8, which will effectively create a new branch. This is something you may or may not want to do. Typically after pulling new changesets, you want to update your working directory to the latest changeset, by right-clicking the latest changeset and choosing Update...
P.S.
Your are not using the latest verion of TortoiseHG. Please update to the latest version. It contains many improvements and resolves many bugs.
Related
I'm new to github and currently only starting off using github for mac.
I have taken a clone of my client's website and made some development changes locally. Note: I'm literally working with the files in the directory I sync with.
I want to push only one small change as the rest is still under development. Is it possible to push only the one file?
Git pushes deal with commits, not files. You'll need to create a commit that contains your selected changes. This is one area where Git's index is really handy.
Let's say you've modified two files, foo and bar.
If you want to commit only the changes to foo, using the command line you can do
git add foo
git commit
This will create a new commit updating foo, but bar's changes will remain only in your working copy. You can now push the new commit.
It's been a while since I've used the graphical GitHub tools, and I've only used them on Windows, but I believe the way to commit only certain files is to check or uncheck the box beside each file before you commit. You can see these checkboxes in their documentation:
You can go even further. If some of the changes in bar should be part of a commit, but not all of them, you can do something like git add --patch, which will break your changes up into chunks and prompt you for the ones to add to the index (these are the ones that will be included when you commit).
On GitHub for Mac you can do this too:
Select one or more lines to commit by clicking on the line numbers in the gutter. In the latest release, you can select a block of changes at a time. Hover over the right hand side of the line numbers to get a preview of what will be selected, and click to select.
See the documentation for git-add for details.
We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).
ClearCase client version: 7.1.1
ClearCase server version: 7.0.1.2
We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.
This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.
We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:
File.txt is checked out by 2 team members.
Each members makes a change in the file (in other regions of the file).
First developer checks in the code to ClearCase, no problems here.
Second developer checks in, gets a merge popup notification.
When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.
Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.
Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?
Edit: Illustrating the problem with images of the issue:
The file Manager.cs is at version 27.
Two developers are checking it out.
One made a change, checked in.
The other checks in, gets the merge notification.
This is what i see in the graphical merge:
Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !
Why is this happening automatically??
Image can also be seen here: Image
Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).
If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.
Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.
For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.
Since my initial answer 4 days ago, 2 new information came about:
ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
That is never good to have a client with a version more recent than the server.
We have performed the same test, without using the "Graphic merge". This option worked as expected!
That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).
I'm using svn for the first time, to maintain a custom version of Wordpress. I'm using the subclipse plugin in eclipse. The time has come to merge the changes in the latest release of Wordpress with my customised code base.
I have tried creating a branch and adding the new Wordpress release there, then performing a merge. No changes were made however.
Could someone walk me through the setup of project like this? I fear I am missing something basic.
Thanks.
This is assuming you merge from branch (containing the latest version of Wordpress) to trunk (your customized codebase).
(Make sure that you have committed everything you need into branch.)
Team --> Switch to another branch/tag/revision... your working copy to trunk (the target of your merge operation), and resolve any conflicts that come up at this point.
Team --> Merge opens a dialog where you will be performing the merge operation. Change the "From" URL to reference branch (the source of your merge operation, i.e. what you want to merge into your working copy). "From Revision" should point to the revision in branch where you want your merge operation to "start" from - typically the revision that was last merged in from branch to trunk (or most likely the head revision in your case, if you really want to merge just that latest changes in branch).
Set "To Revision" to point to the latest revision in branch (= the head revision).
At this point you are ready to perform the merge - Dry run command lets you preview what will happen during the merge, and Merge will perform the actual merge.
Once the merge operation has been completed, you need to make sure that all changes that were performed against your working copy are ok, and resolve all conflicts.
When you're done with resolving conflicts and reviewing the changes, commit the changes to trunk in a single commit operation. For your own convenience, it is strongly recommended that you add a commit message where you specifically state what this commit is for ( = merging revisions from X to Y from branch to trunk, what was the purpose, etc.).
Hope this helps.
Converting wordpress project to vendor branch procedure
If you are using svn for the first time I suppose you have not started with a clean wordpress copy, branched from there and edited the branched version, have you? ;)
If that is so you might have a problem at your hands.
Background
Unlike "regular diffs" SVN merge does not compare right-side code/folders with left-side code/folders.
While svn merge might fall back to a diff-like mechanism if it does not find a history, I would not recommend relying on that as it can be quite prone to unneccessary conflicts.
SVN Merge is used to reproduce changes that have been recorded in the SVN history. It is like telling a painter "Hey you know how this picture looked before you added that tree on the hill? That Tree was great! Look here i've copied the same base picture but now it's with a sunset. Can you paint the same tree again but on this picture with the sunset?"
The painter might be able to reproduce the tree because he knows how he had done it. He might even have a draft somewhere.
The picture, that is wordpress. The painter, its svn with you commanding it. The tree thats your modifications. The picture now sunset-themed is the newer wordpress version.
What most likely you did is copy wordpress vanilla into your svn, modify it, work with it.
To stick with the picture example, the history would contain commands like "copy whole picture, add tree, add leaves".
Now you bring a new version of wordpress, a new picture so to say and put it besides your older modified version. The Problem is, you human and smart know its quite much the same picture and even though the newer verison is different you just have to copy the tree, SVN does not have that knowledge. For SVN your wordpress 1.7 folder (modified) is completly distinct from wordpress 1.8. They share no history because nothing in SVNs log indicate it. SVN is a bureaucratic snob isn't it? ;)
Now what people do to allow svn to maintain that historic connection between wordpress 1.7, your modified 1.7 and the new 1.8 is they use branching right at the beginning of their works.
So you would start off with a clean 1.7 wordpress in a "vanilla-wordpress" folder, store it in svn and branch it to, say, "my-modified-wp". There you hack away until you feel like updating wordpress from upstream. People then download the latest wordpress copy overwrite their vanilla wordpress and merge the resulting changeset.
In the picture example commands would be these:
"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"
You can cleanly reproduce the sunset because you know how the picture looked before the sunset was applied.
Your problem though is that you did not start that way off but edited on your downloaded wordpress right away. So your newer copy of wordpress can not be easily associated with your modified version.
One way to establish history relations
download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.
Now comes the trick part
Scroll back the svn log of your "old-modified-wordpress". The one that you did not branch. You have to find the first revision AFTER your initial import of the old wordpress. Once you found that revision you take its number and use it in the second of these two commands:
change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.
You are telling svn the following: "Take all changes in my old branch between revision 4 and NOW and reproduce them on my new branch."
If all works out you should have two identical branches. the old-modified and the new-modified with the slight difference that the new-modified has a solid history with your "/vendor/wordpress/current" branch.
This ancestry allows you to contunously do the following:
Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit
This procedure I describe with less storystelling at the link allready. But before it can work you have to establish the ancestry relation between the branches.
Subversion svn:externals file override?
I know it has been alot to read :). If you plan do soem drawing, think of "change commands" not states and you'll be fine.
C
Me and my friend using flex builder (eclipse based) with subclipse for a project.
Before committing I always update but sometimes I could not commit because of conflicts. Then I use Team->Synchronize with Repository and it shows at the right side latest from repository and at the left side the my current working copy. It has a button to copy from all non-conflicts from right to left (from latest repository to my working copy). But there are still conflicting lines.
Sometimes I just want to copy from left to right but there is no button for that (I mean overwriting repository file lines with my lines). After copying non-conflicting parts from right to left I just want to commit left side (I want to overwrite and commit my final file to repository). I cannot commit because of these conflict issues. Then my friend can use Replace With-> Latest from Repository command to get latest overwrited version.
Subclipse documentation is weak I could not find any good guide on the Internet. Could you explain subclipse conflict resolution step by step for a dummy like me? A video showing the steps, or an alien technology to fix it quickly will be fine. Are there any better (easier) solution for source control for eclipse?
(I use subclipse 1.4)
Yes, you are right. There is no button for that. in the Diff View(Side-by-Side View) the items in red are in conflict. They can not be automatically merged. You must review the item in conflict and manually resolve it by copying/editing the block of code that is in conflict.
After committing to or updating from repository(Synchronize with Repository) you'll see in the Console view that some items are in conflict. When you take a look at that file in Package you'll see 3 files right next to your original file:
myfile.txt (original file)
myfile.txt.mine
myfile.txt.r3293
myfile.txt.r3501
Right-click your original file then select Team -> Edit Conflict. In the Diff View provided, edit the file on the left-side to match the final result you want. (i.e. You may want to keep some of your changes and copy over new update from the revision in SVN, discard all changes and only keep your changes, etc.) After you are done, save the file. Right click your original file again then select Team -> Mark Resovled.
You will see that the addition 3 files disappear. You can now "safely" commit your work.
There is no easy way to do this since SVN can't decide what's the best option when such conflict arise.
I know this thread is old, but if someone is looking for an updated answer, my experience can help.
I'm using subclipse 1.8. Right-clicking on the original file and selecting "Mark Resolved...", you'll have several options, among others, take the local file or the base file as the correct version. You can save time with these options.
I can't find "Mark Resolved" so instead I clicked "Mark as Merged" after manually deleting the generated files.
Do the following steps:
Copy your latest working updates to a safe place.
Select the file which has conflicts..right click > select replace with>>Select Latest from Repository.
Then go back to your saved working copy and manually replace the current file contents (which has been overwritten in above step) with yours.
Then from team select Commit...
This way conflicts should be resolved and you saved your latest updates to SVN Repository.
¿How would I do the operation described here, which is very simple from the command line, with the subclipse plugin?
I think I would make sure that my working copy is in sync with the branch, then I would go to "Merge...". I'm not sure what to do in the popup!
Edit: I have read somewhere that in the popup I must indicate the merge range as a range of trunk revisions: from the revision where the branch was opened, to HEAD. Makes sense. But I'm trying this out now with a test project and I don't get the new trunk changes on the working copy that points to the branch. I must be missing something, or it's not working!
Note: Subclipse 1.4.8
I got it now. It's how I said in the edit, as read in a number of websites...
in the popup I must indicate the merge range as a range of trunk revisions: from the revision where the branch was opened, to HEAD.
Apparently many people get confused with the from-to range. This is the range of revisions of the trunk/branch you're merging from. These changes are merged into the working copy you selected in the package explorer.
What I said about not getting it to work in spite of doing this was due to my mistake in selecting the trunk URL: the project was below a subfolder in the repository.
Assuming you're using the latest version of Subclipse (in the absence of information otherwise), select "Merge a range of revisions" and "Next >" -- you should be able to select the trunk (or another appropriate source) in the "Merge from:" box on the next page.