ricosecadaHi. I am just in the process of migrating from cvs to bzr. I have a debian server just running sshd. On cvs I normally just specify a CVSROOT variable which points to the server, and after doing an init on the server it is set up. I can't seem to figure out, if its possible to run bzr the same kindda way?00:23
fullermdWell, there's no CVSROOT equivalent; the concept doesn't map.  But you get a CVS-like workflow using checkouts.00:31
fullermdYou just have to specify the full remote URL when you do the checkout.00:33
ricosecadafullermd, do I have to specify the url when I do commits as well then?00:35
Odd_Blokericosecada: No, your branch will remember where it is checked-out from.00:36
fullermdNo, any more than you need to specify the module or have $CVSROOT set when you do a CVS commit.00:36
ricosecadasince the server is running ssh, what would the complete command look like?00:37
ricosecadawith the url00:37
fullermdbzr+ssh://server/path/on/server/   (or sftp:// if you can't get bzr running on the server)00:37
ricosecadaaah :-)00:38
lifelesse.g. bzr checkout bzr+ssh://server/path/on/server/00:38
fullermdHm.  That reminds me; we have a bug open for "No ~ on bzr+ssh", right?00:38
fullermdThat's one of the sort of things I'd put on the "rough edges that 1.0 shouldn't like" list.00:39
fullermdLittle and rather piddly stuff, but it makes you frown.00:40
ricosecadado I need to specify the BZR_REMOTE_PATH anywhere?00:42
lifelessonly if bzr is not in the usual place00:42
tandersonSo if I want to start a new project using bzr I can store my project in a location accessible via my webserver to allow anyone to do a checkout via bzr http://... right?00:44
lifelessthough anonymous users will usually use bzr branch00:45
tandersonI see00:46
ricosecadaare there any specific packages needed to use bzr with ssh?00:49
lifelessricosecada: install the recommends:00:49
ricosecadalifeless, I did. I can do a checkout from the ssh server fine now, but when I try to commit I get this bzr: ERROR: exceptions.AssertionError: end of file reading from server00:49
tandersonAnd if a developer wanted to work on this project and did an initial checkout/branch via bzr http://....  I would need to install the webdav plugin to allow them to commit back to http:// right?00:50
ricosecadalooks like a bug00:56
lifelessricosecada: hmm, there are some bugs open00:57
lifelessricosecada: its likely the permissions error bug, we mis-represent a permissions error sometimes00:57
ricosecadaand I was just beginning to enjoy this :-)00:57
lifelessricosecada: you could try sftp:// with the same url; it might give a better diagnostics00:57
ricosecadaI'll try that00:58
ricosecadalifeless, it works fine with sftp00:59
ricosecadano errors00:59
fullermdWhat version do you have on the client and server sides?00:59
ricosecadaon the client 0.91.0 on the server 0.11.001:00
ricosecadaI am running debian testing on the client and stable on the server01:01
ricosecadabut its ok when its working with sftp01:01
fullermdI think 0.11 supported bzr+ssh (though it was brand new then).  But it didn't support dirstate-tags branches, which I guess you have.01:01
fullermdsftp doesn't use bzr on the server side at all.01:02
abentleyricosecada: For bzr+ssh compatibility, I'd recommend something much more recent.  That support has been evolving rapidly lately.01:02
ricosecadaI will perhaps upgrade the bzr packages on the server01:03
ricosecadaone more question, I have been searching for the variables like $author$ and $id$ to insert in the files. would someone mind pointing me in the direction to doc on that?01:04
fullermdThat's filed under "keyword expansion".  Support doesn't exist yet.01:04
ricosecadaI upgraded bzr on the server - no bugs now01:16
lifelessricosecada: fullermd failed to mention 'bzr version-info --help'01:25
lifelessricosecada: this is in many ways technically superior - its simpler, works with binaries as well as sources, etc.01:26
ricosecadaI am running 0.91 on both server and client now01:26
ricosecadaI do miss the keyword expansion though01:26
fullermdHm.  That reminds me, I should rewrite some scripts to use revision-info01:26
lifelessricosecada: we have no moral objection to it, and will eventually do it for folk that want the bad ol' days :)01:27
* fullermd is one who wants the bad ol' days ;)01:27
fullermdWAG'ing from the current active lists, I'd be surprised if we saw it before next summer at the earliest.01:28
fullermdProbably farther out than that.01:28
lifelessabentley: I find working with [NULL_REVISION] rather than [], to be quite annoying. As we have None to represent 'not here', all it really means is that [] is *never* used01:28
abentleylifeless: Well, in theory it would be used for get_parents(NULL_REVISION)01:30
lifelessabentley: I'm not saying NULL_REVISION shouldn't exist. just that having end-of-graph be coerced to it is extra typing and logic01:30
lifelessI appreciate NULL_REVISION having to exist to differentiate unpassed parameters (None), and NULL_REVISION itself.01:31
lifelessanyhow, I may be wrong, there may be some point where it turns out to be useful, so I'm using it.01:31
jelmerabentley: btw, any particular reason Repository.get_parents() uses self.get_revision(x).parent_ids rather self.revision_parents() ?01:32
jelmermy guess would be that revision_parents() is intended to be deprecated, but it's not marked as such (yet)01:32
lifelessjelmer: I think you'll find knit and pack repos have a different get_parents, and also see Repository.get_graph.01:34
abentleylifeless: Well, I was thinking two things: 1. the graph is more accurate with NULL_REVISION in it.  2. I've seen what a pain it is when we don't use NULL_REVISION enough, so let's try erring on the other side.01:34
jelmerlifeless: Still, it would be nice to have a fast default implementation01:35
lifelessjelmer: for jbof repositories, get_revision.parent_ids is fast01:35
lifelessjelmer: there really is no well defined 'fast' :)01:35
jelmerlifeless, revision_parents() will always be faster I imagine, as it is more specific01:35
jelmersince the information it returns is a subset of the information returned by get_revision()01:36
jelmer*faster or same speed01:36
lifelesssure I guess01:36
lifelessjust saying, check around a bit01:36
lifelessif you come to a conclusion, send a patch01:36
jelmersure, will do01:37
abentleyjelmer: frankly, I don't remember.  I may have been thinking that for weave repos, the implementation just needed to be correct, not fast.01:38
lifelessabentley: if so, revision_parents has the same constraint though; also weaverepo.py can handle that. (Not critiquing, just noting)01:39
abentleyOh, what about ghosts?  Weaves don't record ghost parents.01:45
lifelessa weave will return [NULL_REVISION] when it shouldn't01:53
abentleySounds like a bug.  Do you know where it is?01:54
lifelessmy point is that weaves can't tell [] from [NULL_REVISION]01:55
lifelessso they can't choose to return [] instead of [ghost], so any mapping will just preserve the defect01:55
lifelessyou have to go out to the real data to tell; and if you do that you can return [ghost] correctly anyway01:56
abentleyAre we talking about jelmer's thing or your thing?02:02
lifelessmy thing02:04
lifelesssorry for adduing confusion02:04
abentleyThe implementation of get_parents for weaves does hit the real data.02:05
Pengbzr.dev reconcile took 356 minutes wall-clock time, 305m user time and 44m sys time.02:05
lifelessPeng: yah02:06
lifelessPeng: newer one is nearly done02:06
lifelessI have _generate_text_key_index written02:06
lifelessjust need to hook in the LRU cache02:07
lifelessdamn its not too shabby02:09
lifeless2K/36K done02:09
lifeless-no cache-02:09
lifelessok, I'm out for the day. damn 4am starts :)02:10
lifelessI'll send this in for review but not merge.02:10
lifeless80M memory usage02:10
Pengvs. 7 GB?02:11
PengOr whatever it was?02:11
lifelessthis is bzr.dev02:11
lifelessso you were seeing how much yesterday?02:11
PengDidn't you mention that it used like 7 GB of virtual RAM?02:17
lifelessthat was launchpad02:17
lifelessI'm testing that now02:17
lifelessit's using 88M02:17
PengOoh, bzr check is almost done.02:17
PengThere are MORE inconsistent parents since running reconcile.02:18
lifelessokies, I'm happy with this.02:18
PengWell, I made another commit, so that's probably that.02:18
lifelessPeng: using what bzr version ?02:18
lifelessthats bizaare02:18
lifelessbzr.dev won't create inconsistent parents02:18
PengHee, 19,996 unique file texts.02:18
PengWell, the increase is probably because I made another commit.02:19
PengBut reconcile definitely didn't help.02:19
lifelessnot if you committed using bzr.dev02:19
PengOh, I didn't commit using bzr.dev.02:20
PengI only used bzr.dev for reconcile and check.02:21
PengWasn't bzr.dev's check supposed to fix this?02:22
lifelessdo you mean reconcile?02:22
lifelessand I thought you converted to packs. ...02:22
PengI still had the knit version around.02:23
PengSo I ran reconcile on it.02:23
PengAnd it didn't help.02:26
lifelesswell bzr.dev reconcile is meant to correct mismatched texts, but IIRC it keeps unreferenced and unused texts around just in case.02:26
PengI can successfully push, so I should just keep all of the messed up parent stuff?02:28
lifelesswith packs? I'd keep a backup of the knit repo just-in-case. Until I can have you run a native reconcile I'm just a tad cautious is all.02:29
PengI'm planning to keep a backup of the knits.02:29
PengThis is making my head hurt.02:33
lifelessignore it02:35
lifelessuse the packs02:35
lifelessenjoy the packs02:35
lifelessand don't delete the knit copy for now:)02:35
Peng"Don't worry about the errors. Have fun. But don't delete your backup." I'm so confident. :P02:36
lifelessthey are a trivial defect 99.99% of the time02:37
lifelessthe only place we *know* to be affected by the non-trivial case is bzr.dev, from the bad ole weave days02:38
lifelessanother day or so and a clean pack reconcile should be available02:38
lifelessand I'll get you to run that02:38
PengOkie-dokie. :)02:38
* igc lunch02:43
abentleyAm I correctly understanding that we have no general way of fetching between repositories whose serializers differ?02:47
lifelessnone hooked up commitbuilder is probably the closest thing02:48
lifelessthat was one of its intents02:48
abentleyHmm.  Bundles can do it, though.02:55
abentleyI'm having trouble parsing "none hooked up commitbuilder"02:55
lifelessi ,but02:56
abentleyI beg your pardon?03:01
lifelessnone hooked up, but commitbuilder is probably the closest thing03:03
lifelessi starts insert mode in vim ;)03:03
abentleyI would think it's cheaper to deserialize and reserialize than to run through CommitBuilder.  But I guess CommitBuilder handles the case where more than the serializer differs.03:16
lifelessright;  AFAIK we have no cases where the serializer is the only difference03:26
ricosecadaHi. How does bzr handle binary files?04:16
AfCricosecada: uh, correctly?04:17
ricosecadaAfc, and how is that?04:17
fullermdI was gonna say "with heavy leather gloves and 4 foot tongs"...04:21
PengWow. The local repo that I converted to packs is a 225 MB .pack file. But when pushing it, it's a bit less than 200 MB. That's a lot of space wasted by revisions I had uncommitted.04:44
AfCWhoa. `bzr viz` in bzr-gtk 0.92.1 is _really_ sexy04:54
ricosecadaDoes bzr allow one to checkout a single directory with a repos?04:58
PengI don't think any of the DVCSes do. It would be a little tricky.05:00
ricosecadaSome of them does: http://better-scm.berlios.de/comparison/comparison.html#work_on_dir05:03
* Peng has fun deleting gigabytes of data.05:12
lifelessricosecada missed that all of those that said yes, were not (D)VCS05:30
lifelessPeng: ?05:30
PengI had a bunch of copies of everything from when I converted from bzr to hg. I just deleted most of them.05:39
PengWell, anyway, the pack version of that other repository is working fine, not that I've done much of anything with it.05:45
PengOne commit.05:45
fullermdWell, when I was a kid, my parents told me that if I could keep the bike balanced all the way to the mailbox, I could keep it balanced for any distance.05:54
fullermdSo by that logic, if it worked for one commit, it'll never fail   :]05:54
PengAck. Duh, compressing a tar of compressed stuff doesn't help much...05:59
PengWell, it saved 4 MB.06:00
PengOut of 1.2 GB.06:00
fullermdNot bad.  I've got a whole hard drive that would save...06:01
PengWait, way more than that.06:01
Peng60 MB.06:02
PengAnyway, unless p7zip can extract things *really* fast, that's not really worth it.06:03
PengAt least I can save a bunch of inodes.06:03
abentleyjelmer: initial version of a rich-root repo format is here: http://code.aaronbentley.com/bzr/bzrrepo/rich-root06:18
quicksilverabentley: thanks. We're playing with it.06:53
quicksilverabentley: certain amount of yak shaving was involved in getting the rights versions of python and stuff, but that's computers for you.06:54
PengHey, I just pulled ~30 new changesets from bzr.dev and it only took like 10 seconds. How did that happen?07:03
lifelessno idea07:04
fullermdI'd guess you already had most of 'em.07:06
fullermdActually, with that timing, near all..07:06
PengOhh. You're right.07:06
PengAll of them were already in the repo because I had just pulled another branch.07:07
ig1night all08:03
mwhudsoncan someone here explain what's required of a progress bar?11:15
KinnisonIdeally, indicate what's going on, progress evenly and monotonically giving a good indication of the amount of time consumed/remaining rather than number of tasks11:16
mwhudsonah, i was imprecise11:17
mwhudsoni meant expected from a bzrlib point of view11:17
mwhudsoni need to provide an alternative implementation, and wonder what methods i need to provide11:18
Odd_Blokemwhudson: Checkout bzrlib.progress11:18
Odd_Bloke*Check out11:18
Odd_BlokeIt has a base class and a number of implementations.11:19
mwhudsoni guess i can just inherit from DummyProgress and override everything11:20
=== cprov-away is now known as cprov
=== RichardL is now known as rml
=== AnMaster_ is now known as AnMaster
mwhudsongar, raising exceptions that hide other exceptions is pretty rude12:56
=== fo1 is now known as fog
howarils -la14:23
jam-laptop .14:44
jam-laptophowari: any other files?14:45
=== mwhudson_ is now known as mwhudson
=== cprov is now known as cprov-lunch
=== jam-laptop is now known as jam
jelmerabentley: Cool, I'll have a look15:16
sbalneavHello.  I'm using bzr, and all of a sudden, I'm getting an error trying to do a commit.  Is there a pastebin for this channel?15:17
ubotupastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)15:17
sbalneavSeems to be complaining that the branch is read-only.15:19
sbalneavPermissions are fine.  However, it's on an NFS mounted home dir.  Might that be the problem?15:20
jelmersbalneav: you appear to be committing over http - is that intentional?15:20
jelmerit doesn't know how to send commits to the master branch using http15:20
sbalneavah, wait.15:21
sbalneavmaybe I did a bzr checkout instead of a branch?15:21
sbalneavMight that be it?15:21
jelmerThat would explain it15:21
* sbalneav facepalms15:22
jelmeryou can unbind from the master branch using "bzr unbind"15:22
jelmerhey Szilveszter15:22
phanatichey jelmer15:22
sbalneavok, then just push back later with bzr push sftp://?15:22
jelmeror bind to that branch using "bzr bind sftp://" and it will automatically push when you commit15:23
sbalneavah, even better.15:23
sbalneavone of these days my bzr-fu will get to the point where I'm not so helpless :)15:23
jelmersbalneav: well, I admit the error you got when committing to the checkout wasn't very helpful15:24
sbalneavNah, makes sense now that I look at it.  I was simply panicky after doing 1/2 hour of work :)15:25
sbalneavDidn't know about the bind tho'.  That's a nice tip.15:26
jamjelmer, sbalneav: that error has been improved in 0.91 or 0.92 to not give the ugly traceback15:33
jelmerjam: ah, nice15:33
jamnow you get a single line error:15:34
jambzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ebzr/bzr-cvsps-import/trunk/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()15:34
jamIt isn't perfect, but it does make it a lot more obvious15:35
=== fredp is now known as fredp-afk
=== fredp-afk is now known as fredp
=== fredp is now known as fredp-afk
=== fredp-afk is now known as fredp
=== fredp is now known as fredp-afk
sbalneavYeah, working fine now after the bind.15:50
sbalneavjelmer, jam, thanks muchly.15:50
jamhappy to help15:50
=== fredp-afk is now known as fredp
=== fredp is now known as fredp-afk
neliusis it possible to push a branch to a samba share?16:53
neliuson a local fs it works, but on a samba share i get : bzr: ERROR: [Errno 5] Input/output error16:53
jelmernelius: Sure, if you've mounted that share locally16:53
beunonelius, absolutely, it's the same as pushing locally16:53
jelmernelius: How have you mounted the share, and what is the server running?16:54
neliusmy client is osx, i mounted is as smb:// from finder16:55
neliusthe server runs samba 3 on sun os 916:55
jelmerI'm not sure how much of the POSIX extensions are implemented in OS X's smb implementation at this point16:56
jelmernelius, Can you run with BZR_PDB=1 set and see what function is failing?16:57
=== sii` is now known as sii
neliusjelmer: please advice, how do i set BZR_PDB=1?16:58
jelmerit's an environment variable16:59
neliusjelmer: btw this mornig i mailed that bzr selftest fails from macport16:59
=== fredp-afk is now known as fredp
neliusjelmer: http://paste.uni.cc/1759817:12
jelmernelius: hmm, odd17:12
jamI would rather just see the output from ~/.bzr.log17:13
jamrather than BZR_PDB=117:13
jamI think jelmer was actually  wanting "bzr -Derror ..."17:13
jamwhich prints the traceback to the screen17:13
jamBZR_PDB=1 puts you into the debugger to interactively figure out what is going on17:14
jelmeryeah, ~/.bzr.log would've worked too17:14
jelmerthough this helps us somewhat too17:14
* jelmer first thought would still be to blame Mac OS X's smb implementation17:14
jamWell, it tells us that writing to a file descriptor is failing for some reason17:15
jamWhich does sound like a problem with smb://17:15
jelmerit would be interesting to see if this also breaks with a Linux client17:15
neliusif i try again and again, in some cases bzr enters the "Fetch phase 0/4" but in most cases it breaks just after i hit enter17:16
neliusi'll paste the .bzr.log after the current try failed17:16
jamweird, it seems capable of copying the file texts up, but when we try to start pushing revisions17:22
jamit fails at the signature file17:22
jamyou know what, though, we are probably creating the file with 0 bytes of data17:23
jamSo that the file exists, but doesn't hold anything17:23
jamnelius: can you try this patch: http://paste.uni.cc/1760017:25
neliusjepp, i'm trying... the fech phase takes really long... pleas hold the line17:29
neliusargh...  it failed, but in a new file: /opt/local/lib/python2.5/site-packages/bzrlib/atomicfile.py(97)write()17:29
neliuswant a log?17:30
lnxtechIf I want to setup a smart server that will be accessed via bzr:// does it use the local accounts of the server?17:36
vilalnxtech: no it will use the account it is run from17:38
vilayou should use bzr+ssh for now if you want authentication17:39
lnxtechvila: thanks.17:40
lnxtechAlso,  Is it possible to push/commit to two separate locations at the same time?  I want to have a bazaar repository for my projects at work, but I also want to mirror to my external server so I can work from home and what not17:43
vilalnxtech: you want bound branches, look at 'bzr help bind'17:54
lnxtechvila: thanks again17:55
jamnelius: sorry about the delay, it looks like the same bug. We are creating a file and writing a 0-length string to it, and that is causing a failure17:59
jamnelius: http://paste.uni.cc/1760218:02
jamuse that and the earlier patch18:02
jamnelius: I filed bug 162930 for your use case18:15
ubotuLaunchpad bug 162930 in bzr "Bazaar tries to write 0-length strings to files" [Undecided,New] https://launchpad.net/bugs/16293018:15
ubotuNew bug: #162930 in bzr "Bazaar tries to write 0-length strings to files" [Undecided,New] https://launchpad.net/bugs/16293018:15
ubotuNew bug: #162931 in bzr "`bzr check` incorrectly reports about inconsistent parents" [Low,Confirmed] https://launchpad.net/bugs/16293118:15
vilalnxtech: you may want to track progress on bug #126911, but don't hold your breath18:16
ubotuLaunchpad bug 126911 in bzr "Smart server has no built in authentication" [High,Triaged] https://launchpad.net/bugs/12691118:16
* vila dinner18:17
jammmmm.... food18:19
datohm. what was the recipe to merge two unrelated branches?19:03
datoI just want to merge a branch containing one file into another.19:03
bialixbzr merge -r0..-119:04
datoah, thanks.19:04
datoI was trying -r 0.. only19:04
bialixif you supplied only one rev merge try to merge up to this revision19:05
bialixso you actually did merge -r0..019:05
=== fredp is now known as fredp-afk
jelmerhey lifeless20:07
jelmerI think that was the first time I see you actually disconnect from IRC :-)20:07
lifelessI didn't. My ISP disconnected *me* :)20:11
lnxtechWhen you run bzr init-repo does it default to using --trees or --no-trees?20:18
lifelesson bzr 0.9x and above20:20
lifelessthis is the same as '--init' creating a tree20:20
lifelessso we felt it was more predictable20:20
lnxtechIf I'm wanting to create a shared repo to hold several projects it is generally recommended to use trees or no-trees?20:23
lnxtechor is it personal preference?20:23
lifelesspersonal preference20:25
lifelessif you are working within the repo, trees is handy20:25
lifelessif the repo is somewhere else, and you're using it like a svn or cvs repo, no-trees is better on disk space20:25
lifelessjam: ping20:28
jamlifeless: pong20:29
lifelessjam: my stack of patches is growing alarmingly20:34
lifelessjam: could you review e.g. find_text_key_references ?20:35
lifelessits not in BB for some reason20:35
lifelessbut it is on the list20:35
lifelessabentley: ^ btw, that may be me misuing bzr send; I sent in a cherry pick to get the right diff for _generate_text_key_index20:38
lnxtechlifeless: Why is no-trees better on disk space? (I've been reading through the documentation about this but for some reason I can't seem to get my head around the differences)21:06
datolnxtech: because it doesn't contain the trees. :)21:06
lifelesssay your source code is 100MB extracted on disk21:07
lifelessand say you have 10 branches21:07
datolnxtech: you normally use --trees for the repository at home, and --no-trees for what you publish on your webserver.21:07
lifelessour branch metadata is a few hundred bytes.21:07
lifelessso with disk cluster overhead thats, oh, 200K for 10 branches.21:07
lifelessand 1G for 10 working trees.21:07
sabdfllifeless: very cool perspective from Gerry, huh?21:19
lifelessIan said about my reply: 'That's what I love about you Rob' - always to the point. :-)'21:19
=== phanatic_ is now known as phanatic
glyphhello!  let me preface this by saying that I am not trolling22:10
* jml waves22:10
glyphI am about to recommend bzr to someone22:10
glyphor rather, I'd like to22:10
glyphbut a hard requirement for them is sensible GUI tools for Windows clients, where tortoiseSVN has set a baseline for "reasonable"22:10
glypherm sensible22:11
glyphis there such a thing for bzr yet?22:11
poolfoolglyph: http://bazaar-vcs.org/TortoiseBzr22:14
glyphthe other thing that this particular recommendation hinges upon is "asset" (large binary file) management22:16
lifelesswhat does that mean22:16
glyphlifeless: I'm not sure that I can give a good answer, because it's large and sprawling, and I am not an artist myself, but "this stuff: http://www.softimage.com/products/alienbrain/" is probably a good approximation22:17
glyphlifeless: the person I am talking to is a game developer who needs a single version control system for all the art associated with the game as well as the code22:18
glyphlifeless: they also need to give their (non-technical, windows-using, and somewhat obnoxious) publisher access to the code as it is developed, hence the GUI requirement22:19
glypheverything has problems22:19
glyphAlienBrain is ... unsuitable for code22:19
lifeless(the wowser was me looking at the alienbrain page)22:20
lifelessbzr versions binaries fine22:20
lifelessif they are /huge/ it will eat memory22:20
lifelessand really big may thrash/error. We have a plan there.22:20
glyphlifeless: is 200MB "huge"?22:21
lifelessif you have 600MB of ram, no.22:21
lifelessI think 3 times is our current peak22:21
lifelessit might be 4 time22:22
glyphlifeless: if you were doing a checkin that touched 6 200MB files would you need a gig and a half of RAM or only 600M?22:22
glypherm I mean 4G22:23
lifelessone base copy, one current copy, do a diff, generate a zip store22:23
lifelessglyph: each file is done serially, 600M22:23
glyphlifeless: that's on commit, right?  any issues with update?22:24
glyphmaybe I mean "pull"22:24
lifelessin non-merge cases we'll extract the new text (200MB) and write to disk22:24
lifelessin merge cases we'll extract 3 copies to do a 3-way merge and write a new one to disk, until it trips the binary flag. so 800MB peak.22:25
glyphthat's pretty hefty, but probably not a problem22:25
glyphthese artists have ridiculous machines22:25
lifelessbut I wouldn't expect artists to be trying to merge these files, that would bad.22:25
lifelessbinaries and merging. eewww.22:25
glyphit's apparently not uncommon to have a 64bit windows box with 16G of RAM22:25
glyphlifeless: actually that is the major feature of alienbrain, it does merging on things like photoshop and 3d studio max files22:26
glyphlifeless: by having plugins for the appropriate programs which visually display the differences22:27
hughhi folks, I've been using bzr for a couple of months, after having used svn for a long time22:27
hughI'm still having trouble getting robust mental models of the entities in the bzr world22:28
glyph(one day, when I have a billion dollars and nothing better to do, I am going to make bzr do that.  starting with Python, and "emacs" as the "appropriate program" to have a plugin for.)22:28
hughCould someone patiently explain to me the difference between a branch and a checkout?22:28
LeoNerdA checkout contains copies of the actual files, that you can work on22:29
LeoNerdA branch simply stores history22:29
lifelessglyph: we can do that if someone writes the code; merging is already pluggable22:29
hughOk, thanks; so what is the difference between a checkout and a working tree?22:29
LeoNerdOther RCSes call it a "working directory" or a "workspace" or a "working tree" or similar22:29
lifelesshugh: checkout is more about workflow - working like CVS and svn. working tree is as LeoNerd says.22:30
hughOK; the documentation repeatedly refers to a checkout as a thing rather than a process; this has been confusing.22:30
lifelesshugh: it is - 'bzr checkout' creates a checkout22:30
lifelessa checkout is a thing which is geared to act as a drop-in replacement for cvs or svn22:31
hughmy point exactly, 'a checkout' a thing rather than a process...22:31
lifelessits a thing to support a process :)22:31
hughis a checkout a thing that is any different from the working tree?22:31
lifelessa working tree is a component of a checkout22:31
lifelessa working tree is also present when you have a branch with a tree, so that you can edit and commit in the branch22:32
hughok; what else are components of a checkout?22:32
igchugh: A new User Guide is coming that tries to help explain the concepts up front. See http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html for progress to date.22:32
lifelessa checkout has one of two additional components: Either a 'branch pointer' that points to a branch somewhere else. We call this configuration a 'lightweight checkout'.22:33
lifelesshugh: or it has a 'bound branch', which is a regular branch with a configuration setting that makes commits/pushes/pulls etc to it also be applied to a remote branch.22:33
lifelesswe call that a 'heavyweight' checkout, because you have all the history of the project locally so they take more time to create, and more disk space22:34
hughok, so the lightweight checkout is more like the svn view of things, whereas the heaveyweight checkout bring in bzr's ability to keep the22:38
hughentire branch history locally22:38
lifelesslightweight checkouts have minimal offline capability; heavyweight checkouts have comprehensive offline capability22:38
lifelessmany people don't use checkouts at all, just regular branches. It really depends on your team workflow and needs.22:39
lifelessif you are a solo developer, you can ignore checkouts.22:39
hughso the different checkout variants each get you a working tree, but with more or less support for offline capabilities22:39
hughno I'm working with several folks sitting in different states22:40
hughwe're only rarely at the same site at the same time22:41
hughso we have an 'official' repository, and one guy who's more bzr savvy keeps one or more other branches.... that mirror the official repo22:41
hughthe basic model of: modify files, do local commits, do a push   more or less makes sense, it's when things go wrong that I get confused22:42
glyphlifeless: that's great to hear22:43
hughand then I go look at the man page for the 70th time and try to solidify my mental picture of what's happening :-)22:43
beunohugh, if you're going to be doing local commits, I believe branching makes more sense the checkouts22:43
glyphlifeless: It looks like tortoisesvn isn't quite there yet, although it's getting close22:44
* glyph reluctantly recommends SVN plus a bunch of horrible Apache configuration22:44
hughI think I have a local branch (but am not sure). I do local commits and then push later22:44
beunowhen using checkouts, local commits are normally an exception (have to add an extra parameter), but when branching out, it's local by default, and you send the changes off with "push22:44
beuno" when needed22:44
hughyes, I must have a local branch22:44
beunohugh, sounds like bzr branch is what you want22:45
beunounless lifeless proves me wrong  :D22:45
lifelessglyph: ah well.22:45
lifelessbeuno: I think you're right22:46
lifelesscheckouts are when you want to be in lockstep with other people22:46
lifelesshave a look at the Workflows wiki page22:46
beunohugh, using checkouts for that kind of workflow won't break anything, just make it a bit more uncomfortable as you will have to be adding an extra parameter every time22:48
lifelessbeuno: extra parameter ?22:49
beunolifeless, --local?22:49
lifelessoh right; when you want offline22:50
beuno(when using checkouts)22:50
lifelessanyhow, my advice is -22:50
beunohe was saying he does local commits until he wants to send it off to the parent branch22:50
lifelessif you are used to cvs or svn, use the cvs and svn commands - bzr checkout, bzr commit, bzr merge, bzr branch REMOTEURL to create a new branch then bzr checkout that URL22:51
lifelessif you are not used to cvs or svn, do not use the checkout command at all until you are comfortable with regular branches22:52
jmlhow can you use an external diff util w/ bzr?22:53
jmlthere's a diff option option, but not a diff cmd option.22:54
beunojml, you can use aliases for that22:54
datojml: I *think* there is a plugin22:54
beunojml, http://doc.bazaar-vcs.org/latest/en/user-guide/using_aliases.html22:55
lifelessjml:  it will automatically use gnu diff if the options are not supported in bzr22:55
beunowait, the example isn't there22:55
lifelessjml: also there is a diffutils plugin22:55
* beuno looks for the example of using different diff utils22:55
beunowasn't there one laying around that used meld?22:56
lifelessI thought diffutils did that23:02
lifelessmeld is in my ep2006 talk slides23:02
igcjml: the diffutils plugin is great23:03
igcI use it in combination with meld all the time23:03
YGingrasI see that mercurial uses bzr's diff3, anyone knows if it have been factored out from either rev control system?  I'd need 3-way merge in Gazest, a wiki I'm working on23:07
lifelessYGingras: you could just import bzrlib :)23:08
YGingraslifeless is it exported in a way that I can use it without a bzr repo?23:10
YGingraswill bzr easy_install cleanly on most plateforms?23:12
YGingrasI see C extentions: probably not23:13
lifelessthey are optional23:13
lifelesswon't affect loading the diff3 stuff you need23:14
YGingrasso, in Merge3.__init__(self, base, a, b), base, a and b are paths?  I thought those were rev-ids or something23:16
hughlifeless: beuno: others: thanks for your feedback; this is helping me a lot; catch you later23:18
YGingrasok, I see it: list of lines23:18
YGingraslifeless: how does it compares with gnu diff3?23:18
beunohugh, anytime  :D23:19
lifelessYGingras: they are texts23:21
lifeless'line2\n'], [], [])23:21
lifelessfor instnace23:22
YGingraslifeless: sounds good, I think I'm going to use it.  Will you guys be mad at me if I end up repackaging it yet another time? :-)23:24
lifelessmad? no. Think its a bit pointless and that you miss out on improvements; yes.23:25
YGingrasof course I'm going to watch for improvements but this file seems really stable ;-)23:33
lifelessI'm surprised more of the vcs infrastructure isn't usable for you; wikis and branches have lots in common23:39
YGingraslifeless: I use some bits from mercurial for finding LCA, I probably go hunting in bzr an hg again when I implement new features23:41
lifelessI was meaning more about history storage23:41
lifelesse.g. using a pack repository object directly, no commit or inventory objects though23:42
YGingraslifeless: that questing comes often.  I don't know how you do it precisely in bzr but interface offered by drcs is typically for a whole repo while most wiki acitons are for a single file23:45
YGingrasit's easy to roll my own branch on a single file that to call bzr in  a pipe to branch the repo everytime someone hits the edit link23:46
lifelessYGingras: using the library its easy to use the core storage facilities to do what you need23:47
lifelessI wouldn't have mentioned it if it wasn't trivial23:47
YGingraslifeless: I can't count the number of persons who mentioned calling git in a pipe like it was trivial23:49
lifelessI wouldn't call a pipe level interface trivial23:50
lifelesslibraries are so much better23:50
YGingras"use git: git is super fast => your wiki is going to be uber fast"23:50
lifelessanyhow, the point is that you don't need whole-tree operations; and bzr's core doesn't force you to use whole-tree operations in the sort of scenario you are talking about23:50
YGingraslifeless: that's really interesting, I'll have a serious look at it23:51
lifelessIn particular I'm thinking of PackRepository's text index / mapped knits layer23:51
lifelessyou could use the path to the wiki page as the key23:52
lifelessso this does not give you 'a wiki you can bzr branch', it just gives you a db that supports annotate and other such things as built in primitives23:52
YGingraslifeless: how would it scale across multiple webhead?  I recall some obsure performance issues on NFS23:53
lifelesspacks should be fine on nfs23:53
lifelessgranular locking during data insertion23:53
lifelessno need for oslocks23:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!