The bzr documentation states http://doc.bazaar.canonical.com/bzr-0.10/bzr_man.htm
bzr update: ... If you want to discard your local changes, you can just do a
bzr revert instead of bzr commit after the update.
However this is not what I am getting. I have new files in my repo and all I want is to have the latest revision in my working directory and to have bzr status show anything as being changed.
Is this possible?
First of all, you're looking at an extremely old version of the doc.
As of version 2.6 (current stable),
the description of bzr update is longer, and very different:
Description:
This will perform a merge of the destination revision (the tip of the
branch, or the specified revision) into the working tree, and then make
that revision the basis revision for the working tree.
You can use this to visit an older revision, or to update a working tree
that is out of date from its branch.
If there are any uncommitted changes in the tree, they will be carried
across and remain as uncommitted changes after the update. To discard
these changes, use 'bzr revert'. The uncommitted changes may conflict
with the changes brought in by the change in basis revision.
If the tree's branch is bound to a master branch, bzr will also update
the branch from the master.
You cannot update just a single file or directory, because each Bazaar
working tree has just a single basis revision. If you want to restore a
file that has been removed locally, use 'bzr revert' instead of 'bzr
update'. If you want to restore a file to its state in a previous
revision, use 'bzr revert' with a '-r' option, or use 'bzr cat' to write
out the old content of that file to a new location.
The 'dir' argument, if given, must be the location of the root of a
working tree to update. By default, the working tree that contains the
current working directory is used.
Aliases: up
See also: pull, status-flags, working-trees
Your question is not very clear.
When you're working in centralized mode,
you have a working tree you created with bzr checkout,
the bzr update command will bring in the new revisions that were added in the central repository.
If your working tree was clean (bzr status showing no changes) before bzr update,
then your working tree will be updated to the latest version (as it is on the central server),
and your working tree will be still clean.
If your working tree wasn't clean before bzr update,
then Bazaar will try to merge the new revisions on the server into your working tree,
and conflicts may happen.
If the changes you had were exactly as what the new revisions changed,
then you will end up with a clean working tree, which is extremely rare.
Most commonly,
if your working tree had changes before bzr update,
it will most probably have changes after, and possibly conflicts too.
The bzr status will tell you what they are.
It's best to not have pending changes before running bzr update.
Related
I am working on a project, using Fossil for version controlling and organizing it. I have some branches other than my main trunk branch, and want to update (commit) only a single branch. Doing commit will push my changes on a branch to the main Files (i am hosting my project on Chiselapp)
. How is it possible to update or commit only a single branch without affecting the main files?
A commit only ever affects a single branch. Except perhaps after merging two branches, but I'm assuming you haven't been doing that.
The only thing I can think of is that the skin you're using has a "Files" menu item that links to dir?ci=tip. The tip is a special name for the most recent commit. Which means that, if you make a commit in a different branch than trunk, that "Files" menu item will now show you the files of that other branch.
The hackish temporary way to fix that is to make a commit in trunk afterwards, so that tip refers to trunk again. But that's not ideal.
The easiest way to permanently fix this, is by choosing a different skin which doesn't do that, or by editing your skin's header, and replacing the link to dir?ci=tip by another link, dir?ci=trunk for example. That way, that menu item will always show the files in the trunk branch.
Fossil unlike Git pushes/pulls all branches and tags at once*. The reason (apart from being by design) is that Fossil repository is a database, push/full synchronizes the database in the respective direction.
This means if you committed changes on several branches then all of them will be pushed to the remote.
*UNLESS, the changes are done on private branches (see fossil help for fossil commit --branch --private, fossil branch new --private).
Private commits/branches by default are excluded from push/pull. To also include these use --private option (see fossil help for fossil push --private).
Once the changes have been pushed, they are integrated in the remote repo and can be viewed in the remote repo's web-GUI as individual commits or via the branch to which they belong. The view includes the Files section that reflects the repo contents (snapshot) at the commit's version.
To answer your question: if you committed changes to existing trunk branch, they will be pushed to the remote trunk as well. If you don't want to make changes to the remote trunk, then make your changes in your new branch (to be pushed as a new branch) or in your private branch (will NOT be pushed by default).
I have local folder that is branch from formal_versions.
My workflow is:
Mkae changes and than commit them
The integrator merge them in his local branch.
The integrator push its local branch to formal_versions
I use pull to make my local branch identical to formal_versions
This is working fine.
However what should I do in the following scenario:
After pull from formal_versions , I compile the code. As a result , some workspace and obj file are changed (I.E date and time of compilation) and of cource , bazaar explorer inform me on modified files
I again want to make my branch mirror of formal version. What should I do?
A. Why using pull again says that "nothing to pull" even if
I use --overwrite switch ? it is suppose to make my local branch as mirror of the pulled branch...
B. Is my only option is to use revert working tree?
It is generally considered best practice (as well as good for one's sanity) not to version files that are the result of the build process. Executables, shared libraries, and even source files generated from by a 4GL are examples. You can ignore files by using bzr ignore <pattern>, for example bzr ignore *.exe. If the files are already versioned, you will also have to remove them using bzr remove.
bzr pull says there is nothing to pull because the formal version has had no new commits since your last pull.
If you must version the files in question, bzr revert is the only way I know of when bzr pull does not find new revisions. If there had been new revisions in the formal branch, the files should be updated (and will potentially be reported as conflicts).
Is it possible to create a branch of a bzr repository that selects omits certain changes? For example, let's say my repository is at revision 354, and I want to branch it, but I don't want to include the changes that were done in revision 247.
Note that I plan to merge in the changes from revision 247 at some point in the future. So I don't want to just make changes to the code that undo what revision 247 did, otherwise there will be a conflict later when I try to do the merge.
Is this type of selective branching possible with bzr?
I think you're looking to Reverse Cherrypick. This will let you remove a single revision from a branch.
no.
A revision always guarantees all of it's parent revisions.
I don't think you will have too many conflicts if you first undo and commit that revision and then later re-apply it.
If you are unsure branch into a temp directory and try it out.
Is theere a way of finding out what changes a bzr update will do without actually doing it.
Specifially I would like to have a bit of warning if there is going to be a conflict.
Not directly that I'm aware of, that's what bzr revert is for. However, there is a common way to structure your local branches to help. I use one local branch that mirrors the central branch, then I branch off of that for my work. When I'm ready to "check in," I update my local mirror branch, which always succeeds without conflicts because I haven't changed my working copy of that branch. Then I merge my feature branch into my local mirror branch, then push my local mirror branch to the central repository.
The advantage of this setup in your case is you could use bzr merge --preview or bzr diff to see the changes if you don't want to actually try the merge. I personally prefer just to revert the merge until the conflicts are fixed either upstream or in my local feature branch.
Is it possible to emulate the behavior of 'git stash' when using fossil/bzr?
Basically I'm interested in handling the following workflow:
at some point the source code tree has state X, it is commited
I proceed to writing new code, I write it for a while and I see the
opportunity of a refactoring
I can't commit at this point, because the change I've started to make is not
completed, it is not atomic yet
at this point I would do 'git stash', would save the current work and would
get back to state X
I would do the refactoring and commit, source code now has state Y
I would merge source code in state Y with code in stash, complete the change
to make it atomic, then commit once again, pushing the source code to state Z
I think that generally it is possible to emulate this scenario when using
another SCM by branching the code in state X instead of doing 'git stash',
doing the refactoring in that branch, then merging the branch back into the
main one. But I'm aware that branching is not always a cheap operation. So are
there any better particular approaches that eventually rely on specific
features of fossil/bzr?
Use bzr shelve and bzr unshelve commands.
You can use the patch command of your system.
First you make a "stash" by storing a generated diff as .patch file:
$scmtool diff > working.patch
then reset your working directory.
later, apply the patch with:
patch -p1 --dry-run < working.patch
and then this works, remove the --dry-run to apply the patch for real.
The stash command was implemented in fossil recently. You got to check out latest fossil executable you will see stash in the available command list.
Here is the link to the web help on its syntax.