My question is related to this one. Basically, I checked out a file in my local branch and, later, I performed a merge from the main branch, which already had a newer version of this file. I find it weird that file##/main/branch/subbranch/LATEST still contains the older version of the file, from before performing the checkout. Shouldn't the merge operation also update this link?
For merging, I used this command:
cleartool findmerge /my_file_folder -nc -fver .../branch -merge
The cleartool findmerge will checkout and merge, but won't check in.
As long as you do not checkin, the extended path ##/main/branch/subbranch/LATEST won't reflect the result of that merge.
Related
I have merge code from a branch to trunk using SVN merge tool (not the svn merge command but using UI). I use TortoiseSVN.
When I run following command svn propget svn:mergeinfo <<URL_to_trunk>> then I cannot see the merge information getting recorded in mergeinfo property.
Even if I use this command with branch URL then as well I cannot see the recorded merge info.
I read following line in SNV book.
The svn:mergeinfo property is automatically maintained by Subversion
whenever you run svn merge.
Does this mean that mergeinfo property would be updated only when merge is done using svn merge command from command line and not merge using UI?
If not then why I cannot see merge info using svn propget svn:mergeinfo <<URL_to_trunk>>?
To add to the previous answer, tortoise will also not record merge info if the "ignore ancestry" is checked
The svn:mergeinfo property should be correctly added to merged files even when using Tortoisesvn.
You should run the "svn propget" command on merged files in your working copy, to see the svn:mergeinfo property.
I'm coming late to the DVCS party after developing solo for a long time by doing my own version control with copies of folders. For a small project, I would have essentially a folder structure that looked like this:
project
development
release1.0
release1.1 (for a bug fix)
release1.2 (for a bug fix)
release 2.0 (for a new feature)
I'm now getting on board and learning DVCS using Mercurial (SourceTree) and BitBucket, and slowly learning the ropes with both the GUI and command line with some new projects where I could start fresh using DVCS. I'd like to move some of my old projects into DVCS, but I don't want to lose my project history. What is the best path to follow, or is it even worth the effort?
I'm thinking something along the lines of the following (attempting to use an HgFlow methodolgy):
Create repository using code from release 1.0
Commit files into the development branch
Add tag for release1.0
Merge into the master
From the development branch, create feature/hotfix branch for release 1.1
Copy files from release 1.1 into hotfix branch and commit
Merge hotfix branch into develop and master
Add tag for release 1.1
From the development branch, create feature/hotfix branch for release 1.2
Copy files from release 1.2 into hotfix branch and commit
Merge hotfix branch into develop and master
Add tag for release 1.2
etc.
Does this seem like a workable approach? What suggestions do you have?
Yes, your approach is good. The only thing to add it to use hg addremove before you commit the next version of your code. This command can find renamed files for you and will thus help you recreate an even more accurate history.
The workflow then becomes
Create repository
Copy files from release1.0 into the working copy. They will all be seen as unknown (? ... lines in hg status).
Use hg addremove to schedule them all for addition. Adjust the .hgignore file to exclude build output before running hg addremove.
Commit and tag this as 1.0.
Delete all files from your working copy using your normal OS delete command. The files will now be listed as missing (! ... lines in hg status).
Copy files from the release1.1 into the working copy. Files that were changed compared to release1.0 now show up as modified and (importantly) newly added files show up as unknown while removed files still show up as missing.
Run hg addremove to schedule the new files for addition and the missing files for removal. If a file foo.c in 1.0 was renamed to bar.c in 1.1, foo.c will show up as missing and bar.c will show up as unknown. When you run hg addremove, Mercurial will recognize this as a rename. Use the --similarity option to adjust how similar the files need to be for them to be considered a rename.
Commit and tag this as 1.1.
Now repeat for the other releases. The important part is to clean the working copy between each code import — what way you make sure that each commit accurately reflects the state in the folders you used before.
How do I replace a local file by its latest version in the repository?
Is there also a way of replacing all local files which are conflicting with the corresponding files from the repository?
Both hg update -C and hg revert will do what you are looking for - replace a locally modified file with the clean version in the repository. Personally I prefer hg revert but hg up -C will also do the job
hg revert
Some further details from the help for hg revert
With no revision specified, revert the specified files or directories to
the contents they had in the parent of the working directory. This
restores the contents of files to an unmodified state and unschedules
adds, removes, copies, and renames. If the working directory has two
parents, you must explicitly specify a revision.
Using the -r/--rev or -d/--date options, revert the given files or
directories to their states as of a specific revision. Because revert does
not change the working directory parents, this will cause these files to
appear modified. This can be helpful to "back out" some or all of an
earlier change. See "hg backout" for a related method.
Modified files are saved with a .orig suffix before reverting. To disable
these backups, use --no-backup.
Hope that helps
Chris
svn update ?
Or delete your folder, and svn checkout...
Or try the option --force.
So i've made the switch from CVS to mercurial for my website.
The biggest issue I am having is that if i'm working on some files that I don't want to commit, I just save them.. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down.. It asks me to merge or rebase.. either of these options will cause me to lose my local changes that I have not committed.
I've read that I should clone the repository for each project on my local host and merge it into the live when it's ready to do so. This not only seems tedious, but also takes a long time as it's a large repository.
Are there better solutions to this?
I would have hoped that Mercurial would see that I haven't committed my changes (even though I have changed the file from what's on the server) so it'd just overlook the file.
Any input on this would be greatly appreciated. Thank you!
Also, i'm using the hg eclipse plugin to work on my files and push/pull from the server.
hg shelve is your friend here I think.
which comes from the shelve extention (maybe - see below)
from the overview:
The shelve extension provides the
shelve command to lets you choose
which parts of the changes in a
working directory you'd like to set
aside temporarily, at the granularity
of patch hunks. You can later restore
the shelved patch hunks using the
unshelve command.
The shelve extension has been adapted
from Mercurial's RecordExtension.
or maybe its the attic extension
This module deals with a set of
patches in the folder .hg/attic. At
any time you can shelve your current
working copy changes there or unshelve
a patch from the folder.
it seems to have the same syntax as the shelve extension, so I'm not certain which one I've used
I second #Sam's answer. However, if you prefer to use standard Mercurial, a simple workflow is to
save your working dir changes in a temporary file,
sync your working dir with a specific revision, then
push, pull, merge .. whatever you want to do and which requires a clean working copy, and
get back your changes from the temporary file into the working dir.
For instance:
$ hg diff > snapshot.patch # save your uncommited changes
$ hg up -C # get a clean working copy
$ hg pull # do things ..
$ hg merge # .. you need a clean ..
$ hg commit -m "merge" # .. working copy for
$ hg import snapshot.patch # get back your uncommited work
First, are you working from the commandline, or using something like Tortoise?
If you're working from the commandline, and you've done a pull, mercurial will not ask you to do anything, as it merely updates your local repository.
If you then do an hg update and have local changes, it should do what you're used to from CVS. It will update to the tip of the current branch, and attempt to merge your outstanding changes in. There are some caveats to that, so refer to the official docs at http://www.selenic.com/mercurial/hg.1.html#update.
Also, for temporarily storing changes, I would recommend MQ over shelve. Shelve only provides one storage area, whereas MQ provides as many as you need. MQ takes some getting used to, but worth the investment.
If a file is committed several times with various changes, how can I fetch one change at a time, i.e., one changeset at a time?
I use eclipse, subversion, and subclipse, and I can't change the former two for the time being (or the MS platform..).
In my Team/Synchronization view in eclipse (using subclipse), choosing the changeset model, a file seems to be listed only in the latest relevant changeset even if all changesets are listed. So an earlier changeset doesn't necessarily show the full set of files in the original commit, nor the original diff for a file in a commit.
Update: I'm thinking about using changesets for simplified code review, so I'd like the partial update represented for all the files commited in one changeset. It's easy to get diffs and specific revisions for specific files in eclipse, but I'd like to step through all the changes in one specific commit/ changeset in a practical manner.
As I'm sure you know, svn up will by default grab the latest revision of the file.
However, you can use the -r parameter to svn up to grab a particular revision of a file. So if you know a file was committed in revisions 5, 7, and 9, you could do this:
svn up -r5 myfile
svn up -r7 myfile
svn up -r9 myfile
I believe (but I don't have an installation of it in front of me) that Subclipse has a similar option, labeled something like "Update to Revision..."
Subversion does not support atomic changesets.
(Note: If anyone can prove me wrong, I'll happily switch accepted answer.)
I've compared Git and Subversion using TortoiseGit and TortoiseSVN (and looked at what is possible on the command line).
With both Svn and Git I can update to a certain revision, or see and update to different versions of only one file at a time.
With both Tortoise clients can I see individual commits (revisions) from the repository and look at changes between a revision and the previous revision. (Note that I can't seem to do this in Eclipse, ref the question.)
Only with Git, however, can I update to or cherry-pick an isolated commit. The closest I've seen to this functionality in Subversion is to update to head and then revert a certain revision with a "subtractive merge"...
Test setup: make a project, check out or clone the project, make 2 separate commits to repository from elsewhere, including at least one file that is modified in both commits.
Then, with Git: fetch remote changes.
Then, with both Git and Subversion: look at the log.