Is there a good way to update committer email addresses in bzr? Using the fastimport plugin, I can do something like:
bzr fast-export --no-plain ./trunk/ trunk.fi
cat trunk.fi | bzr fast-import-filter--user-map=names.txt > trunk_clean.fi
bzr init fixed
bzr fast-import trunk_clean.fi ./fixed
What concerns me about this approach is that I'm worried that my branches won't be properly associated with the filtered trunk. As such, is there a better way to update committer email addresses? If I need to use fastimport, is there a way to do so where all the branches I care about are still associated with one another in the history?
Use whoami like this:
bzr whoami "Firstname Lastname <email.address#example.com>"
Email addresses can also be set by branch in the config file:
vi $HOME/.bazaar/branches.conf
[/some/branch/location]
email=Your Name <name#other-isp.com>
References
Setting email via the 'whoami' command
PEP 374
Related
I want to access from one user/client combination (say, user1#cl) to a user/server combination (say, user2#srv) via ssh, with two different types of Access:
Access type #1 would be restricted to interactions with a bazaar repository.
For this, I added a line (#1) in ~user2/.ssh/authorized_keys like
command="bzr serve --inet --directory=/repodir --allow-writes",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa ... user1#cl
Access type #2 would be a login shell.
For this, I added a "usual" line (#2) in ~user2/.ssh/authorized_keys like
ssh-rsa ... user1#cl
As I understand, and as I tested, both lines cannot be used simultaneously.
I.e., if line #1 appears first in ~user2/.ssh/authorized_keys, then I would be able to interact with the bzr repo, but I will not be able to do
[user1#cl]$ ssh user2#srv
If line #2 appears first in ~user2/.ssh/authorized_keys, then I would be able to do ssh, but any bzr operation gives
bzr: ERROR: Not a branch ...
Is there any way to work this out?
I am using RHEL7, but I guess this is not important.
Related posts (but not addressing my case, as I understand):
Best way to use multiple SSH private keys on one client
https://serverfault.com/questions/142997/what-options-can-be-put-into-a-ssh-authorized-keys-file
https://serverfault.com/questions/749474/ssh-authorized-keys-command-option-multiple-commands
https://askubuntu.com/questions/1962/how-can-multiple-private-keys-be-used-with-ssh
I made it work, with two different key pairs (say, pair 1 for bzr and pair 2 for ssh login).
I added the corresponding lines in ~user2/.ssh/authorized_keys.
The private key 1 was stored in file id_rsa (which is read by default),
and the private key 2 was stored in file id_rsa_ssh.
Then, bzr was working normally, and for logging in I use
[user1#cl]$ ssh -i id_rsa_ssh user2#srv
which indicates using an alternative identity.
A user checked new files on the wrong branch. I would like to move them in the most efficient way there is a lot of them. My first thought is to remove the element from the branch and have the user recheck in the files on the proper branch. But I was hoping there was a way i could change the pointers?
/VOB/DIRECTORY/file##/main/1.00/1 to /VOB/DIRECTORY/file##/main/2.00/1
Whenever there are a lot of files to checkout and move, clearfsimport is a viable option.
Simply set a view to the destination branch, and import the files found in the source (and wrong) view.
See "How can I use ClearCase to “add to source control …” recursively?"
That will checkout, add, modify or remove files in the destination view in order to mirror the ones from the source (here the source is a ClearCase view, but it could actually be any folder, ClearCase view or not, where the files are).
That will be enough to "recheck in the files on the proper branch", but that won't remove the versions from the wrong branch though, and I would advice against using cleartool rmver (even though I used that here).
Perhaps a subtractive merge is better.
If you know where they are, and where you want them, you could:
1) Merge the directory and files over.
2) Use cleartool ln in a view in the destination branch to link in the files, and then merge the files individually.
If you use clearfsimport, and don't purge the added-in-the-wrong-place files, you can set yourself up for down-the-road "fun" caused by "evil twins."
Personally, since you know the files and directories that got added, where, when and by whom, you could do something like this (command lines are off-the-top-of-my-head:
Get the list of files to copy/merge
cleartool find -type d -element "created_by(baduser) && created_since(25-Jul-2016) && !created_since(26-Jul-2016)" -print > dirlist.txt
cleartool find -type fl -element "created_by(baduser) && created_since(25-Jul-2016) && !created_since(26-Jul-2016)" -print > filelist.txt
Pull the directories over by merging the parent directories while CD'd/set in a view using the destination path. Not knowing the OS involved I can't say which way you would need to parse this. If you use perl, you can grab the offset of the last instance of the directory separator and use that in substr to get the parent directory path. In the windows command prompt, you can do something like this:
SET SRCDRIVE=D:
for /f "delims==" %x in (dirlist.txt) do cleartool co -nc %~px & cleartool merge -to %~px %SRCDRIVE%~px
for /f "delims==" %x in (dirlist.txt) do cleartool co -nc %~px & cleartool merge -to %~px\%~nx %SRCDRIVE%~px\%~nx
Yes, you can do all that in a single script, and do better error checking and not trying 40x to check out the same directory.
You might also be able to merge them to the 2.0 branch (using a view selecting the 2.0 branch). To identify the elements involved, you can run a 'cleartool find' command something like this:
% cd /vobs/myvob
% cleartool find -all -version 'brtype(1.0) && created_by(user_x)' -print
The 'created_since(date-time)' query might also be useful in the compound query.
Once you're convinced you have the right set of versions, you can use '-exec' in place of the '-print' to actually perform the merge. It might look something like this:
% cleartool find -all -version 'brtype(1.0) && created_by(user_x) && created_since(29-Jun)' -exec 'cleartool merge -to $CLEARCASE_PN -version $CLEARCASE_ID_STR'
If you're happy with the results, check everything in. Then you just have to decide if you need to remove the versions on the 1.0 branch (which you can do with another 'cleartool find ... -exec ...' command).
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
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.