I'm still figuring out how bazaar's revision numbering works. The workflow our team uses is basically:
bzr branch lp:project/trunk
# code,code,code
bzr commit ...
# code,code,code
bzr commit ...
bzr merge
# resolve, resolve, resolve
bzr push lp:project/trunk
I'd prefer it if the trunk revision numbering was stable and increased monotonically with each push. However, as I understand it, whoever does bzr merge; bzr push lp:project/trunk ends up renumbering the revision history of the trunk to whatever their local branch revision numbering was. This makes things very confusing for the team, because "trunk, revision 705" may change over time.
We could use global ids, but it's a little awkward to work with a long string like foo#example.com-20110224160420-nnob0vg2vdk0yjow.
Is there any way to arrange our workflow so that the trunk revision numbering scheme is stable and increases monotonically?
On the trunk on your central server, edit
<yourbranch>/.bzr/branch/branch.conf or ~/.bazaar/locations.conf or ~/.bazaar/bazaar.conf
add append_revisions_only=True
This branch's existing revision order will not change any more.
http://doc.bazaar.canonical.com/beta/en/user-reference/configuration-help.html#append-revisions-only
Edit: For launchpad you can try the following as John Arbash Meinel said:
At the moment, the only way to get a branch with that
option is during "bzr init".
bzr init --append-revisions-only
So you could:
1) have launchpad delete the existing branch
2) bzr init --append-revisions-only lp:...
3) bzr push lp:...
Not exactly optimal.
The other way to do it is to use sftp and do:
sftp bazaar.launchpad.net
cd ~user/project/branch/.bzr/branch
get branch.conf
Then outside of sftp, edit the file to add
append_revisions_only = True
put branch.conf
https://lists.ubuntu.com/archives/bazaar/2008q3/046797.html
Related
I have a project where I want to split it into 3 experiments, each path with a separate twist to it. Down the road, I will want to revert back to a previous iteration or go back to the original. If I pull from the other branch, will it completely replace my local files with the files form the other branch? To keep both iterations locally, should I just copy and paste the folder?
Also with commenting, what is the standard practice for commiting new updates? Every time I commit -m "new update", it replaces the old one and I can't see the history of commits.
In regards to question about viewing commit history, you can use: git log from your terminal in the project's root directory.
More info here.
From the git-scm webpage linked above:
By default, with no arguments, git log lists the commits made in
that repository in reverse chronological order – that is, the most
recent commits show up first.
If you want to see all the differences, you can use the -p flag like so: git log -p.
A good recommendation from the same webpage is to use this command git log --pretty=format:"%h - %an, %ar : %s" to see the log in a very readable format, something like:
ca82a6d - Scott Chacon, 6 years ago : changed the version number
085bb3b - Scott Chacon, 6 years ago : removed unnecessary test
a11bef0 - Scott Chacon, 6 years ago : first commit
After I was required to update my password on a remote SVN server, I'm getting this error on all git-svn operations:
Penultimate record is all-zeroes in .git/svn/refs/remotes/trunk/.rev_map.f0385452-2b02-e011-bae3-001e4f1e4737 at /usr/libexec/git-core/git-svn line 1554
I can't figure out how to get past it.
I had this error after a system crash. The following worked for me:
delete file .git/svn/refs/remotes/trunk/.rev_map.f0385452-2b02-e011-bae3-001e4f1e4737
Replace the hash for refs/remotes/trunk/ in .git/packed-refs by the hash of the previous revision.
run git fetch. It should first rebuild the .rev_map file.
I also ran git pack-refs --all at some point, but I think that didn't have an effect.
I was guided by this:
I need to un-fetch some revisions from git-svn
I'm still trying to figure out how the revision numbering works with bzr, despite having read the understanding revision numbers bzr documentation.
I have a local branch of an upstream repository. The local revision is 689, and I haven't made any local changes.
If I do bzr missing url/to/upstream, bzr tells me that I'm missing 10 revisions: 689-698.
Clearly the upstream revision numbering changed, since the remote 689 is now different from my local 689. What I'm trying to figure out is:
What sequence of events causes an upstream branch to get renumbered? Did my local revno 689 become a merged revision number upstream when somebody else made a change and pushed it up?
How can I use the revision-id from my local revision 689 to determine what the merged revision number is upstream? Is there a way to retrieve this using command-line bzr and/or loggerhead?
You have 2 questions there, so:
Did my local revno 689 become a merged revision number upstream when somebody else made a change and pushed it up?
Yes, that's exactly what happened.
How can I use the revision-id from my local revision 689 to determine what the merged revision number is upstream?
For CLI bzr:
Simple method: run bzr log -n0 --show-ids and search the output for your revision-id. Then scroll back to the top and see which revision has your revision id merged.
You can use qlog command (from QBzr plugin) to make your history exploring much pleasant.
With bzr 2.3+ you can use mainline: revision modifier: bzr log -r mainline:your-revid
i have a bzr repository with revision number 701 and some time ago on revision number 680 i committed some code that changes every file in the repository (i.e. a source code formatter changes every file ) now i want to have the old formatting with out missing the changes i made after revision 680
how can i forget revision number 680 the one that changes every file
1st way: bzr merge -r680..679, but you have to be ready to resolve many conflicts in the places where you made changes after re-formatting.
2nd way: use bzr rebase command from bzr-rewrite (former bzr-rebase) plugin.
In CVS, my working copy (WC) is on a certain branch (which we'll call "foo"). There have been other changes checked into foo by another dev. I want to do a diff between my WC and the upstream state of foo. Normally, when working in the trunk (HEAD), I just do a cvs diff, and that's fine. But for some reason when doing a plain cvs diff in the branch, the diff is empty. When I try to use "cvs diff -r foo", the diff shows up, but it is inverted -- upstream additions are shown with minuses, and upstream removals are shown with pluses.
How can I either: (1) get CVS to diff "the other way" (plus for upstream additions), or (2) invert a patch (in general)?
maybe what you want can be done by using interdiff from the patchutils package.
I often use it this way to see what has changed on the TRUNK for a given file:
cvs diff -up -r1 givenfile | interdiff /dev/stdin /dev/null
If the principal purpose of this is to check "what's up" in the central repo, I suggest you get yourselves a functional CVS viewer/browser/web thingy where you can browse and see the latest changes before updating. But assuming all you have is command-line CVS, I will attempt to give you a solution anyway :)
So, what you have here is a branch foo that went from A -> B, where B is the state of the branch (on the server) after the other developer's checkin, and A is the state you last updated your working copy to.
When just doing a plain cvs diff in this situation, you'll see your local changes compared to A since A is what you have checked out. The local CVS state will show that each file comes from the A revision on the foo branch, and when diffing your CVS client will download that revision from the server. In your case I'm guessing you have no local changes since your cvs diff is empty.
Then, when you do a cvs diff -r foo you're diffing your local A (or A+changes) against the server's foo (which currently is at B) - and the changes required to get from the server's B to your A+changes is exactly the opposite of the other developer's check-in, plus your own local changes.
Now, if you really really want to know how B (or tip-of-foo) compares to A (the pristine version of whatever you currently have checked out), what I think you have to do is set a tag on your working copy, then diff that tag against the state of the branch. Something like this:
cvs tag pistos_temp1
cvs diff -r pistos_temp1 -r foo
# And clean up by deleting the tag afterwards:
cvs tag -d pistos_temp1
You can try export a file from the branch to some temporary file and then make diff between your working copy and this temp file. It seems to be the easiest way.