=== yofel is now known as Guest39202 === Guest39202 is now known as yofel [19:15] how to merge a branch without a common ancestor? [19:17] Manually specify the rev range to merge. Usually the whole history, i.e. "-r0..-1". [19:18] I wonder if we should just add that as suggestion to the error message. [19:18] I'd hesitate, I think. [19:22] Worth a FAQ entry, maybe. If we have a FAQ. [19:30] I think clarify the error message would be nice, because I went through exactly the same steps as described here, without knowing this page: http://selfdocumentingcode.blogspot.com.br/2009/04/merging-unrelated-branches-in-bazaar.html [19:32] is there a way to specify a bug in commit comment without using full URL? [19:33] I want to reference bug 308562 in the dummy initial commit [19:33] Launchpad bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555 [19:33] mark06: there is the --fixes option which adds a commit property [19:33] I know, but it doesn't fix the above bug :) [19:33] mark06: it allows you to use shortcuts for bug tracker URLs [19:34] mark06: --fixes lp:4545 will reference http://bugs.launchpad.net/4545 [19:34] Ubuntu bug 4545 in amsn (Ubuntu) "amsn crashes on start-up/won't load" [Medium,Fix released] [19:35] ok, I know, but it doesn't fix that bug, it's that bug which required the commit, so would be rather --forced-by [19:35] mark06: I'm not sure I follow what you mean in that case [19:35] mark06: do you want to reference a bug without actually changing anything else? [19:36] mark06: you want --unchanged in that case [19:36] I'm already using --unchanged [19:36] I think you're just trying to outsmart yourself :) [19:36] I want to reference the bug in the commit comment, something like: [19:36] Just reference "LP bug 12345" in the commit message. [19:36] Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345 [19:37] ISDN? Yeesh. How 1990's :p [19:37] yeah fullermd, just wondered if it was possible [19:37] mark06: Why though? This is what the commit properties are used for, and what all bzr tools will display [19:38] Having two different ways of referencing bugs would seem very confusing to me, and not particularly useful. [19:39] jelmer: ...something like: bzr commit -m "This is a dummy, empty commit required because of bug lp:308562" [19:41] mark06: ah, no, there isn't any way to do that. I don't think that would be particularly useful. [19:42] btw, it would be nice if tags weren't unique, or if we had options like --not-very-important (e.g. code formatting) --broken (for broken revisions we don't open a bug for) [19:43] about the dummy commit, nothing much important [19:43] or --fixes=revision [19:43] mark06: what do you mean with --not-very-important, what would that do? [19:45] add a metadata to the commit stating it is not as important as "regular" commits, so we could for example bzr qlog --exclude-not-much-important [19:45] mark06: one of the fundamental properties of tags is that they're unique; without that; if you want to use them to annotate revisions I think what you want is a different feature (perhaps stored as revision property?) [19:45] yeah, as a property then... [19:46] is it possible to add arbitrary properties and have them showing in qlog juts like tags or --fixes? [19:47] mark06: you'd have to have a plugin installed that can display those properties [19:47] similarly though, you'd need a plugin to set them [19:48] :( [19:51] what's the difference between -r 0..-1 and -r 1..-1? [19:51] 1 8-} [19:52] The former runs from null, the latter from rev1. Just what the result is probably varies a bit by command and how they interpret the rev range. [19:53] Could someone explain to me the relationship between repositories and branches in bzr? [19:54] Guest40826: the repository is the thing that holds the revisions, and a branch is a line of history [19:54] how about the merge command, does it make any difference like merging uncommitted commits or something? [19:55] mark06: Yes, -r1..-1 would mean the revs {2,3,4,...,-1}, in contrast to 0..-1 meaning {1,2,3,...,-1} [19:55] So, if I want to have two completely separate projects, would I create two separate repositories for them? [19:56] Guest40826: no, you can have them in the same repository without problems. The repository is merely a container for the revisions, it doesn't require them to be related in any way and it doesn't have any effect on their relation either. [19:57] However, if they really are completely separate, there would be no _gain_ from having them both in the same repo. [19:57] indeed [19:57] Potentially a minor loss in performance in some cases, since half (or whatever proportion) of the data to be sorted through would be pointless for any individual activity. [19:58] fullermd: ah thanks! [19:58] Probably pretty unimportant, unless either branch is huge. [19:58] So, I could create one repository (using the init-repo command?) that would have multiple branches inside of it (created using the init command?) and could develop two different codebases within that one repository? [19:59] Do I have that right? [19:59] Guest40826: yep [19:59] You could, yes. The repository doesn't care; all it knows is it gets told "find me revision XYZ" or "here's a revision; hold onto it" [19:59] maybe just create standalone branches (each branch contains its own repo) [20:00] mark06: What do you mean by that? [20:00] Guest40826: What's your VCS background? [20:00] almost strictly svn [20:01] OK. So the difference here is that svn is very repo-centric, whereas bzr is branch-centric. [20:01] In svn, the repo boundary is important. You checkout the whole thing, or some arbitrary subpart of it. All your operations take place inside it. [20:02] Whereas in bzr, you deal only with branches; the whole branch, and nothing but the branch. You checkout the whole thing, you make a new branch of the whole thing, etc. [20:02] Operations like merge take place between two branches. And any two branches; they don't have to be in the same repo (or in any shared repos at all) [20:03] okay, so what is a standalone branch? [20:03] (mentioned by mark06) [20:03] Whether a branch is in a shared repo or not doesn't make any difference to how you interact with it; it only changes some backend storage details. [20:03] A branch that's not in a shared repo. [20:04] How about an example... [20:04] "mkdir ~/work ; cd ~/work ; bzr init projA ; bzr init projB" [20:05] Now you've got two unrelated branches to work in, each of which is standalone. All the history for projA is in ~/work/projA, and for projB in ~/work/projB. [20:05] Or add a step instead: [20:05] "mkdir ~/work ; cd ~/work ; bzr init-repo . ; bzr init projA ; bzr init projB" [20:06] Now you've got two unrelated branches to work in, both of which use the shared repo for their history storage. [20:06] Inside ~/work/ is a giant bucket that all the revisions get dumped into. projA knows which of them belong to it, and projB know which belong to it. [20:06] For pretty much anything you _do_ day to day, the two cases are identical. [20:07] Unlike svn, the repo isn't [generally] a semantically meaningful unit. It's the branches that are the granularity you work with. [20:07] And in this case, it doesn't convey any advantages, since the two projects don't share any history. [20:08] Where it's useful is when you have projA-trunk/ and projA-frob_foo/ and projA-from_bar/ branches, which _are_ related. [20:08] Standalone, each would have the entire history (both the stuff common to all of them, and the new stuff in each) [20:09] With a shared repo, all the history is in one place, so the common history isn't duplicated. Saves disk space, I/O bandwidth, buffer cache, etc. [20:09] Here is my situation: I have two development teams, neither of which has any relationship to the other (outside of that fact that they have them same system admin). Team A is dealing with one codebase, Team B is dealing with two codebases (for two entirely separate pieces of software). I want to give Team B one domain at which they can access both codebases and choose which one to modify based on what they are going to be working on. [20:10] Which sounds to me like one repo with two branches in it for Team B. [20:11] Is that 3 codebases, or 2 (one shared, one B-only)? [20:11] 3 total - one for team A, the other two for team B [20:11] I'd just make one repo for each codebase then. [20:12] Sharing a repo between unrelated codebases doesn't gain you anything, so go for simplicity. [20:12] okay [20:14] so how do I serve those two repos for team B at the same domain? [20:14] Just by placing the two repos in the same directory and giving team B access to that parent? [20:14] Yeah. [20:15] How are you accessing them? bzr+ssh? [20:15] That is another question I have :( [20:15] Is there a difference between bzr and bzr+ssh [20:15] ? [20:16] bzr is a standalone server, like svn://. bzr+ssh ssh's into the server and talks to a spawned process over that channel, like svn+ssh [20:17] so I bzr:// what you would use when running the http://doc.bazaar.canonical.com/bzr.2.5/en/admin-guide/other-setups.html#direct-smart-server-access setup? [20:17] *is [20:18] Note that bzr doesn't have any concept of AAA, so in general you'd only use it for readonly stuff. [20:18] (bzr:// that is) [20:18] Okay, [20:18] I am going to be accessing this using bzr+ssh [20:19] With user accounts being restricted to bzr [20:28] http://i.imgur.com/z0zsX.png o/ [20:32] Definitely an odd use of tags. [20:42] actually I changed it to fixes_rev_0.11.5 on 0.11.6 [20:43] Yeah, that would also fall under "pretty odd" :p [20:45] yeah I know :) [20:46] oh wait, fixed_by_0.11.6 :) [20:47] * fullermd reaches for the smelling salts. [20:54] I think I've found a bug, if merged branch contains tags already present in current branch, then it gets deleted after merge! (current branch wins the tag) [20:55] That's not exactly a bug. [21:07] I would personally add a merge conflict to let the user decide [21:07] The trouble is, there's no way to record a resolution. [21:08] Actually, I'd expect merge to spit out a warning about it. pull does. But maybe it gets lost in all the other stuff merge outputs. [21:09] I guess it doesn't. That's probably worth a bug. [21:21] hmm ok leaving... thank you all! [22:25] Oh look, a Wacky Log Bug. [22:27] fullermd: where? [22:28] I'm gonna have to work up a repro script. 's hard to explain, but it winds up with "bzr log $DIR" (or $FILE I presume) not showing you what it should. [22:29] hi I am trying to use checkout and I am doing bzr checkout sftp://user:pass@host [22:30] and bazaar seems to ignore hte pass field entirely and still ask for a password [22:30] That's because bzr doesn't have access to the password-asking; sftp talks to your terminal directly for that. [22:30] is there anyway to automate it at all? [22:30] I get sick of typing in a password everytime? [22:32] Use key auth (possibly with the aid of ssh-agent). [22:33] meh okay thanks for your help fullermd [22:34] Possibly you could force it to use paramiko instead of an outside ssh client, and pass it in that way? I dunno. Not as nice a solution at any rate. [22:35] what is a bit annoying is http://doc.bazaar.canonical.com/bzr.1.11/developers/authentication-ring.html [22:35] says I can embed the pass in the url but I guess it doesn't note the exception for sftp [22:37] fullermd: I'll just put up with entering the password for now at least I know the url is remembered I was typing that too [22:37] thanks again [23:03] Boy, this thing is tricksy... [23:21] fullermd: which thing ? [23:21] Weird log bug I'm tracking. [23:27] why would you not just use keys [23:29] harmony [23:30] Yeah, you might be Berg or Schoenberg. [23:31] it is far too early on a monday for classical music jokes [23:31] Good thing it's late on a sunday 8-} [23:53] * fullermd writes up a terribly confusing bug...