| toddw | howdy, anyone know if I can get bzr status to work non-recursively, i.e. to not report on child directories? | 02:04 |
|---|---|---|
| spiv | toddw: bzr st `find . -maxdepth 1 ! -type d` | 02:09 |
| spiv | toddw: I think adding a --no-recurse option to bzr status would be a reasonable feature request. | 02:09 |
| toddw | spriv: nod, what about windows :D | 02:09 |
| toddw | spiv: thanks, I'll make the bug request | 02:10 |
| spiv | toddw: cygwin ;) | 02:10 |
| ericvw | oders | 02:11 |
| * ericvw wrong window | 02:11 | |
| lifeless | toddw: a use case would be good too | 02:17 |
| lifeless | toddw: because all the times I've seen someone want that so far, its really been a svnism | 02:17 |
| toddw | heh, it's for a GUI that does only wants to show the status of a particular directory | 02:18 |
| lifeless | I'd much rather guis use the scriptable interfaces - | 02:22 |
| lifeless | ls, xmlrpc, or plain python | 02:22 |
| lifeless | I'd also ask *why* the gui wants to only know one directories status | 02:23 |
| toddw | nod, I don't know a lot on the scriptables, does that require the GUI to provide their own install of bzr? | 02:24 |
| lifeless | no | 02:25 |
| lifeless | the reasoning here - status is for humans, we will continually adapt it to make it more useful | 02:25 |
| lifeless | GUI's that are generating data should depend on programmatic interfaces that are less subject to make-it-pretty changes | 02:26 |
| lifeless | as for doing one dir vs the whole tree | 02:26 |
| lifeless | its much more efficient to do the whole tree once than to call into bzr once per directory | 02:26 |
| lifeless | (and I mean _MUCH_ more efficient) | 02:26 |
| toddw | is there info on these scritables part? | 02:27 |
| lifeless | yes | 02:27 |
| lifeless | the IntegratingWithBazaar wiki page talks about the xmlrpc interface used by bzr-eclipse and other IDE's | 02:28 |
| lifeless | the bazaar pydoc/pydoctor API documentation talks about using the python interface directly, and there are examples on th ewiki | 02:28 |
| toddw | there is an additional plugin to provide xmlrpc, does not seem that friendly - additional step(s) | 02:37 |
| toddw | or use the python bzr library files, which sounds good, but I'm guessing I'd need to find both the library files and the correct python installation to run it | 02:37 |
| toddw | honestly, the --non-recursive command line option is looking much simpler for me | 02:38 |
| fullermd | Oh look, another project doing a source control vote between hg and git... | 03:09 |
| lifeless | fullermd: whom | 03:11 |
| fullermd | Dragonfly[BSD] | 03:12 |
| fullermd | Git seems to be leading about 2:1 | 03:12 |
| fullermd | Right up top of http://news.gmane.org/gmane.os.dragonfly-bsd.kernel/ | 03:14 |
| === cafuego is now known as buggerror | ||
| === buggerror is now known as cafuego | ||
| uniscript | any idea when a bzr-svn update to correspond to bzr 1.8 is due out? | 04:28 |
| jelmer | uniscript, 0.4.13 works with 1.8 | 04:37 |
| uniscript | so why did the bzr update from ppm push out bzr-svn? | 04:38 |
| jelmer | uniscript, ppa hasn't been updated yet | 04:38 |
| uniscript | for bzr-svn? | 04:38 |
| jelmer | yeah | 04:39 |
| uniscript | OK, any idea when? | 04:39 |
| uniscript | I want my bzr-svn back :) | 04:39 |
| jelmer | no, sorry | 04:39 |
| uniscript | ah so I should get the source package and change the depends and rebuild | 04:39 |
| uniscript | OK | 04:39 |
| jelmer | jam usually does the ppa uploads, not sure what his plans are | 04:41 |
| uniscript | is he uk TZ based? | 04:42 |
| jelmer | uniscript: yeah, or alternatively you can install the debian experimental package | 04:42 |
| jelmer | US based | 04:42 |
| uniscript | package built | 04:42 |
| uniscript | aah build failed ah well time to add ppa to pdebuild :) | 04:43 |
| jfroy | jelmer: how goes 0.5, BTW? | 05:33 |
| jfroy | I never sent you an update on those Unicode exceptions, BTW, because I couldn't reproduce them with the current top of tree | 05:34 |
| jfroy | jelmer: also, in the event of a catastrophic "you screwed up", doing a Subversion repository dump and re-import, with a filter to leave out the bzr-svn properties, should allow a clean start, right? | 05:34 |
| === jaypipes is now known as jaypipes-afk | ||
| vila | hi all | 07:10 |
| * fullermd waves vila. | 07:18 | |
| === AnMaster_ is now known as AnMaster | ||
| poolie | hi vila | 09:33 |
| vila | hi ! | 09:34 |
| === sabdfl1 is now known as sabdfl_epic | ||
| ace | hi the happy community | 10:52 |
| ace | can you give me a link to a nice doc that compare bzr and git? | 10:52 |
| luks | you can't find anything objective | 10:53 |
| ace | ok | 10:54 |
| ace | is there a doc that explain big changes between CVS/svn and bazaar ? | 10:54 |
| AfC | ace: are you already a Bazaar user? | 10:54 |
| ace | no | 10:54 |
| ace | i m a CVS/SVN user for 8 years | 10:54 |
| AfC | ace: tell you what, then. Why don't you just use Bazaar, and then you won't have to worry about comparing it to Git. | 10:54 |
| ace | and i want to discover what make bazaar so different and better before using it :) | 10:55 |
| fullermd | That's one way to shortcut documentation :p | 10:55 |
| AfC | fullermd: I thought so, yes | 10:55 |
| ace | ok i ll continue to googlize then | 10:55 |
| uniscript | ace, which one do you want to win the comparison? If you want git to win, go to the git site and if you want bzr to win got to the bzr site :) | 10:55 |
| ace | lol | 10:56 |
| uniscript | it really depends what is important to you | 10:56 |
| fullermd | Which one wins if you go to the darcs site? | 10:56 |
| AfC | ace: have you read Bazaar's user manual? Why don't you start with that. | 10:56 |
| ace | afc: i ll do that | 10:56 |
| uniscript | fullemd - mercurial of course! | 10:56 |
| fullermd | Blast their sneaky liquid metal hides! | 10:56 |
| uniscript | btw here's my take given a dev team here just went from svn -> git -> hg (I wonder how long before the see real sense) | 10:59 |
| uniscript | svn is centralised, yawn. git is fast, powerful and nearly unusable, | 10:59 |
| ace | uniscript: why unusable? | 10:59 |
| uniscript | hg doesn't have hgpushsvn which makes it useless if you want to work with an svn repo | 10:59 |
| ace | too hard to setup? | 11:00 |
| ace | what is hg? | 11:00 |
| uniscript | the strikes against git are: revisions are all shar hashes and auto tagging is a pain | 11:00 |
| uniscript | hg is mercurial | 11:00 |
| ace | ah ok | 11:00 |
| ace | why hg? | 11:00 |
| uniscript | mercurial is perceived to be nice on windows due to tortoisehg | 11:00 |
| ace | there s no H nor G in mercurial | 11:00 |
| luks | which is a gtk application ;) | 11:00 |
| uniscript | why there can't be one big tortoise project with plugable backends I have no idea | 11:00 |
| fullermd | ace: Check your periodic table of elements :p | 11:01 |
| ace | aaahhhh lol they are crazy | 11:01 |
| uniscript | so ease of use and model goes to bzr | 11:01 |
| uniscript | integration with svn goes to bzr | 11:01 |
| uniscript | speed still doesn't go to bzr but it's getting better | 11:02 |
| uniscript | I *like* bzr it just feels right | 11:03 |
| uniscript | the rest all seem to be that you are working around stuff | 11:03 |
| uniscript | if you are workign on the kernel, you will have to use git | 11:03 |
| uniscript | as I say, it all depends on what is important to you | 11:03 |
| LeoNerd | ace: Hg is the chemical symbol for mercury | 11:03 |
| ace | LeoNerd: yes i understood :) | 11:03 |
| ace | i have a big source tree, bzr will be too slow? | 11:03 |
| luks | big is pretty relative | 11:04 |
| luks | how big is big? | 11:04 |
| AfC | ace: unless your big is >>> Mozilla, no, it'll be fine. | 11:04 |
| fullermd | Also depends on what way the big is. | 11:04 |
| LeoNerd | I've used bzr on trees of 4,000 HTML and Perl files. That worked just fine. | 11:04 |
| LeoNerd | Hellofalotquicker than the CVS that used to run it | 11:04 |
| fullermd | Long histories are where bzr really eats itself. Large trees with lots of files, not so hard. Very large files, hard again. | 11:04 |
| ace | let me check | 11:05 |
| * fullermd considers "big" to start at a hundred thousand revs of a hundred thousand files. | 11:05 | |
| ace | 5000 Cpp sources ode for a total of 60mb of text files | 11:06 |
| AfC | ace: that's tiny. | 11:06 |
| ace | ok | 11:06 |
| sabdfl_epic | you won't have performance issues with that tree and bzr | 11:06 |
| ace | perfect then | 11:06 |
| sabdfl_epic | not even if the tree grows 4x | 11:06 |
| luks | you will only have the usual startup performance issues :) | 11:06 |
| AfC | The ones that really blow my mind are the Apache mob. They have *all* projects in a *single* Subversion repository. It has over 700,000 revisions in it. Gadzooks. | 11:07 |
| mwhudson | AfC: kde too | 11:07 |
| luks | AfC: why exactly is that bad? | 11:07 |
| sabdfl_epic | it just really constrains your options | 11:07 |
| fullermd | Well, it's not by itself; only after you point bzr-svn at it :p | 11:07 |
| AfC | mwhudson: Oh yeah? Haven't tried to import any KDE code lately :) | 11:08 |
| mwhudson | it's about the same size i think, ~750k revisions | 11:08 |
| luks | that's the price for abusing svn :) | 11:08 |
| fullermd | s/ab// | 11:08 |
| luks | if you use it the svn way, it's fine | 11:08 |
| AfC | luks: well, for one thing, it means several hundred completely unrelated projects are entirely dependent on a single on disk structure. | 11:09 |
| AfC | luks: Another is that it means they are all contending for unique resources (the primary key problem). | 11:09 |
| luks | AfC: that's a problem apache sysadmins have to consider, not you | 11:09 |
| AfC | luks: Third is, well, "HELLO, no bloody way am I putting my precious source code in a single point of failure like that!" | 11:09 |
| AfC | :) | 11:09 |
| AfC | luks: see point 3 then :) | 11:09 |
| fullermd | Well, and that's the sort of load and use-case svn is designed to push for. | 11:09 |
| sabdfl_epic | i would have recommended a more granular structure | 11:10 |
| AfC | yeah. | 11:10 |
| sabdfl_epic | makes it just that much easier to reconfigure, rearrange | 11:10 |
| sabdfl_epic | teaches better coding practice! | 11:10 |
| luks | sabdfl_epic: actually, it's not true | 11:11 |
| sabdfl_epic | but would have required more thought and possibly more sophisticated project infrastructure | 11:11 |
| luks | one big svn repository is much more flexible | 11:11 |
| * fullermd gets all snarky at the thought of "better coding practice" and "java and XML everything"... | 11:11 | |
| sabdfl_epic | fsvo flexible | 11:11 |
| luks | moving history from one repo to another is a pain | 11:11 |
| AfC | ... but you know the Apache mob mindset. Not even "Our way or the highway" because they tend to just focus on "Our way" | 11:11 |
| luks | with a single repo you can rename/move anything | 11:11 |
| luks | I personally use svn the same way | 11:12 |
| luks | it's just easier | 11:12 |
| sabdfl_epic | does svn not provide a facility for nested trees through externals? | 11:12 |
| AfC | Well. Nice jamming with you lot. Time to get out for a drink. | 11:13 |
| fullermd | That's not the only use case. Take splitting off a part of a project into a new project of its own; in one big repo, you can do that with svn. You can't, with the same capability, do it with bzr at all. | 11:14 |
| AfC | fullermd: that's true. The join/fork story here could be a lot nicer. Alas. | 11:14 |
| fullermd | Yeah. Your choices are either (a) throw away all the history, (b) drag along a lot of unrelated history, or (c) recreate a mirror of the history (which may or may not be sufficiently easy, but still breaks all previous and future merging across the boundary) | 11:15 |
| fullermd | It CAN'T be done as simple as svn, internally. And it would take a lot of infrastructural work and papering to make something functionally equivalent work reasonably well. | 11:17 |
| fullermd | (which isn't bzr-specific at all of course. git or hg or anybody else who conceptually works in full trees would have the same issues) | 11:17 |
| jml | if I move my branches, how do I make my checkouts point to the new location? | 12:00 |
| LeoNerd | Personally I'd vim .bzr/branch/branch.conf | 12:03 |
| bob2 | bzr bind blah | 12:06 |
| LeoNerd | That doesn't fix up all the locations though... push/missing etc | 12:06 |
| mwhudson | vila: hello! | 12:11 |
| === Verterok|out is now known as Verterok | ||
| spiv | jml: bzr switch, possibly with --force, if I'm understanding the question correctly? | 12:26 |
| vila | mwhudson: hi ! | 12:28 |
| jml | spiv: probably | 12:28 |
| spiv | jml: (or edit .bzr/branch/location manually, assuming these are lightweight checkouts...) | 12:29 |
| jml | spiv: thanks. | 12:33 |
| mwhudson | vila: Ng would like to talk to you, i hope :) | 12:36 |
| jml | btw, if anyone is curious, bzr on a largish tree in an encrypted filesystem is basically unusable. | 12:38 |
| spiv | jml: lifeless would be, I bet | 12:41 |
| Ng | vila: it's about bzr's http requests | 12:42 |
| * vila listening | 12:42 | |
| Ng | if I see this in a .bzr.log..... | 12:42 |
| Ng | 22.384 * About to connect() to squid.internal:3128(proxy for bk-internal.mysql.com) | 12:42 |
| Ng | 22.384 > GET http://bk-internal.mysql.com/bzr-mysql/.bzr/repository/packs/4390f40920ca612296692194f5c6235d.pack | 12:42 |
| Ng | 22.385 > Host: bk-internal.mysql.com | 12:42 |
| Ng | is that *exactly* what was sent? ie there was no HTTP/blah after the URL? | 12:43 |
| Ng | the request looks like HTTP/1.1, but afaik if you don't *say* HTTP/1.1 you may not get it, and in this case it's not | 12:43 |
| vila | What that produced with -Dhttp ? | 12:44 |
| mwhudson | yes | 12:44 |
| vila | urlib or pycurl ? | 12:44 |
| Ng | how would I determine that? | 12:44 |
| vila | nm, if it's .bzr.log it's urllib, sry | 12:45 |
| mwhudson | the puller forces urllib | 12:45 |
| vila | Ng: Ok, relevant line is 517 in _urllib2_wrappers and indeed is restricted to method and url, so the don't worry, the right headers should be send, but if you used -Dhttp, you should see that too in .bzr.log | 12:47 |
| vila | But if you're observing the whole file being transfered instead of just the range requests, there is a known bug in Squid, what version are you using ? | 12:48 |
| Ng | vila: 2.6.18 | 12:48 |
| vila | and for the first part of the question ? Did I guess right ? | 12:49 |
| Ng | vila: I'm not exactly sure, bzr just seems to hang | 12:54 |
| vila | Can't remember the squid version it was fixed in, spiv and lifeless knows it by heart I'm pretty sure... | 12:55 |
| vila | hang for how long ? What size is the pack file ? | 12:55 |
| Ng | it's 8MB, it hangs for about 10 minutes and then says: InvalidHttpResponse: Invalid http response for http://bk-internal.mysql.com/bzr-mysql/.bzr/repository/packs/4390f40920ca612296692194f5c6235d.pack: Expected a boundary (squid/2.6.STABLE18:CDF2964E12A3A3AF0D83A580AC47D079) line, got '' | 12:55 |
| vila | Yeah, sounds like it, I'm still searching the relevant bug report, sorry for the delay | 12:56 |
| Ng | np | 12:56 |
| fullermd | Yeah, I remember that one... | 12:57 |
| fullermd | bug 198646 maybe? | 12:58 |
| ubottu | Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] https://launchpad.net/bugs/198646 | 12:58 |
| * vila was thinking about putting fullermd inside ubottu seconds ago :) | 12:59 | |
| fullermd | > This was fixed in the 2.6.STABLE19 release [...] | 12:59 |
| vila | fullermd: yeah ! Well done | 12:59 |
| fullermd | It's always one version more than you have ;) | 12:59 |
| vila | Ng: as fullermd said ^ | 13:00 |
| * fullermd has validated his oxygen consumption for the day! | 13:00 | |
| vila | Ng: upgrade your squid and you should be fine | 13:00 |
| Ng | vila: ok thanks very much | 13:01 |
| fullermd | Or if you have access to use sftp/bzr+ssh, so you don't hit squid. | 13:01 |
| Ng | fullermd: thanks too :) | 13:01 |
| vila | Ng: have a look at the bug report anyway as there are some more explanations | 13:02 |
| Ng | yep, am reading it :) | 13:02 |
| fullermd | I think I'll celebrate by dredging up a sandwich, and then getting back to the eternal joy of writing documentation... | 13:03 |
| some3kksf | hi all | 13:07 |
| Peng_ | some3kksf: Hi? | 13:08 |
| ace | tell me, does "bazar" means something in english? | 14:53 |
| Jc2k | ace: http://www.thefreedictionary.com/bazar | 14:54 |
| ace | funny | 14:54 |
| Odd_Bloke | ace: It stems from "The Cathedral and the Bazaar" by esr. | 14:56 |
| ace | ah ok | 14:57 |
| ace | it has sense | 14:57 |
| === SteveA_ is now known as SteveA | ||
| === jaypipes-afk is now known as jaypipes | ||
| james_w | do directory services have a way of influencing what directory name is created when you don't specify one to "bzr branch"? | 15:46 |
| jelmer | james_w, afaik not | 15:55 |
| james_w | it doesn't look like from the code | 15:56 |
| james_w | oh well | 15:56 |
| NfNitLoop | I'm getting an error: [Errno 1] Operation not permitted | 16:22 |
| NfNitLoop | Is there a way to run bzr in verbose/debug mode? | 16:23 |
| NfNitLoop | I tried -v and --verbose with no luck. | 16:23 |
| james_w | NfNitLoop: try -Derror | 16:24 |
| james_w | NfNitLoop: and "bzr --version" will tell you where your log file is located, that will have more information | 16:25 |
| NfNitLoop | actually, a bit of googling found my exact error (and solution): | 16:27 |
| NfNitLoop | https://bugs.launchpad.net/bzr/+bug/183948 | 16:27 |
| ubottu | Ubuntu bug 183948 in bzr "can't PUSH over an sshfs fuse file share" [Undecided,Won't fix] | 16:27 |
| NfNitLoop | it's an issue with sshfs, not bzr. | 16:28 |
| james_w | -orename? | 16:30 |
| matkor | Hi ? Is it possible to get from bzr only conflictin file names ? | 16:45 |
| james_w | matkor: bzr conflicts? | 16:47 |
| james_w | vim $(bzr conflicts --text) | 16:47 |
| matkor | james: Great ! Thanks a lot that's what I am looking for | 16:48 |
| Pieter | https://bugs.launchpad.net/bzr-fastimport/+bug/287785 is there a way to assign that bug to me or so? | 16:52 |
| ubottu | Ubuntu bug 287785 in bzr-fastimport "bzr-fastexport crashed in git-bzr -- broken pipe" [Undecided,New] | 16:52 |
| Pieter | I'm not really sure how launchpad works | 16:53 |
| james_w | Pieter: yeah, there is | 16:53 |
| Pieter | oh, I found the drop down thingie | 16:53 |
| james_w | yup | 16:53 |
| evarlast | i was working bound to a repo, did a few local commits, then when I was back online, I did a bzr update, and it deleted a bunch of files. How can I get back my files that were in my local commits? | 17:13 |
| Spaz | evarlast, bzr help revert | 17:21 |
| evarlast | but revert to what? | 17:22 |
| Spaz | also, does bzr work ok with rbash instead of regular bash? | 17:22 |
| evarlast | bzr log shows only server revs, not my local commits. | 17:22 |
| Spaz | evarlast, i don't know, hence why i said use bzr help revert | 17:22 |
| Spaz | i'm not psychic | 17:22 |
| Spaz | i do not know what revisions had the files that got deleted | 17:22 |
| Spaz | o_O | 17:22 |
| fullermd | If you install the heads plugin, you can use it to find the revid of your old local commit head. | 17:22 |
| Spaz | ooh | 17:22 |
| evarlast | ok, so new question driven by spaz, how can I revert to a local commit or see them in logs. | 17:22 |
| Spaz | see fullermd's comment ^ | 17:22 |
| fullermd | Then you can merge it in. | 17:23 |
| evarlast | wow, so I need the heads plugin to see local commits in the log? | 17:23 |
| fullermd | That's... too narrow and too broad to answer. | 17:25 |
| evarlast | seems like I should be able to bzr log --local or something. | 17:25 |
| fullermd | When you update with local commits, they should be turned into pending merges. Various things you can do from that point (including revert) can lead to them being off in never-never land. | 17:25 |
| fullermd | No, 'local' doesn't really mean anything special in this case. | 17:25 |
| fullermd | There's only log, and log works backward from a head. Those revisions aren't in the history of your current head. | 17:26 |
| evarlast | it did when I bzr commit --local, didn't it? | 17:26 |
| fullermd | Not exactly, no. | 17:26 |
| evarlast | oh, so I should move my current head? | 17:26 |
| fullermd | But the revs are still in your repository. The heads plugin lets you find unreferenced revs in the repo, so once you find the revid, you can force your head to change to that, or merge it in, or whatever is appropriate. | 17:27 |
| fullermd | Sorry I can't do details; I'm way overdue to be off elsewhere :| | 17:27 |
| evarlast | ok, I have heads, but the guy with the real problem doesn't :( | 17:28 |
| fullermd | Local commits are a treacherous corner. When you do them, you're working in a distributed fashion, with a layout that works in a centralized fashion. There are a lot of dragons in a setup like that. | 17:29 |
| evarlast | strangely, he did commit local, then he did bzr up, and I would expect them to be pending merges, but bzr status doesnt' show them as such | 17:30 |
| evarlast | so how to restore the old dead head? | 17:38 |
| evarlast | i've got a dead head, but I want files out of it. | 17:41 |
| evarlast | ah, the nastly long revid: from the heads list. | 17:51 |
| evarlast | thanks. | 17:52 |
| evarlast | special thanks to Spaz and fullermd | 17:52 |
| Spaz | np | 17:58 |
| abentley | fullermd: heads is part of bzrtools nowadays. | 18:22 |
| AnMaster | Hi, what command does bzr smart server run? | 18:47 |
| AnMaster | I can't figure out what force command to set in sshd_config | 18:47 |
| AnMaster | to disallow anything except bzr | 18:48 |
| luks | it runs `bzr server --inet ...` | 18:48 |
| AnMaster | luks, and what extra parameters after that? | 18:49 |
| luks | um, I don't know | 18:49 |
| Spaz | AnMaster, probably whatever command the client asked is my guess | 18:49 |
| luks | there is a wrapper script which might be easier to use for this | 18:49 |
| luks | Spaz: no | 18:49 |
| AnMaster | luks, oh? got a link? | 18:49 |
| AnMaster | luks, I guess it would need repo path | 18:50 |
| luks | `bzr serve --inet --allow-writes --directory=/` would be my guess | 18:50 |
| luks | AnMaster: it's in contrib/ in the tarball | 18:50 |
| luks | contrib/bzr_access | 18:50 |
| AnMaster | hm, installed from ports on freebsd so that means *looks at launchpad branch* | 18:50 |
| Spaz | AnMaster, no | 18:50 |
| luks | you can have per-repository permissions | 18:50 |
| Spaz | AnMaster, cd /usr/ports/devel/bzr; make fetch; make extract; cd work/ | 18:51 |
| AnMaster | Spaz, more complex | 18:51 |
| Spaz | though i suppose that's like killing a bird with a boulder | 18:51 |
| AnMaster | also build tree not same as ports tree | 18:51 |
| AnMaster | aye it is | 18:52 |
| AnMaster | but would be faster ;P | 18:52 |
| AnMaster | launchpad is slow atm | 18:52 |
| AnMaster | "Sorry, there was a problem connecting to the Launchpad server." | 18:53 |
| AnMaster | at http://bazaar.launchpad.net/~mbp/bzr/bzr.1.8/files | 18:53 |
| Spaz | someone forgot to feed the hamsters powering the server | 18:53 |
| * AnMaster sighs | 18:53 | |
| AnMaster | ah works now | 18:53 |
| RaceCondition | is the main difference between branches and repositories that repositories are branches without a working tree? | 19:32 |
| jfroy|work | RaceCondition: repositories are containers for branches, nothing more | 19:35 |
| jfroy|work | they allow for efficient data sharing for related branches | 19:35 |
| RaceCondition | can repositories be worked in, i.e. do they have a working tree? | 19:35 |
| jfroy|work | (e.g. branches with a common ancestor) | 19:35 |
| RaceCondition | and does the data sharing efficiency only come into play when all branches in the repository are on the same machine/disk? | 19:36 |
| jfroy|work | no, again, repositories store branches, period | 19:36 |
| jfroy|work | branches have working trees | 19:36 |
| RaceCondition | yes, I know that | 19:36 |
| RaceCondition | I'm trying to draw parallels to other VCS's | 19:36 |
| jfroy|work | And yes, the savings are realized for the branches stored in a particular repository | 19:37 |
| RaceCondition | so in which real life situations I would use a repository? | 19:37 |
| jfroy|work | You should always use one! | 19:37 |
| jfroy|work | You should use many in fact, typically one per project | 19:38 |
| jfroy|work | to store your local branches for said projects | 19:38 |
| RaceCondition | why not just use branches? | 19:38 |
| jfroy|work | anytime you plan on storing related branches, you should put them in a repository, to gain the efficient storage benefits | 19:38 |
| RaceCondition | I mean, what's the benefit of having branches in a repository as opposed to having them stand alone? | 19:38 |
| jfroy|work | storage efficiency | 19:38 |
| RaceCondition | other than that | 19:38 |
| jfroy|work | none that I am aware of | 19:39 |
| jfroy|work | by efficiency, I mean mostly disk space | 19:39 |
| RaceCondition | yeah | 19:39 |
| jfroy|work | which could potentially significantly improve speed, because disk access is slow | 19:39 |
| RaceCondition | I'm not aware of what format bazaar uses for repositories though.. I know git stores everything in files so it can simply use hardlinks when cloning a repository | 19:40 |
| awilkins | RaceCondition: Bazaar uses packs | 19:40 |
| jfroy|work | indeed | 19:40 |
| jfroy|work | and hard links are support as well | 19:40 |
| jfroy|work | but not used by default, I believe | 19:40 |
| RaceCondition | are packs modified or are they immutable? | 19:40 |
| awilkins | RaceCondition: But using repositories in Bazaar is more that all the branches inside it use the same packs, not that the packs are copied as hardlinks | 19:41 |
| RaceCondition | but if hardlinks are possible, why are repositories used? sorry for so many questions, I'm just trying to get the picture here | 19:41 |
| awilkins | RaceCondition: Bazaar objects are immutable, just like git objects - packs are not immutable in either Bazaar or git | 19:41 |
| RaceCondition | are packs stored as multiple files then or as a single file? | 19:42 |
| awilkins | RaceCondition: Packs are stored as one or more files | 19:42 |
| awilkins | And may be repacked | 19:42 |
| RaceCondition | I see | 19:42 |
| awilkins | The main advantage of a shared repo in Bazaar is that branches do not copy the entire repository when you make a new one | 19:43 |
| RaceCondition | so basically achieving the same thing git does with hardlinks using a different approach | 19:43 |
| jfroy|work | indeed, creating a branch stored in a repository inside the same repository is nearly instantaneous; it's great :) | 19:43 |
| awilkins | git is also pretty instant because a branch starts off as one 40 byte file | 19:44 |
| RaceCondition | why are most commands kinda slowish though? Python environment start up overhead? | 19:44 |
| awilkins | RaceCondition: Which version and platform are you using? | 19:44 |
| jfroy|work | and how many plugins | 19:44 |
| jfroy|work | (and which) | 19:45 |
| awilkins | Yes, also relevant | 19:45 |
| RaceCondition | awilkins: I'm actually the most confortable using darcs but I've lately started using git because of it's speed and large community/tool support | 19:45 |
| RaceCondition | but I really hate that it's unintuitive and is very hard to learn | 19:45 |
| RaceCondition | I'm a programmer and consider myself a good learner, but git really gets me by the balls sometimes | 19:45 |
| jfroy|work | Ah, I've been there as well. I could never figure out git entirely, bzr was very easy to pick up in comparison. | 19:46 |
| awilkins | Here, "bzr st" takes less than a second in a reasonable size tree (870 items) (win32, core2duo 2gb, vista, bzr 1.8) | 19:46 |
| jfroy|work | There are other advantages. Being in Python makes it easily hackable and readable (something shared by Mercurial). | 19:46 |
| RaceCondition | well most commands are instantaneous in git :) | 19:46 |
| RaceCondition | which I really enjoy | 19:46 |
| jfroy|work | And I work on Mac OS X mostly, so directory versioning is critical. | 19:47 |
| awilkins | I think you are right in thinking a lot of that is down to VM setup | 19:47 |
| awilkins | Try "bzr shell" and see if that makes an appreciable difference to you | 19:47 |
| RaceCondition | jfroy|work: I work on OS X, too, but why is directory versioning critical on OS X? | 19:47 |
| jfroy|work | I think so too. Python takes a while to being up. | 19:47 |
| jfroy|work | Because of bundles, executable ones or otherwise. | 19:47 |
| jfroy|work | Frameworks, applications, document formats, plugins, are all directories on Mac OS X, and I appreciate that bzr handles them properly. | 19:48 |
| awilkins | The advantages of Bazaar for me are i) It was easy to learn ii) It's fast (was faster than SVN, now is very fast) | 19:48 |
| awilkins | iii) OK for my _users_ to learn | 19:49 |
| awilkins | iv) Written in a language that I could be productive in without a major learning effort | 19:49 |
| jfroy|work | indeed, the small learning curve makes it really easy to switch to. | 19:49 |
| RaceCondition | so back to repositories -- when doing distributed development, should each developer have a repository or should there be one or more central/main repositories per project and developers just branch remotely from that (or from each other)? | 19:49 |
| RaceCondition | jfroy|work: you are an OS X developer? | 19:49 |
| awilkins | RaceCondition: You should have a central repo, and your own repo | 19:50 |
| jfroy|work | I presume you did read it, but the bazaar guide presents a number of use case scenarios that are really great starting points. | 19:50 |
| jfroy|work | RaceCondition: I work for Apple, so yeah :p | 19:50 |
| RaceCondition | awilkins: so multiple repos and multiple branches per repo? | 19:50 |
| jfroy|work | RaceCondition: more like, a project is going to have a set of branches | 19:50 |
| awilkins | RaceCondition: Since you can push a branch to any repo (that has the same rich-root-ness!), yes | 19:50 |
| jfroy|work | Some of those branches you will want to share, some will be private (each developer can have their own set of branches) | 19:50 |
| RaceCondition | jfroy|work: cool, I like your products :P and now I know who to ask from when I can't figure out the directory layout of OS X :) | 19:50 |
| jfroy|work | All of those branches will, likely, have common ancestors. | 19:51 |
| awilkins | Yes, I find the combo of a no-trees repo and lightweight or heavyweight checkouts, plus switching, to be the most productive | 19:51 |
| jfroy|work | So, you will want to setup one, or more, repositories on networked machines to share branches among developers. | 19:51 |
| RaceCondition | ah, yeah, there are checkouts, too :P | 19:51 |
| jfroy|work | And each developer will want one, or more, repositories to store branches they are working on on their own machines. | 19:51 |
| jfroy|work | Does that make sense? | 19:51 |
| jfroy|work | Checkouts are branches, with some convenience tossed on top of it. | 19:51 |
| RaceCondition | so basically all developers have repositories plus central ones and all repositories contain all public branches of all developers + private branches? | 19:52 |
| jfroy|work | Not necessarily. | 19:52 |
| RaceCondition | well more or less | 19:52 |
| jfroy|work | Repositories contain the branches that have been created in them or pushed to them. | 19:52 |
| awilkins | Central repo doesn't have to have developer branches | 19:52 |
| RaceCondition | repository is a (partial) map of the world (development status) of a single project | 19:52 |
| jfroy|work | Correct, it will be a sub-set of all the branches. | 19:53 |
| RaceCondition | yeah, I see | 19:53 |
| jfroy|work | In almost all cases. | 19:53 |
| RaceCondition | so in most cases, branches are never stored outside of repositories? | 19:53 |
| jfroy|work | There will usually be a "mainline" or "trunk" branch, as well as "release" branches, in one, designated, central repository. | 19:53 |
| RaceCondition | yeah | 19:53 |
| jfroy|work | That central repository is not special in any ways, it is simply "designated" or "marked with a post-it note" as being the central repository. | 19:54 |
| awilkins | RaceCondition: I end up with standalone branches where I'm just using Bazaar as a deployment mechanism :-) | 19:54 |
| RaceCondition | yeah, good point | 19:54 |
| awilkins | e.g. on user machines. | 19:54 |
| RaceCondition | but, in theory, one could only use branches and never use repositories? | 19:54 |
| RaceCondition | for development, that is | 19:54 |
| jfroy|work | Yeah, I have a bunch of standalone branches for small stuff. | 19:54 |
| jfroy|work | Correct | 19:54 |
| jfroy|work | Branches can live on their own. | 19:54 |
| awilkins | Yes, but certain things are more resource-consumy and certain other things are not possible (like switch) | 19:54 |
| jfroy|work | yeah | 19:54 |
| awilkins | Actually, you can still switch without shared repos, ignore me | 19:55 |
| RaceCondition | now I'm thinking why bazaar doesn't handle this disk space sharing thing in the background and not force the programmer to think about branches AND repositories :) | 19:55 |
| awilkins | Heh, sometimes I think it could take a leaf out of gits book and have a branch format that includes the option to have multiple heads in the repo and be able to switch without external directories | 19:56 |
| RaceCondition | even though, now I realize git does this in a similar manner | 19:56 |
| RaceCondition | what about that checkout thing? is it similar to a central SVN like approach? | 19:57 |
| awilkins | Checkouts come in 2 flavours - lightweight and heavy | 19:57 |
| awilkins | lightweight commits to it's bound branch | 19:57 |
| RaceCondition | because this is what I really like about Bazaar -- my designer guy really never understands the distributed nature of DVCS'es but SVN sucks, but Bazaar has both | 19:57 |
| awilkins | heavy commits to it's local branch - AND it's bound branch | 19:57 |
| awilkins | So lightweight is the closest you get to SVN in Bazaar | 19:58 |
| jfroy|work | ayep | 19:58 |
| awilkins | Heavy is similar but you also retain the ability to work offline | 19:58 |
| RaceCondition | so heavy checkout is like an SVN checkout but "replicates" the bound branch (repository in SVN terms) locally | 19:58 |
| awilkins | And more performance at the expense of local disk space | 19:58 |
| RaceCondition | yeah | 19:58 |
| RaceCondition | that's cool | 19:58 |
| jfroy|work | a heavy checkout is a full branch | 19:58 |
| RaceCondition | just that it has hooks to always commit to the bound branch, too | 19:59 |
| awilkins | I go for heavy under most circumstances where the bound branch is across a network | 19:59 |
| jfroy|work | With the convenience that a commit to it will automatically mean a commit to the parent, bound branch. | 19:59 |
| awilkins | On the grounds that the server may fail and it also provides distributed backup | 19:59 |
| jfroy|work | You can, in fact, unbind a heavy checkout, and it will be a regular, plain old branch. | 19:59 |
| awilkins | Or occasionally "bzr commit --local" when you are offline | 19:59 |
| RaceCondition | and of course it's possible to mix the central and distributed approaches so one developer could be using a distributed approach and dumb-users such as designers and project managers could be using a central approach? | 19:59 |
| jfroy|work | Lightweight checkouts will *not* work without the parent branch | 20:00 |
| RaceCondition | within the same project | 20:00 |
| awilkins | RaceCondition: | 20:00 |
| awilkins | Yes | 20:00 |
| jfroy|work | In fact, I'm not sure lightweight checkouts are relevant anymore now that we have stacked branches | 20:00 |
| awilkins | I've not tried stacked branches | 20:00 |
| RaceCondition | what are stacked branches? | 20:00 |
| jfroy|work | RaceCondition: happiness :) | 20:00 |
| jfroy|work | Essentially, a stacked branch has a *partial* set of the parent branch's history. | 20:01 |
| RaceCondition | so stacked branches is the same thing as sex and alcohol and going to Hawaii? | 20:01 |
| awilkins | A branch where a lot of the history is a pointer that says "look here" | 20:01 |
| jfroy|work | It has the recent history, but requires access to the parent branch for anything older. | 20:01 |
| RaceCondition | yeah | 20:01 |
| jfroy|work | So it makes branching zippy. | 20:02 |
| awilkins | So you can have your cake and eat it - have a quick checkout over limited bandwidth and get hacking fast | 20:02 |
| jfroy|work | yep :) | 20:02 |
| jfroy|work | Hence, happiness. | 20:02 |
| awilkins | Can stacked branches move back their history horizon? (e.g. download older history if it becomes apparent they need it?) | 20:02 |
| RaceCondition | does Bazaar make it possible to selectively choose which changes to commit in a file in the working tree like darcs and git do? | 20:02 |
| jfroy|work | No idea | 20:02 |
| jfroy|work | asak|: | 20:02 |
| jfroy|work | ... | 20:02 |
| jfroy|work | awilkins: | 20:02 |
| jfroy|work | RaceCondition: you want to look at the looms plugin for that | 20:03 |
| jfroy|work | I believe | 20:03 |
| RaceCondition | so no built-in support? | 20:03 |
| awilkins | RaceCondition: Yes ; you can list the files manually at the command, or use qcommit or gcommit | 20:03 |
| LarstiQ | jfroy|work: hmm, I'm not sure how well they'd go with switch | 20:03 |
| jfroy|work | LarstiQ: good point | 20:03 |
| LarstiQ | RaceCondition: I'd use shelve for that | 20:03 |
| RaceCondition | awilkins: I often have changes in a single file that should be committed separately, in 2 or more commits | 20:03 |
| jfroy|work | Ah yes, shelve is good too | 20:03 |
| awilkins | RaceCondition: shelve | 20:03 |
| awilkins | Not tried looms | 20:04 |
| RaceCondition | awilkins: will check it out, thanks | 20:04 |
| jfroy|work | You can commit individual files, but if you want a specific change in a specific file, you'll have to use shelve or looms | 20:04 |
| jfroy|work | (or a set of specific changes) | 20:04 |
| LarstiQ | RaceCondition: or you could use the 'interactive' plugin, but I personally don't like that workflow | 20:04 |
| RaceCondition | I see | 20:04 |
| RaceCondition | git even has an option to interactively edit diffs that will be committed which I really like | 20:05 |
| awilkins | Yes, the "index" | 20:05 |
| RaceCondition | because sometimes even a single line contains changes of multiple potential commits | 20:05 |
| RaceCondition | no, not the index.. I can edit diffs that will go into the index | 20:06 |
| awilkins | That part of git really seems confusing to me (not having used it in anger) | 20:06 |
| Pieter | who is the bzr-fastimport maintainer? | 20:06 |
| RaceCondition | it's actually one of the less confusing parts of git :) | 20:06 |
| RaceCondition | the most confusing part of git is that I cannot push changes to remote repositories/branches and actually have those changes applied on the remote working tree | 20:07 |
| awilkins | It's counterintuitive to me.. I'm used to my VCS committing all my current changes by default, not having to be told which ones to commit | 20:07 |
| RaceCondition | (without manual hacking) | 20:07 |
| awilkins | RaceCondition: That's true of Bazaar too unless you run certain hooks | 20:07 |
| RaceCondition | damn | 20:08 |
| awilkins | RaceCondition: Well, across the smart network transports | 20:08 |
| evarlast | we run without a remote working tree, so when others pull/branch from the remote tree, they do get latest changes. | 20:08 |
| RaceCondition | how time consuming it is to set up those hooks? a single command? a script? | 20:08 |
| RaceCondition | since I'm normally developing alone, I need a way to "deploy" changes to remote installations | 20:09 |
| RaceCondition | without actually logging in remotely and doing a pull/update/merge | 20:09 |
| RaceCondition | btw what's the different between pull, update and merge? does update pull AND merge? | 20:09 |
| awilkins | Well... I'm not totally familiar. The one I know just uses SSH to make the remote box do a "bzr update" on the branch you just pushed | 20:09 |
| awilkins | pull pulls revisions and updates the tree if you have one. If your branches have diverged, pull instead tells you to merge | 20:11 |
| awilkins | You need a working tree to merge | 20:11 |
| jfroy|work | a pull is a merge + commit in one operation | 20:11 |
| RaceCondition | what is an update then? | 20:11 |
| awilkins | a "fast forward" in git terms | 20:11 |
| jfroy|work | A merge requires a working tree because it will modify a working tree, not commit for you. | 20:12 |
| awilkins | update updates your working tree to the latest revision (and pulls it if you are a heavy checkout) | 20:12 |
| awilkins | Pull also updates | 20:12 |
| awilkins | (if you have a tree) | 20:12 |
| jfroy|work | so does merge | 20:12 |
| RaceCondition | wtf | 20:12 |
| RaceCondition | this is confusing | 20:12 |
| jfroy|work | I'm not sure what the distinction between update and merge are | 20:12 |
| jfroy|work | :p | 20:12 |
| LarstiQ | RaceCondition: git doesn't care about ordering of parents, so it conflates pulling and merging | 20:12 |
| jfroy|work | Beyond that update will essentially be a merge from the parent branch (the one you are bound to), and merge can operate on any branch with (or without) a common ancestor. | 20:13 |
| awilkins | pull is a special case of merge where the pulling branch has no revisions that are not in the pulled branch | 20:13 |
| LarstiQ | RaceCondition: for your updating a remote tree, to me that seems like you are trying to do deployment, which I'd do with bzr-upload | 20:13 |
| LarstiQ | RaceCondition: but if you really do want a branch there, you could use the push-and-update plugin | 20:14 |
| jfroy|work | right | 20:14 |
| jfroy|work | The most correct understanding of "update" is that it updates a working tree. | 20:14 |
| RaceCondition | does bzr-upload basically do a selective upload to save bandwidth and not store revision information remotely? | 20:14 |
| LarstiQ | right, brings it up to date with the branch | 20:14 |
| LarstiQ | RaceCondition: yes | 20:14 |
| RaceCondition | does update ever pull stuff from another branch/repository? | 20:15 |
| LarstiQ | RaceCondition: no/yes | 20:15 |
| awilkins | update pulls revisions to a heavy checkout | 20:15 |
| jfroy|work | When you have a bound branch however (e.g. the result of a heavy checkout), update will do a merge with the parent branch as well. | 20:15 |
| LarstiQ | RaceCondition: the case where that happens is if you are using a checkout, when it needs to sync the local branch to the master branch | 20:15 |
| jfroy|work | Or a pull, I should say. | 20:15 |
| RaceCondition | but if I have a regular branch not a checkout? what does update do then? | 20:15 |
| awilkins | Updates to the most recent LOCAL revision | 20:16 |
| LarstiQ | RaceCondition: make sure the working tree files are the same as the tip of the branch | 20:16 |
| jfroy|work | Updates the *working tree* to the branch's most recent revision. | 20:16 |
| RaceCondition | I thought revert makes sure the working tree files are the same as the tip :P | 20:16 |
| LarstiQ | RaceCondition: say, when you bzr push remotely, the working tree will not be updated, you could do that with a `bzr update` remotely (which is what push-and-update does) | 20:16 |
| LarstiQ | RaceCondition: right, I should be more precise | 20:16 |
| awilkins | RaceCondition: You're right ; update does NOT do this esp if you reverted to an older revision | 20:17 |
| LarstiQ | RaceCondition: update will merge local changes, revert will not | 20:17 |
| LarstiQ | (local uncommitted changes, to be precise) | 20:17 |
| jfroy|work | right, revert will clobber the working tree with what | 20:17 |
| jfroy|work | *with what's in the branch | 20:17 |
| RaceCondition | in which situations I might have newer revisions locally that are not applied to the working directory files yet? | 20:17 |
| LarstiQ | RaceCondition: no? | 20:17 |
| LarstiQ | oh, yes | 20:18 |
| LarstiQ | RaceCondition: is that a question or a statement? | 20:18 |
| RaceCondition | question | 20:18 |
| jfroy|work | I'm confused too :p | 20:18 |
| awilkins | RaceCondition: If you are in a working tree that was pushed to using a smart protocol but has not been updated | 20:18 |
| LarstiQ | RaceCondition: ok, which situation do you mean then? | 20:18 |
| RaceCondition | awilkins' answer satisfied me :P | 20:18 |
| LarstiQ | good :) | 20:18 |
| jfroy|work | Ah, awilkins is exactly right | 20:18 |
| awilkins | RaceCondition: Most of these cases, you receive a warning when pushing | 20:18 |
| jfroy|work | Say developer B pushed to developer A's shared branch. | 20:19 |
| LarstiQ | RaceCondition: the main reason not to update working trees remotely is that you can't detect conflicts without being horribly wasteful to bandwidth | 20:19 |
| RaceCondition | is pull the exact reverse/opposite of push? I mean, to push from A to B is to pull to B from A? are the effects on B the same? | 20:19 |
| jfroy|work | Developer A will have to "bzr update" before he sees developer B's changes in his working tree. | 20:19 |
| LarstiQ | RaceCondition: almost, yes | 20:20 |
| LarstiQ | jfroy|work: right, imo it's a horrible idea to do that to someone :) | 20:20 |
| awilkins | RaceCondition: pull always updates working trees because it assumes they are local | 20:20 |
| RaceCondition | what about merge? does merge touch the working tree? | 20:20 |
| LarstiQ | RaceCondition: yes, it often needs to | 20:20 |
| jfroy|work | merge *only* touches the working tree | 20:21 |
| jfroy|work | it doesn't actually commit | 20:21 |
| awilkins | RaceCondition: merge touches the working tree as much as the revisions you are merging | 20:21 |
| jfroy|work | although a branch does keep track of pending merges | 20:21 |
| awilkins | And leaves a merge state pending | 20:21 |
| LarstiQ | RaceCondition: what jfroy|work said is important, it doesn't commit | 20:21 |
| RaceCondition | but is there a command that gets patches from branch A to branch B but doesn't touch the working tree just like push? | 20:21 |
| jfroy|work | pull probably as a flag for not updating the working tree | 20:21 |
| RaceCondition | I see | 20:22 |
| jfroy|work | flag -> option | 20:22 |
| RaceCondition | so running pull with that flag + update = regular pull? | 20:22 |
| jfroy|work | yes | 20:22 |
| awilkins | I don't think pull does have that flag | 20:22 |
| jfroy|work | actually, damn, no such option | 20:22 |
| jfroy|work | :| | 20:22 |
| RaceCondition | doesn't matter, I'm just trying to get a picture :P | 20:22 |
| awilkins | You can pull and then revert back to the tip revision you pulled on top of though :-) | 20:23 |
| RaceCondition | it's like complex numbers -- the imaginary part really doesnt exist like that pull flag but it makes the equation simpler :) | 20:23 |
| LarstiQ | RaceCondition: pull does make a working tree | 20:23 |
| LarstiQ | RaceCondition: so if your branch doesn't have one, it doesn't update it | 20:23 |
| LarstiQ | argh | 20:23 |
| LarstiQ | pull does _not_ make a working tree | 20:23 |
| awilkins | Yes, a no-tree branch doesn't have a working tree to write to :-) | 20:23 |
| RaceCondition | make? you mean touch the working tree? | 20:24 |
| RaceCondition | oh | 20:24 |
| LarstiQ | RaceCondition: hmm, I believe there used to be a `fetch` command that did just the revision pulling logic | 20:24 |
| awilkins | But if you pull to an empty branch (zero revisions) you will get the working tree also | 20:24 |
| RaceCondition | I wish there was a set of underlying elementary commands that made up all user level commands that the user level commands could be explained with/expanded to :P | 20:24 |
| RaceCondition | LarstiQ: exactly! fetch was what I was thinking of | 20:24 |
| LarstiQ | RaceCondition: well, a lot of that understanding you get from understanding the 3 main domain concepts | 20:25 |
| LarstiQ | RaceCondition: being, Branch, WorkingTree, Repository | 20:25 |
| * awilkins wonders if Bazaar supports hardlinks on NTFS6 | 20:25 | |
| jfroy|work | Would the fetch-ghosts in bzrtools do what RaceCondition is talking about? I'm not sure what "ghosts" are? | 20:26 |
| LarstiQ | RaceCondition: you can have all 3 in the same location, or just one of them, or any two | 20:26 |
| LarstiQ | jfroy|work: no | 20:26 |
| jfroy|work | Good to know :) | 20:26 |
| awilkins | jfroy|work: "ghosts" are revisions that do not exist within a branch | 20:26 |
| jfroy|work | Ah | 20:26 |
| LarstiQ | jfroy|work: ghosts are references to revisions where you don't have the actual revision object | 20:26 |
| awilkins | Oops | 20:26 |
| LarstiQ | but you do know the position in the revision dag | 20:27 |
| awilkins | I was thinking of something else | 20:27 |
| LarstiQ | jfroy|work: if stacked branches didn't point somewhere else to get older history, you'd have a branch with tons of ghosts | 20:27 |
| awilkins | Maybe we should have a feature based on that for Halloween | 20:28 |
| awilkins | Something that goes "WOO!" every time it encounters a ghost, but only on October 31st :-P | 20:29 |
| LarstiQ | jfroy|work: Arch branches used to be similar to stacked branches, except they always pointed somewhere else | 20:30 |
| LarstiQ | jfroy|work: so that introduced lots of ghosts when the pointees would disappear | 20:30 |
| === visik7 is now known as Guest97541 | ||
| === visi_ is now known as visik7 | ||
| unenough | what are the highlights of the major changes since version 1.0? i've blinked and we're at 1.8 already | 20:56 |
| * LarstiQ looks at NEWS | 21:00 | |
| jfroy|work | sky is now green, grass blue, and let's not even mention the oceans | 21:00 |
| jfroy|work | Or look at NEWS :p | 21:00 |
| awilkins | Lots of features, lots of speed. | 21:00 |
| LarstiQ | unenough: stacked branches is a major one | 21:00 |
| unenough | if NEWS is what i think you're referring to: error, too much information | 21:00 |
| jfroy|work | Speed has seen huge progress as well | 21:00 |
| jfroy|work | Like, probably an order of magnitude since the early days | 21:01 |
| awilkins | In short No Reason Not To Upgrade (tm) | 21:01 |
| awilkins | I've been using since 0.9 and never regretted an upgrade (even to random revisions in bzr.dev) | 21:02 |
| LarstiQ | unenough: I don't hold the diff in my head, so I'm looking at NEWS too | 21:02 |
| unenough | ok | 21:02 |
| unenough | :) | 21:02 |
| LarstiQ | unenough: an easier question would be if you had specific things in mind | 21:02 |
| awilkins | Bazaar is a real poster-boy for test driven development | 21:02 |
| jfroy|work | And that is why It Is Awesome™ | 21:03 |
| unenough | svn has a "feature" that merges are automatic if there is no "conflict" (which are defined as changes on a single line of text) - can anyone explain what can possibly justify such a destructive "feature"? | 21:03 |
| unenough | or am I missing something | 21:03 |
| awilkins | I still think you need to commit a merge from SVN after you've done it | 21:04 |
| unenough | that's right | 21:05 |
| unenough | and yet, what's the sense | 21:05 |
| awilkins | Because you should review it to make sure it didn't destroy the universe? | 21:05 |
| LarstiQ | unenough: what does "automatic" mean in this context? | 21:06 |
| unenough | it means that if svn's diff algorithm decides that two changes are non conflicting, then it merges them (if two changes are in two different lines, it puts in the new versions of both lines) | 21:07 |
| lifeless | unenough: generally I don't try to justify things bzr doesn't do :P | 21:07 |
| unenough | lifeless, I would gladly use bzr, but i need this for a company that's currently using VSS and the replacement must have Visual studio integration | 21:08 |
| unenough | and svn has AnkhSVN | 21:08 |
| unenough | and bzr doesn't have it | 21:08 |
| unenough | EOF | 21:08 |
| awilkins | Hmm, "must have VS integration" sounds like a management-generated requirement | 21:08 |
| unenough | awilkins, they are working with VS. that's what they are paying me for..to find an alternative to VSS | 21:09 |
| awilkins | And merging two seperate single line changes without conflict is pretty universally normal.... | 21:09 |
| awilkins | Is this VSS 6 they are using? | 21:09 |
| unenough | i think so | 21:10 |
| awilkins | Godawful piece of trash | 21:10 |
| LarstiQ | unenough: welll | 21:10 |
| unenough | awilkins no it isn't normal. what if line 1 was changed to ptr = NULL and line 2 was changed to *ptr = 1? | 21:10 |
| LarstiQ | unenough: depending on how much work you want to do, you could continue the VS integration work that currently exists | 21:11 |
| unenough | LarstiQ not that much :) | 21:11 |
| evarlast | VS integration is pretty damn important. | 21:11 |
| evarlast | especially when you figure in things like refactoring tools. | 21:11 |
| awilkins | unenough: Adjacent lines are usually thought of as conflicts | 21:11 |
| awilkins | unenough: I thought you meant line 1 and line 100 | 21:11 |
| evarlast | you rename a class, it renames the file for you, these changes need to be done properly in source control | 21:11 |
| unenough | awilkins, ok, you can put a ton of lines in the middle, but the logical meaning could be the same | 21:11 |
| evarlast | you can do it manually, but it is painful. | 21:12 |
| LarstiQ | unenough, evarlast: https://edge.launchpad.net/bzr-visualstudio | 21:12 |
| unenough | LarstiQ seen that, it looks premature | 21:12 |
| LarstiQ | unenough: it's not as mature as svn integration, no | 21:12 |
| awilkins | unenough: Which is why it doesn't commit it off the bat - you should test it and review it before you commit (or at least have a staging branch where you do that) | 21:12 |
| LarstiQ | unenough: so it needs someone to work on it :) | 21:12 |
| unenough | awilkins what it really should do is tell you "you can't update this unless you perform a merge, OR if you want, merge automatically now and review later" | 21:14 |
| unenough | isntead, it FORCES you to merge automatically | 21:14 |
| awilkins | unenough: Oh, when you update files that you've edited. | 21:14 |
| unenough | yes | 21:15 |
| unenough | it "succeeds" in the update, btu actually kills all your files that need merges | 21:15 |
| lifeless | this is getting quite offtopic | 21:16 |
| unenough | ok, so what does bzr do in this case? | 21:16 |
| lifeless | bzr merge will not merge without --force if you have uncommitted changes; | 21:17 |
| unenough | that's more like it | 21:17 |
| LarstiQ | but pull and update will merge file contents of uncommitted changes | 21:17 |
| lifeless | merges are between a revision and a working tree, if your branch is out of date the un-updated changes are not brought in by merging an unrelated other branch | 21:17 |
| lifeless | LarstiQ: right, but those commands are defined that way; update isn't merging a different line of work, and pull is maintaining a local mirror-with-edits | 21:18 |
| LarstiQ | lifeless: yes, I'm just not certain unenough means bzr merge when he says merge | 21:19 |
| lifeless | there is an argument for wanting --force on those cases, but I think it would be an unbreakme option | 21:19 |
| unenough | LarstiQ, i'm looking into converting ankhsvn to ankhbzr ... if it's nto hard, i'll do it :) | 21:41 |
| jelmer | unenough, there's already a visual studio plugin for bzr | 22:02 |
| jelmer | never mind, I missed the earlier discussion | 22:02 |
| jfroy|work | jelmer: good [morning, afternoon, evening, night] | 22:04 |
| jelmer | jfroy|work, hi | 22:04 |
| RaceCondition | I've branched and easy_install'ed the bzr-upload plugin, but how do I use it? | 22:42 |
| RaceCondition | bzr-upload nor bzr upload seem to work | 22:42 |
| beuno | RaceCondition, it's: bzr upload | 22:43 |
| beuno | run: bzr plugins | 22:43 |
| RaceCondition | doesn't show bzr-upload | 22:43 |
| beuno | and see if it installed properly | 22:43 |
| beuno | right, then it didn't install properly | 22:43 |
| RaceCondition | how to install it properly? | 22:44 |
| RaceCondition | aha, easy_install was incorrect, python setup.py install was needed instead | 22:44 |
| RaceCondition | wonder why, though | 22:44 |
| lifeless | easy_install doesn't meet the standard behaviour for python modules and packages | 22:46 |
| lifeless | you have to do special stuff to make it work and noone has contributed that stuff to bzr's plugin logic | 22:47 |
| lifeless | its pretty crufty anyway, I'm not entirely sure it would be a win to add it :) | 22:47 |
| beuno | and, bzr-upload is in Ubuntu and Debian now! | 22:47 |
| beuno | intrepid and unstable, but it's there | 22:47 |
| RaceCondition | what does the ftp:// URL have to be like? | 22:48 |
| RaceCondition | I'm getting bzr: ERROR: No such file: '/path/my/to/dir/': 550 Can't create directory: No such file or directory | 22:48 |
| RaceCondition | for totally valid paths | 22:48 |
| beuno | RaceCondition, what's the exact command? | 22:48 |
| RaceCondition | ah, relative to the home directory | 22:49 |
| RaceCondition | nevermind :) | 22:49 |
| RaceCondition | anyway, this bzr-upload thing really rocks | 22:53 |
| RaceCondition | I think I'm switching over from git right away :P | 22:53 |
| beuno | RaceCondition, good to hear | 22:54 |
| unenough | what does bzr upload do? | 22:54 |
| RaceCondition | unenough: push changes over dumb-transports such as FTP | 22:54 |
| unenough | hmm so you can use any dumb server for bzr? | 22:54 |
| beuno | unenough, you can use a dumb server without the plugin | 22:55 |
| beuno | this just uploads your working tree | 22:55 |
| beuno | for websites and such | 22:55 |
| RaceCondition | I love that I don't have to do a full upload | 22:56 |
| RaceCondition | I wonder if I could bind a branch to a specific FTP location so I wouldn't have to enter a remote location every time I use bzr-upload | 22:56 |
| beuno | RaceCondition, and it all came out of a nice dinner and a few beers :) | 22:56 |
| RaceCondition | beuno: bzr-upload? | 22:56 |
| beuno | RaceCondition, yeah | 22:56 |
| RaceCondition | so this means I will want beer whenever I use bzr-upload | 22:57 |
| * RaceCondition wants beer | 22:57 | |
| * beuno invests in beer stocks | 22:57 | |
| RaceCondition | I also want a nice dinner | 22:57 |
| * RaceCondition invests in nice dinner stocks | 22:57 | |
| RaceCondition | now how can I migrate from git to bazaar -- is there a tool for that? :) | 22:58 |
| beuno | RaceCondition, take a look at fastimport | 22:59 |
| beuno | not sure how advance it is with git | 22:59 |
| beuno | maybe lifeless knows | 22:59 |
| RaceCondition | OK | 22:59 |
| lifeless | yes, its git-fast-export | bzr fast-import | 23:05 |
| lifeless | (roughly) | 23:05 |
| lifeless | details are on the wiki I believe | 23:05 |
| jam | lifeless: I tried calling via skype, didn't get through | 23:14 |
| jam | There is a patch for your review which retries at the CombinedGraphIndex layer | 23:15 |
| jam | if you are interested | 23:15 |
| jam | I'm still looking at retrying for data access | 23:15 |
| jam | it gets pretty convoluted. ATM I'm thinking we'll have to do a pretty large retry | 23:15 |
| lifeless | jam: what drives the convolution? | 23:16 |
| jam | lifeless: NoSuchFile exceptions while iterating over "self._indices" | 23:16 |
| lifeless | jam: I was thinking it would just redo the whole operation (minus already returned items) | 23:16 |
| jam | lifeless: right | 23:16 |
| jam | the data reads are a bit harder to find the right point to retry | 23:16 |
| jam | because we end up re-reading the index a few times | 23:16 |
| jam | and we use a lot of helper functions, etc | 23:16 |
| jam | I think I can do it, I just need to tweeze apart the state-that-needs-to-be-preserved from the state-that-gets-refreshed | 23:17 |
| lifeless | CGI is a bad abbreviation :P | 23:17 |
| jam | True :) | 23:18 |
| jam | so is GI | 23:18 |
| jam | oh wait, it was GC | 23:18 |
| l3dx | isn't it possible to use tortoiseBzr if tortoiseSVN is already installed? My context menu only contains svn | 23:20 |
| jam | l3dx: it should be fine, though I've heard of problems with TBZR and 64-bit windows in case that is relevant | 23:21 |
| markh | where "problems" == "doesn't work at all" :) | 23:22 |
| l3dx | 32-bit here | 23:23 |
| markh | l3dx: is a bzr taskbar icon created? | 23:23 |
| markh | and are you checkin on a local disk (ie, not a network or removable disk)? | 23:23 |
| markh | checking (ie, testing) | 23:24 |
| l3dx | no taskbar icon, and it's a local env | 23:24 |
| markh | I'm not sure what could be going wrong, but the tortoise readme has some info for collecting diagnostic information. | 23:25 |
| lifeless | jam: I'm not in front of the skype machine; if you want voice let me know I'll switch rooms | 23:25 |
| jam | lifeless: nah, I just skyped for the standup, I'm done for now | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!