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.
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
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
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
lanchpad.net states that for project Emle - Electronic Mathematics Laboratory Equipment, the current focus of development is the 2.0 series
This is what I have done so far:
Set the launchpad.net project to import from the sourceforge.net project Emle (this actually set the launchpad.net project to mirror the sourceforge.net project rather than just inport the content once)
Examined the launchpad.net project to see that the three commits (#1 - #3) which were done in the sourceorge.net project previousley made it into launchpad.net.
Used bzr to get the launchpad.net project which I did while it was still set for mirroring.
Made three changes and commits using bzr (#4 - #6).
Was unable to see the changes on the launchpad.net site.
Requested the mirroring to be stopped (it did).
Here is an extract from lanchpad.net for project Emle 2.0 series showing that launchpad.net has #1 - #3:
Code for this series
The following branch has been registered as the mainline branch for this release series:
lp:emle - C.W.Holeman II
3 revisions, 3 in the past month.
This shows that #4 - #6 have some kind of problem:
$ bzr missing
Using saved parent location: bzr+ssh://bazaar.launchpad.net/~cwhii/emle/2.0/
You have 3 extra revision(s):
------------------------------------------------------------
revno: 6
committer: C.W.Holeman II <cwhii_hcnual#julianlocals.com>
branch nick: lp.emle
timestamp: Sat 2010-02-27 09:13:29 -0800
message:
#528096 Corrected setting of paramter value for emleDir to the dir
attribute value of the message element in the lanuage message file,
lang/emle_lang_XX.xml. Minor refactor - Consistently setting the dir and lang
attributes of html, head and body elements.
------------------------------------------------------------
revno: 5
committer: C.W.Holeman II <cwhii_hcnual#julianlocals.com>
branch nick: lp.emle
timestamp: Sat 2010-02-27 09:08:09 -0800
message:
Minor refactor - improved comment regarding workaround for replacing
html vs head and body elements from index html with lab transformed
XML (to html) document tree.
------------------------------------------------------------
revno: 4
committer: C.W.Holeman II <cwhii_hcnual#julianlocals.com>
branch nick: lp.emle
timestamp: Sat 2010-02-27 09:04:29 -0800
message:
#529089 #529087 Index file html tag lang attribute corrected and empty link tag changed
How do I get the changes that are in bzr on my system to apply to launchpad.net?
More info:
$ bzr check
Checking working tree at '/home/cwhii/work/lp.emle'.
Checking branch at 'file:///home/cwhii/work/lp.emle/'.
Checking repository at 'file:///home/cwhii/work/lp.emle/'.
checked repository <bzrlib.transport.local.LocalTransport url=file:///home/cwhii/work/lp.emle/> format <RepositoryFormat2a>
6 revisions
83 file-ids
checked branch file:///home/cwhii/work/lp.emle/ format Branch format 7
$ bzr merge
Merging from remembered parent location bzr+ssh://bazaar.launchpad.net/~cwhii/emle/2.0/
Nothing to do.
It turnes out that lp:~cwhii/emle/2.0 is an auto-import branch from svn. You're not allowed to write to import branches, even if you own them, because that would cause confusion when the auto-import robot tries to keep writing to them.
So what I suggest you do here is
1- go to http://launchpad.net/people/+newteam and make an emle-dev team, so that you can later let other people write to this project if you want
2- go to http://code.launchpad.net/~cwhii/emle/2.0/+edit and change the name field to "2.0-import" to "get it out of the way"
3- on your pc, in the branch directory, type "bzr push --remember lp:~emle-dev/emle/2.0"
4- on http://launchpad.net/emle/2.0/+linkbranch enter ~emle-dev/emle/2.0 to indicate this is now the focus of development
hope that helps.
(sorry they're not real links, I don't have enough karma here.)
The poor message here is https://launchpad.net/bugs/543797/
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.