| === yofel is now known as Guest39202 | ||
| === Guest39202 is now known as yofel | ||
| mark06 | how to merge a branch without a common ancestor? | 19:15 |
|---|---|---|
| fullermd | Manually specify the rev range to merge. Usually the whole history, i.e. "-r0..-1". | 19:17 |
| jelmer | I wonder if we should just add that as suggestion to the error message. | 19:18 |
| fullermd | I'd hesitate, I think. | 19:18 |
| fullermd | Worth a FAQ entry, maybe. If we have a FAQ. | 19:22 |
| mark06 | 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:30 |
| mark06 | is there a way to specify a bug in commit comment without using full URL? | 19:32 |
| mark06 | I want to reference bug 308562 in the dummy initial commit | 19:33 |
| ubot5 | 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 |
| jelmer | mark06: there is the --fixes option which adds a commit property | 19:33 |
| mark06 | I know, but it doesn't fix the above bug :) | 19:33 |
| jelmer | mark06: it allows you to use shortcuts for bug tracker URLs | 19:33 |
| jelmer | mark06: --fixes lp:4545 will reference http://bugs.launchpad.net/4545 | 19:34 |
| ubot5 | Ubuntu bug 4545 in amsn (Ubuntu) "amsn crashes on start-up/won't load" [Medium,Fix released] | 19:34 |
| mark06 | 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 |
| jelmer | mark06: I'm not sure I follow what you mean in that case | 19:35 |
| jelmer | mark06: do you want to reference a bug without actually changing anything else? | 19:35 |
| jelmer | mark06: you want --unchanged in that case | 19:36 |
| mark06 | I'm already using --unchanged | 19:36 |
| fullermd | I think you're just trying to outsmart yourself :) | 19:36 |
| mark06 | I want to reference the bug in the commit comment, something like: | 19:36 |
| fullermd | Just reference "LP bug 12345" in the commit message. | 19:36 |
| ubot5 | Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345 | 19:36 |
| fullermd | ISDN? Yeesh. How 1990's :p | 19:37 |
| mark06 | yeah fullermd, just wondered if it was possible | 19:37 |
| jelmer | mark06: Why though? This is what the commit properties are used for, and what all bzr tools will display | 19:37 |
| jelmer | Having two different ways of referencing bugs would seem very confusing to me, and not particularly useful. | 19:38 |
| mark06 | jelmer: ...something like: bzr commit -m "This is a dummy, empty commit required because of bug lp:308562" | 19:39 |
| jelmer | mark06: ah, no, there isn't any way to do that. I don't think that would be particularly useful. | 19:41 |
| mark06 | 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:42 |
| mark06 | about the dummy commit, nothing much important | 19:43 |
| mark06 | or --fixes=revision | 19:43 |
| jelmer | mark06: what do you mean with --not-very-important, what would that do? | 19:43 |
| mark06 | 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 |
| jelmer | 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 |
| mark06 | yeah, as a property then... | 19:45 |
| mark06 | is it possible to add arbitrary properties and have them showing in qlog juts like tags or --fixes? | 19:46 |
| jelmer | mark06: you'd have to have a plugin installed that can display those properties | 19:47 |
| jelmer | similarly though, you'd need a plugin to set them | 19:47 |
| mark06 | :( | 19:48 |
| mark06 | what's the difference between -r 0..-1 and -r 1..-1? | 19:51 |
| fullermd | 1 8-} | 19:51 |
| fullermd | 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:52 |
| Guest40826 | Could someone explain to me the relationship between repositories and branches in bzr? | 19:53 |
| jelmer | Guest40826: the repository is the thing that holds the revisions, and a branch is a line of history | 19:54 |
| mark06 | how about the merge command, does it make any difference like merging uncommitted commits or something? | 19:54 |
| fullermd | mark06: Yes, -r1..-1 would mean the revs {2,3,4,...,-1}, in contrast to 0..-1 meaning {1,2,3,...,-1} | 19:55 |
| Guest40826 | So, if I want to have two completely separate projects, would I create two separate repositories for them? | 19:55 |
| jelmer | 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:56 |
| fullermd | However, if they really are completely separate, there would be no _gain_ from having them both in the same repo. | 19:57 |
| jelmer | indeed | 19:57 |
| fullermd | 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:57 |
| mark06 | fullermd: ah thanks! | 19:58 |
| fullermd | Probably pretty unimportant, unless either branch is huge. | 19:58 |
| Guest40826 | 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:58 |
| Guest40826 | Do I have that right? | 19:59 |
| jelmer | Guest40826: yep | 19:59 |
| fullermd | 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 |
| mark06 | maybe just create standalone branches (each branch contains its own repo) | 19:59 |
| Guest40826 | mark06: What do you mean by that? | 20:00 |
| fullermd | Guest40826: What's your VCS background? | 20:00 |
| Guest40826 | almost strictly svn | 20:00 |
| fullermd | OK. So the difference here is that svn is very repo-centric, whereas bzr is branch-centric. | 20:01 |
| fullermd | 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:01 |
| fullermd | 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 |
| fullermd | 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:02 |
| Guest40826 | okay, so what is a standalone branch? | 20:03 |
| Guest40826 | (mentioned by mark06) | 20:03 |
| fullermd | 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 |
| fullermd | A branch that's not in a shared repo. | 20:03 |
| fullermd | How about an example... | 20:04 |
| fullermd | "mkdir ~/work ; cd ~/work ; bzr init projA ; bzr init projB" | 20:04 |
| fullermd | 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 |
| fullermd | Or add a step instead: | 20:05 |
| fullermd | "mkdir ~/work ; cd ~/work ; bzr init-repo . ; bzr init projA ; bzr init projB" | 20:05 |
| fullermd | Now you've got two unrelated branches to work in, both of which use the shared repo for their history storage. | 20:06 |
| fullermd | 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 |
| fullermd | For pretty much anything you _do_ day to day, the two cases are identical. | 20:06 |
| fullermd | Unlike svn, the repo isn't [generally] a semantically meaningful unit. It's the branches that are the granularity you work with. | 20:07 |
| fullermd | And in this case, it doesn't convey any advantages, since the two projects don't share any history. | 20:07 |
| fullermd | Where it's useful is when you have projA-trunk/ and projA-frob_foo/ and projA-from_bar/ branches, which _are_ related. | 20:08 |
| fullermd | Standalone, each would have the entire history (both the stuff common to all of them, and the new stuff in each) | 20:08 |
| fullermd | 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 |
| Guest40826 | 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:09 |
| Guest40826 | Which sounds to me like one repo with two branches in it for Team B. | 20:10 |
| fullermd | Is that 3 codebases, or 2 (one shared, one B-only)? | 20:11 |
| Guest40826 | 3 total - one for team A, the other two for team B | 20:11 |
| fullermd | I'd just make one repo for each codebase then. | 20:11 |
| fullermd | Sharing a repo between unrelated codebases doesn't gain you anything, so go for simplicity. | 20:12 |
| Guest40826 | okay | 20:12 |
| Guest40826 | so how do I serve those two repos for team B at the same domain? | 20:14 |
| Guest40826 | Just by placing the two repos in the same directory and giving team B access to that parent? | 20:14 |
| fullermd | Yeah. | 20:14 |
| fullermd | How are you accessing them? bzr+ssh? | 20:15 |
| Guest40826 | That is another question I have :( | 20:15 |
| Guest40826 | Is there a difference between bzr and bzr+ssh | 20:15 |
| Guest40826 | ? | 20:15 |
| fullermd | 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:16 |
| Guest40826 | 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 |
| Guest40826 | *is | 20:17 |
| fullermd | Note that bzr doesn't have any concept of AAA, so in general you'd only use it for readonly stuff. | 20:18 |
| fullermd | (bzr:// that is) | 20:18 |
| Guest40826 | Okay, | 20:18 |
| Guest40826 | I am going to be accessing this using bzr+ssh | 20:18 |
| Guest40826 | With user accounts being restricted to bzr | 20:19 |
| mark06 | http://i.imgur.com/z0zsX.png o/ | 20:28 |
| fullermd | Definitely an odd use of tags. | 20:32 |
| mark06 | actually I changed it to fixes_rev_0.11.5 on 0.11.6 | 20:42 |
| fullermd | Yeah, that would also fall under "pretty odd" :p | 20:43 |
| mark06 | yeah I know :) | 20:45 |
| mark06 | oh wait, fixed_by_0.11.6 :) | 20:46 |
| * fullermd reaches for the smelling salts. | 20:47 | |
| mark06 | 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:54 |
| fullermd | That's not exactly a bug. | 20:55 |
| mark06 | I would personally add a merge conflict to let the user decide | 21:07 |
| fullermd | The trouble is, there's no way to record a resolution. | 21:07 |
| fullermd | 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:08 |
| fullermd | I guess it doesn't. That's probably worth a bug. | 21:09 |
| mark06 | hmm ok leaving... thank you all! | 21:21 |
| fullermd | Oh look, a Wacky Log Bug. | 22:25 |
| jelmer | fullermd: where? | 22:27 |
| fullermd | 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:28 |
| Konomi | hi I am trying to use checkout and I am doing bzr checkout sftp://user:pass@host | 22:29 |
| Konomi | and bazaar seems to ignore hte pass field entirely and still ask for a password | 22:30 |
| fullermd | That's because bzr doesn't have access to the password-asking; sftp talks to your terminal directly for that. | 22:30 |
| Konomi | is there anyway to automate it at all? | 22:30 |
| Konomi | I get sick of typing in a password everytime? | 22:30 |
| fullermd | Use key auth (possibly with the aid of ssh-agent). | 22:32 |
| Konomi | meh okay thanks for your help fullermd | 22:33 |
| fullermd | 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:34 |
| Konomi | what is a bit annoying is http://doc.bazaar.canonical.com/bzr.1.11/developers/authentication-ring.html | 22:35 |
| Konomi | says I can embed the pass in the url but I guess it doesn't note the exception for sftp | 22:35 |
| Konomi | 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 |
| Konomi | thanks again | 22:37 |
| fullermd | Boy, this thing is tricksy... | 23:03 |
| lifeless | fullermd: which thing ? | 23:21 |
| fullermd | Weird log bug I'm tracking. | 23:21 |
| bob2 | why would you not just use keys | 23:27 |
| lifeless | harmony | 23:29 |
| fullermd | Yeah, you might be Berg or Schoenberg. | 23:30 |
| bob2 | it is far too early on a monday for classical music jokes | 23:31 |
| fullermd | Good thing it's late on a sunday 8-} | 23:31 |
| * fullermd writes up a terribly confusing bug... | 23:53 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
