=== kiko is now known as kiko-zzz
lifelesspoolie: I did review your lp_registration patch; it doesn't seem to be in bzr.dev ?03:49
poolielifeless, i may not have merged back 1.2, i'll check03:53
lifelessspiv: ping04:40
spivlifeless: pong04:55
lifelessI've just sent an updated patch for external ref support04:55
lifelessI'm hoping you can review it as it contains smart server changes04:56
lifelessthe old patch is a week old now too; which is the other thing.04:56
spivI'll take a look.04:57
lifelessspiv: thanks04:59
lifelessdone for de day; ciao05:25
bob2http://thyrsus.com/lists/uvc-reviewers/2008-January/000016.html -> "One of my big complaints about bzr is that it tries to hide the fact05:39
bob2that history is no longer linear"05:39
thumperbob2: your issues, or raising someone elses?05:40
bob2ted t'so's05:43
poolieso there is some tendency that way but it's a bit inaccurate06:08
pooliewe show branch points in viz, we just don't show it by default in log06:08
fullermdI'd tend to agree more with him, if he could show some way to make a command-line 'log' NOT do so, and still be comprehensible.06:09
fullermdBlatting them out in unannotated partial order (or just plain chronological) sure isn't a solution.  mtn's annotated graph output is staggeringly unpleasant too.06:10
fullermdI maintain that the reason gitk and mtn-viz gets pushed so much harder than bzr viz is that you just can't figure things out from the CLI 'log' output.06:11
fullermdWhereas bzr log's linear projection (with the subsidiary forms of action that enable it), while misleading and oversimplified, DOES let you figure things out much better.06:12
johnny_where are the bzr 1.2 release notes?08:27
jabrjohnny_: https://launchpad.net/bzr/1.2/1.2/ ?08:40
johnny_well they aren't linked on the main page08:40
jabryes, they are.08:40
jabrlinked from the link "full changelog"08:41
johnny_oh.. it is fixed now08:42
johnny_i think i had that window open for a while..08:42
johnny_thought i refreshed the thing08:42
johnny_i'm looking at this bzrarchives blueprint08:43
johnny_got any other systems you guys are looking at to take inspiration from?08:43
johnny_people always found that confusing in monotone for sure08:44
johnny_they use sqlite for the archive storage08:46
appcinehi, bzr push works like 1/5 times. otherwise it just stalls.09:35
appcinessh/sftp works dandy all the time thouggh09:35
appcineI ditched my old svn history and went 100 % bzr, but I really can't work like this.09:36
appcinepython goes up to use 99% cpu09:36
frskIt stalls when working on local files?09:37
appcineafter a commit, I push the files to a server09:37
appcineusing bzr+ssh09:37
appcineand often too..09:37
appcinenow I have to: commit, push, ctrl-c (like 30 times), go to server, break-lock .. push again etc .. until it works09:38
appcineand I hopen I'm alone with this, because I've recommended bzr to A LOT of people :)09:41
=== weigon__ is now known as weigon
awilkinsappcine: Are you working on a wireless connection?09:52
appcineawilkins: yes09:52
appcineawilkins: both at work and at home09:52
awilkinsIs the signal a bit flaky? The only time I had any trouble with plain BZR (over a shared filesystem) was when the connection was dropping.09:53
appcineit's not very flaky :/09:54
awilkinsHow big are your branches?09:54
appcine120 MB or so, including a lot of media files09:58
awilkinsIt could be the large binaries that are giving you trouble, I've seen warnigns about that in the documentation, although I am no authority on the matter.09:59
awilkinsOn the other hand, 120MB is not too much, I have a partially converted repo with over 900MB of packs in it.10:00
appcineand it's soo weird that it works 1/510:01
appcinealmost consistently10:01
appcineI get this in my client log: WARNING: This transport does not update the working tree of: ...10:02
appcinebut that's quite alright, no?10:02
awilkinsThat's normal10:02
appcineJust means that I have to update the server10:02
awilkinsDo your server repos have a working tree, is it desired?10:02
appcinethen Using fetch logic to copy between KnitPackRepository ...10:02
appcinethen somethign weir happens10:02
appcinewhenever it is going to stall, i see the progressbar10:02
awilkinsWhy not try rich-root-pack instead?10:02
appcineand I get this in my log: not updating child fraction10:02
awilkinsSee if that helps at all10:03
appcinerich-root-pack? :)10:03
awilkinsDifferetn repo format10:03
appcinehow do I change that then?, hehe10:03
awilkinsYou take your branch and bzr upgrade --rich-root-pack10:03
datoawilkins: uhm, KnitPackRepository == packs10:03
datopack-0.92 I mean10:03
awilkinsOk, proabbly not much differnt then10:03
datoawilkins: and pack-0.92 and rich-root-pack will be the same for performance10:04
awilkinsappcine: I think you should try it over a wired connection10:04
awilkinsThat will at least eliminate one variable from consideration ; you're going to have to be a detective to isolate the cause.10:05
appcinehehe yeah10:09
appcineplugging cable in10:10
sttng359I am curious if bzr can/will preserve file permissions/ownership in it's database.10:11
appcinesame over cable10:12
appcineIt just doesn't do anything and .bzr.log is spitting out "not updating child fraction"10:13
awilkinsBut you feel less doubt and fear, for now you know it isn't your wireless flaking out!10:13
appcinehaha, yes! :)10:13
appcineanything else I can try?10:14
appcineIt's nice with software that you want to work10:14
appcineLike bzr, it doesn't work for me .. normally I would go use mercurial or back to svn instead10:15
appcinesince it's totally disrupting my work10:15
appcinebut .. you keep on trying10:15
lukssttng359: no, it can't (by design)10:17
appcinecould that be my problem perhaps?10:18
luksnormally when you work with source code, you work with multiple people so preserving the ownership doesn't really makes sense10:18
sttng359yes, I understand that design principle and why cvs/subversion and others use it10:18
sttng359but I am currently looking for something more suitible for version /etc where large subtree may not even be versioned and preserving permisisons it more important as it's single use only10:19
appcineBut no, it happens with sftp also for me :(10:19
sttng359So I am looking for a decent configuration versioning, not source code versioning10:19
sttng359also, something that could version across hosts would be nice, such as pushing changes for nss_ldap.10:20
sttng359I just saw a blog of someone mentioning using Bazaar on /etc.10:21
=== johnny_ is now known as johnny
datosttng359: there is metastore and etckeeper10:23
awilkinsI use monotone on my /etc at the moment10:24
awilkinsBut I may well switch to bzr, mtn is good but not perfect10:24
datosttng359: though I thought jelmer had added bzr support to etckeeper, but I can't see that being the case10:25
johnnymtn does have soeme nice things tho..10:25
awilkinsI can't bring to mind any features that bzr doesn't (not to say there aren't any, just none I care about )10:25
ubotuNew bug: #193214 in bzr ""bzr up" in a branch with local commits shows changes twice" [Undecided,New] https://launchpad.net/bugs/19321410:25
awilkinsAnd I think learning Python for hooks is probably more productive than Lua10:26
johnnythe sqlite storage is mtn is neat10:26
johnnyand the arbitrary certs10:26
awilkinsAre you mining the database for information?10:27
johnnylua is simple enough at least10:27
johnnywe have about 30K revs in mtn across 4 databases10:27
johnnyi don't think monotone will every be a big thing tho...all the other vcs will just mine it for information :)10:28
johnnythe project that is10:29
sttng359I mainly just want to track changes in configuration files through package upgrades, or when services stop working.10:29
awilkinsYes, I think it's probably a battle between git and bzr now.10:29
johnnyi just use dispatch-conf10:29
johnnyin gentoo sttng359 `10:29
sttng359Also, a mechanism for pushing common configuration files between servers would greatly help in maintenance.10:29
johnnymaybe you want something like cfengine?10:29
johnnyor is that too intense? :)10:29
awilkinsgit has a crack squad of Kernel developers, bzr has a nice easy-to-learn language and popular visibility in the Ubuntu community.10:30
awilkinssttng359: There's a "update tree" plugin for bzr that will do a server-side update after a bzr+ssh push, afaik.10:31
sttng359Ahh, I remember reading about cfengine a few years ago, but I was not ready for it.10:31
sttng359Perhaps that's the solution to my needs.10:31
appcineawilkins: I upgraded from 1.1 to latest trunk, it still hangs, but I get "34.513  not updating child fraction" -- a preceeding float number -- in my logs now10:34
appcineand now cpu goes to 99%10:34
awilkinsLooks like it's probably a known bug if they are adding more debugging information to the messages in newer revisions10:34
awilkinsOr at least, a reported / suspected bug10:35
appcineI really wanted to solve this..10:35
appcineI guess I have to merge my current changes back into the svn repos and use that for a few more months until this is fixed. Else my boss will have my head10:36
awilkinsDo a bzr annotate on the file which generates the message - maybe the commit log will give you more information about what's going on.10:36
awilkinsHave you tried setting up a persistent smart server?10:37
appcineNo.. but this also fails using just sftp10:37
appcineand the changes I make is a comment in just one file10:37
awilkinsTry archiving up the branch on the server, unpacking it to your local filesystem, and pushing to that.10:38
awilkinsThen you know if it's a network-protocol problem or a corrupted data problem10:38
appcinegood idea10:38
appcineBut I really haveto go tow ork .. it's lunch already and I'be been trying to solve this all morning :)10:41
awilkinsFair enough10:42
awilkinsMight I recommend SVk for disconnected operation from an SVN repo?10:42
awilkinsI recently ditched it for bzr because it had a bug that caused me real problems... and Perl gives me a headache.10:43
awilkinsBut I was using it for some time without trouble.10:43
awilkinsYou don't even have to ditch your comfy SVN tools like TortoiseSVN (or whatever you use).10:44
luksI find bzr with bzr-svn much easier to use than svk, and actually even more functional10:44
luksbut I mainly use it for only for merges10:44
awilkinsYes, the bzr merging is better10:44
awilkinsA merge bug is what lead me to ditch SVK10:45
awilkinsIt was a blocker too - it couldn't do a particular merge, I couldn't find a workaround, so I was faced with re-mirroring the SVN repo and waiting for it to happen again, or trying something else.10:46
appcinesvn was working great for me, but I hear bzr branching is better .. and I branch a lot10:47
appcineI get this in my server "bzr info"10:47
appcineConflict: can't delete apps/new_media because it is not empty.  Not deleting.10:47
awilkinsbzr / SVN branching are equally easy (you might even say that SVN branching is less costly on resources), but bzr MERGING is where it shines10:47
lukswhy do you have a working tree on the server?10:48
awilkinsappcine: Try resolving that conflict. And then (thanks luks) nuking the tree.10:48
appcineluks: I have NO idea! :)10:48
awilkinsHaving a tree is the default.10:49
luksnot if you push over sftp/bzr+ssh10:49
awilkinsDepends where the branch was created.10:49
appcinebzr remove-tree10:49
appcineis that safe?10:49
awilkinsYou might need a --force10:49
luksappcine: if you don't have any local changes there10:49
awilkinsDepends if those non-empty files are significant10:49
awilkinsThey represent local changes you might want to keep (or they might just be build cruft)10:50
appcineI have a dir in my tree: media/user_uploaded/10:50
appcinethat's not version controlled and contains user uploaded data10:50
appcinedoes remove-tree delete the actual files?10:50
appcineor what does it do?10:50
awilkinsremove-tree removes the files from disk, but not the repository storage10:51
appcineI need the files on the disk10:51
appcineotherwise apache can't serve them10:51
awilkinsIf you are pushing to a common branch there is always a risk of conflict.10:51
appcineI am pushing to our live-server10:52
appcineWorking on my laptop, pushing to the server when done.10:52
luksI wouldn't use bzr to push to an apache-served directory10:52
appcinethe restart apache and the site is live10:52
awilkinsProbably not such a great idea to serve straight from a full branch10:52
awilkinsBecause you are serving the .bzr repo as well10:52
appcineit's not php10:52
awilkinsPaste address10:53
appcineit's a python site and the source code is not avaialble in apache www-root10:53
appcineSo, let's start from scratch :)10:53
appcineI used to work like this: work on my laptop, commit to svn server, ssh to web server and update. restart apache10:54
luksappcine: are you updating the working tree manually?10:54
luksor using push-and-update?10:54
appcineNow I: work on laptop, commit, push to web server, ssh to webserver, bzr update and restart apache10:54
appcineNow, the bzr remove-tree that I ran, has it destroyed anything? I ctrl-c:ed when I saw what was happening.10:55
awilkinsHow about you have a no-tree branch on the server and do a bzr export instead?10:55
appcineAnd, is there something wrong with theat workflow?10:55
awilkinsremove-tree will nuke the "working copy"10:55
awilkinsIt doesn't destroy any revisions10:55
appcinebut it will remove files?10:55
awilkinsIt removes the files from the working copy10:55
awilkinsBut probably not the unversioned ones10:56
luksbzr reconfigure --tree if you want them back10:56
appcineluks: PHEW.. hehe10:56
awilkinsbzr checkout10:56
appcineit removed a lot of user uploaded files10:56
datoappcine: do bzr update10:56
appcinedato: nothing happened10:56
luksappcine: you version user uploaded files?10:56
datoI arrived late to the party10:56
awilkinsbzr update only works if there's a tree10:56
appcineluks: no, but the dirs they were in10:57
awilkinsa checkout reconfigures it back to tree and gets the files.10:57
datoawilkins: but he said he ctrl-c'd early10:57
luksI'm quite sure it doesn't touch non-versioned files10:57
appcineawilkins: I can't run checkout because .bzr still exists10:57
awilkinsappcine: checkout fetches the files from .bzr into the working tree10:58
appcineluks: It seems like it removed the versioned directory containing the files10:58
awilkinsif you jsut go into the branch and do a "bzr checkout"10:58
awilkinsappcine: If you can confirm that behaviour, that's bad10:58
appcinebzr: ERROR: File exists: u'/home/appcine/webapps/appcine/.bzr'10:58
appcinewhen doing bzr checkout10:59
* awilkins is confused.10:59
luksappcine: if I do that I get a conflict telling me that there are unversioned files10:59
luksso I'm not sure what exactly did you run11:00
awilkinsThere isn't a "force" option either, you'd have to remove them manually to get it to clear the tree11:00
appcineluks: bazaar remove-tree --force .. then, when I noticed what was happening, i hit ctrl-c11:00
awilkinsluks: How about if they are in your ignore list,?11:00
luksappcine: "bzr: ERROR: no such option: --force"11:01
luksawilkins: same error if they are ignored11:01
luksappcine: err11:01
appcinebut how do I get my site back up now? :)11:02
lukswhat _exactly_ did you run?11:02
appcineluks: sec11:02
appcine$ bzr remove-tree11:02
lukseither way, running random commands your live site is not the greatest idea11:02
appcineI know :)11:03
luksthen it complained about non-versioned files in the working tree11:03
luksif you had there any11:03
awilkinsMy recommended layout ; put a no-trees branch somewhere other than inside your web root.11:03
luksbzr --version?11:03
awilkinsTHen do a bzr export to the desired location11:03
appcineno-trees branch, ok11:03
appcineand then to keep it up-to-date?11:03
awilkinsEither make a lightweight checkout for your web app, or use bzr export11:04
appcineNevermind the deleted user-files, that directory had been renamed11:04
appcineI got so stressed up11:04
awilkinsTHe lightweight checkout is probably easiest to keep fresh11:04
appcineand the lightweight checkout is something you do from the server?11:05
appcineDoes my laptop need to have a public ip for that?11:06
awilkinsYou might be able to hook script it, I'm not up to speed with bzr hooking though11:06
awilkinsappcine: No, there's a branch on the server11:06
awilkinsappcine: You do your checkout from that11:06
appcineSo .. if I start from scratch now11:06
awilkinsWork on laptop, push to branch on server, ssh to server, lightweight checkout to web app folder11:06
appcinefrom client I run: bzr export bzr+ssh://server/project11:06
awilkinsFrom laptop you bzr push bzr+ssh//server/home/me/mywebappdeploymentbranch11:07
awilkinsfrom server bzr checkout --lightweight /home/me/mywebappdeploymentbranch /var/www/webapp11:08
awilkinsThen for updates bzr update /var/wwe/webapp after a push11:08
appcineAh, ok ..11:09
appcineLet me try that11:09
awilkinsI'm inferring from the docs that hooks don't run at the target end of a push, even if you're using the smart server.11:10
awilkinsBut you could splat together a swift deploy script that did the push and an ssh remote bzr update /var/www/webapp11:13
awilkinsI think the problem you've run into is that you have a server folder that fills with unversioned files that you subsequently renamed in your local branch11:14
appcineUpdating manually on the server really isn't a problem11:16
appcineI'm usually always logged in there anyway11:16
awilkinsMaybe you could get around that by using a symlink for your user upload area .. that way bzr should ignore the content (it's only versioning the link)11:16
appcineAnd how would that work for local development?11:17
=== jrydberg__ is now known as jrydberg
appcineIE, the link would be different, now?11:17
awilkinsYou could make it a link to the same path clocally11:17
* awilkins is on windows and cannot readily test this theory :-)11:19
appcineOk, site back up11:23
awilkinsjelmer: Something in one of our production repos is producing a deadlock in bzr-svn (ie it sits there and neither process consumes CPU)11:23
awilkinsjelmer: (by neither process, I mean svnserve and python bzr)11:24
awilkinsjelmer: Would a copy of the svncache help with debugging or would you need more than that?11:24
appcineawilkins: And it seems like my problem has been resolved11:25
awilkinsappcine: I think you're just going to have to be careful on the server with that unversioned content, but with a treeless branch on the server there should be no excuses for pushes failing, if you are pulling/merging any other developers work before you do it.11:27
awilkinsBut I'm guessing you are the sole "pusher" here11:27
appcineI am11:27
awilkinsThose error message could be more helpful.... were you committing on the server?11:29
appcinecomitting, pushing on client, update on server11:31
appcineOk, situation under control. Thanks a lot for the help11:33
johnnyhmm.. got loggerhead nearly working now.. something is odd about the public branch url tho..11:34
muffinresearchAnyone had any joy setting up bzr-svn on osx 10.4? I'm following the instructions here http://bazaar-vcs.org/BzrForeignBranches/Subversion but the install is failing with make: *** [subversion/bindings/swig/python/core.c] Error 12711:46
=== jezdez_ is now known as jezdez
=== Verterok is now known as Verterok_
jelmerawilkins: Are you using 0.4.7 or the 0.4 branch?12:02
wortktdoes anyone know is there a hook or something like that to catch push or commit on the remote repository side?12:11
wortktlike when you do bzr push bzr+ssh://remoterep.server/repo12:12
wortktso that remoterep.server does something like sends an email when this happens12:13
jelmerwortkt: no, you can only use local hooks at the moment afaik12:13
ubotuNew bug: #193250 in bzr "memory error when attempting to copy a branch" [Undecided,New] https://launchpad.net/bugs/19325012:31
grutte_pierhas anyone ever tried to set up a repository/branch accessible over http+access permissions as set in an .htaccess file?12:32
grutte_pierbasically: got bzr to handle http code 401 by means of a plugin/experimental path?12:33
=== mrevell is now known as mrevell-lunch
awilkinsjelmer: 0.4 branch12:43
jelmerawilkins: Please try the 0.4.7 branch12:44
jelmerthe 0.4 has some severe performance regressions at the moment12:44
awilkinsWell, it's not a "performance" problem ; it just sits there doing nothing (no resource consumption), but I'll try.12:44
* awilkins reverts to r 87712:46
jelmerit iterates over the history unnecessarily12:46
jelmerit's mainly bandwidth usage, not cpu or memory12:46
awilkinsI think the reason I moved forward was https://bugs.launchpad.net/bugs/19157212:52
awilkins... which is where I am now.12:54
awilkinsjelmer: I thought all the history got cached?13:05
jelmerawilkins: the path changes (the paths in "svn log -v") are cached13:05
awilkinsjelmer: The server process was also doing nothing when it was in this condition ; it sat there for 2 1/2 hours doing nothing.13:07
awilkinsI didn't notice the server even eating 1% of the cpu on the occasions I checked.13:08
awilkinsOh, by the way, since there are no API changes for 1.2, is bzr-svn compatible ?13:09
jelmerawilkins: haven't checked yet13:10
awilkinsjelmer: Which bit of libsvn has that humungous memory leak?13:12
jelmerawilkins: the python bindings themselve13:12
awilkinsjelmer: It's not entirely solved even by those patches, is it?13:15
corporate_cookieI'm attempting to build an RPM for BZR1.2 on RHEL4 and I'm getting "error: file 'bzrlib/_dirstate_helpers_c.pyx' does not exist" ... is this related to Pyrex ?13:15
jelmerawilkins: there are several other leaks that are only fixed in 1.5 I think13:16
awilkinsjelmer: I should think so, it eats 1.5GB processing the first 300 or so revisions13:17
awilkins'tis a shame that "pull" doesn't count up revisions, it's not very reassuring :-)13:17
jelmerawilkins: That's not right though13:17
jelmerawilkins: That sounds like it doesn't have *any* memory leak patches applied13:17
awilkinsI should be using the windows builds from http://d5190871.u44.websitesource.net/bzr/13:18
* awilkins does some checking13:18
awilkinsjelmer: Some of these revisions are very large ; the tree is large, and it has quite a few larger files in it too.13:20
jelmerthe size of the files shouldn't matter13:20
awilkinsI'm just wondering if the size of the tree is accentuating some of the memleaks.13:21
jelmerwhat do you mean by large specifically?13:22
awilkins39,000 files13:22
jelmerin a single tree?13:22
awilkinsSome of the files are as large as 50MB13:22
jelmerwow, ok13:23
awilkins(not many that large though, they are mostly in the 10-100s of KB range)13:23
jelmerhave you tried with native bzr<->bzr with a tree that large13:23
awilkinsjelmer: Nope, but I shall try an export of this tree and branch it.13:24
=== mrevell-lunch is now known as mrevell
awilkinsjelmer: Ok, I've done that now ; it tops out at 190MB to either commit or branch this tree (via the filesystem).13:58
jelmerawilkins: that's the same history size / number of files/ size of files as in svn?13:59
awilkinsNo, alas.13:59
awilkinsIt's the same files, but I don't have 13,000 revisions of history13:59
awilkinsJust one revision13:59
awilkinsI'd have to convert the repository to bzr via other means if I wanted all those revisions.14:00
awilkinsI could try sv2bzr I suppose14:02
awilkinsI don't suppose svn2bzr is compatible with bzr-svn, is it?  :-)14:03
jelmerawilkins: You can try the subversion 1.5 binaries if there are any yet14:03
jelmerawilkins: if it's just one revision, it's not a proper simulation so not really a sign that the memory leak is in bzr-svn14:04
jelmer(or python-svn/svn)14:04
awilkinsjelmer: I agree, but the difficuly is simulating an identical revision tree without converting it over :-)14:04
awilkinsjelmer: svn2bzr shouldn't suffer the same problem since it works from dumpfiles14:05
awilkinsSo that would be one way of getting an equivalent branch14:05
awilkinsI shall instruct the server to make me a dump.14:05
jelmerawilkins: you can also try the 'bzr pull -r...' trick to work around the memory errors14:13
awilkinsjelmer: I was just resuming when it crashed, which seems to work well enough until it gets to that KeyError exception14:14
awilkinsThe latest revisions don't even do that though, they just become inactive and do nothing (as describe further up)14:15
jelmerawilkins: Right, but that's what you get for running a development version :-)14:15
jelmerawilkins: That bug is unrelated to bzr-svn, it's a bzr bug.14:16
awilkinsjelmer: Rock >> awilkins << hard place14:16
awilkinsIt's not essential, I don't really work on this branch much anymore, most of my projects are in much more manageable branches14:17
awilkinsI just like to torture test things :-)14:17
awilkinsjelmer: reading 191731, I may just install 1.2 and try that14:20
=== kiko-zzz is now known as kiko
awilkinsjelmer: Much improved in 1.2, but still eating heap big memory. Python is a reference counter, not a garbage collector, yes?14:38
* awilkins again wonders what bzr would be like on IronPython14:39
jelmerI'm pretty sure bzr-svn doesn't keep a lot of handles open though14:39
awilkinsIt's still creeping up, but it creeps back down again a lot more than before14:40
awilkinsIs there any kind of ?heap? viewer in the debugger ; get an idea of which objects are holding the memory?14:40
jelmernot as far as I'm aware14:41
=== mw is now known as mw_______
=== mw__ is now known as mw
jelmerit's really tricky to debug this sort of thing with cpython14:41
awilkinsIt seems to go through big leaps of memory use for certain revisions ; it's almost like it's growing a bloody enormous hash table14:41
awilkinsI had a look at the log, they don't seem to correspond to revisions with large deltas14:42
jelmerit may be to do with how packs work14:43
jelmeror perhaps the fact that bzr keeps whole files in memory atm when applying deltas14:43
awilkinsIt seems to be holding between 1.48 and 1.6 GB14:43
awilkinsYes, I did notice that committing large files to my export/branch test ate memory for the whole file14:44
awilkinsBah, the ceiling went from 1.48 to 1.6114:45
awilkinsIt's managed over 700/9243 revisions so far....14:48
awilkinsDoing much better on 1.2 that 1.1 did14:48
* awilkins tries the -r 100 trick :-)15:09
ubotuNew bug: #193304 in bzr-svn "Unable to start a bazaar branch in a directory containing .svn directories" [Undecided,New] https://launchpad.net/bugs/19330415:10
=== juliank0 is now known as juliank
unenoughhow does bzr compare with mercurial? (i just heard of that one)15:13
jdongunenough: they are quite similar15:13
jdong(though maybe bzr devs will beg to differ!)15:13
luksunenough: I don't think you can get an objective answer here15:13
unenoughwell, i'd like to know what bzr ppl think15:14
unenoughi use bzr15:14
luksand I guess the same would apply for #mercurial15:14
jdongunenough: I think both are great tools, but bzr's developer and user community rules15:14
luksI personally have weird feelings about a VCS that doesn't do merges15:14
awilkinsHg doesn't merge?15:15
lukshg uses "merge tools"15:15
unenoughwell since i'm about to rewrite the software world anyway, i'll just stick to bzr for now15:16
jdonghg merges...15:16
jdongjust some of its paradigms are different15:16
jdongto the end user I think it's safe to say it has an analog operation to bzr merge15:16
jdongit handles "shared repositories" differently (more git-like)15:16
luksjdong: like I have to install the rcs package to make it actually merge something? :)15:16
jdongand it (used to be?) significantly faster15:17
jdongluks: I could've sworn when I used hg it merged just fine15:17
awilkinsWhat's Hg written in?15:17
jdongthese days I think bzr and hg have similar performance characteristics15:17
luksjdong: it doesn't have built-in merge15:17
jdongawilkins: python, C-extension diff15:17
awilkinsSame as bzr then...15:17
luksthere is extension that is basically the three-way merge from bzr15:17
jdongluks: hg merge doesn't count?15:17
lukshg merge just starts the hgmerge script15:18
jdongbut what is the difference to the end user?15:18
luksyou need to have a merge tool15:18
lukslike the "merge" program from rcs15:18
awilkinsDoe Hg track file renames like bzr?15:19
awilkinsAnd how does it square that with separate merge tools if it does?15:19
lukshg tracks copies+deletes15:19
luksand using file names, not file ids15:19
abentleyAnd doesn't track directory renames, because it doesn't track directories at all.15:20
jdongunenough: but anyway, since you asked us, IMO bzr is better :)15:21
awilkinsHmm, I'm used to directory tracking, I don't think I'd like to give that up15:21
awilkinsAlthough the "content tracking" in git is an appealing idea, it just isn't mature enough on windows15:22
luksI don't think it ever will be15:22
awilkinsToo close to the "metal" of VFS15:23
luksI also don't like how hg/git handle unicode15:24
luks"just use the current locale and hope everybody is using the same"15:24
lukswhich doesn't really work well if you on both windows and linux15:25
* awilkins never really figured out encoding on *nix, espuncode support15:25
mruizhi all. I want to use 5-a-day package but I got the following error with bzr : http://pastebin.ubuntu.com/4762/15:28
awilkinsDo the "modern" distros come Unicode flavoured out of the box?15:28
luksI think all of them use utf-8 now by default15:29
awilkinsmruiz: That's not an error WITH bazaar, that's a lack of bazaar15:29
mruizawilkins, I'm using bzr 1.2~rc1-115:30
mruizbzr: ERROR: Couldn't import bzrlib and dependencies.15:30
lukspython -c 'import bzrlib'15:31
luksdoes it work?15:31
mruizluks, no :(  ImportError: No module named bzrlib15:31
luksthen you are not using 1.2~rc1-1 :)15:31
luksor you have it installed somewhere else15:31
lukshow did you install it?15:32
awilkinsYou should be able to get a full 1.2 release too (not that it's different to the RC AFIK)15:33
jdongmruiz: are you running hardy by any chance?15:33
mruizjdong, awilkins : I'm using Hardy up to date15:34
jdongmruiz: pycentral, most likely15:34
jdongthey broke it15:34
jdongbug 192992 I think15:34
ubotuLaunchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/19299215:34
theSoftManhello... where can i find winBZR ( the BZR client like winCVS) ? ;-)15:34
jdongwhoa! I got that right!15:34
jdongI just pulled it off the top of my head15:34
jdong(is that sad?)15:34
lukstheSoftMan: there isn't one :)15:34
awilkinsThere ought to just be a Tortoise<D?VCS> that worked with everything15:35
theSoftManhello luks... that so unlucky :-)15:35
awilkinsThey should merge all the various Tortoises and have a backend of plugins15:36
rifhi guys, is there a bzr command to create a file containing history that I can send through email and apply it on a related repo?15:40
rifmore than a patch15:40
luksbzr send15:40
luks(too obvious? :))15:40
jdongawilkins: does that make some sort of giant land turtle?15:41
jdongrif: bzr bundle too15:41
awilkinsHeh, yeah "GalapagosVCS, your one-stop integrated Windows VCS tool!"15:42
luksthe problem is that all have their own little differences15:42
awilkinsThis is true, But I bet you could re-use a lot of the GUI, etc, with some well defined interfaces15:43
awilkinsLog dialog, tree browser, etc15:43
awilkinsUpgrade the log dialog for meged trees, it would still work fine for straight trees.15:43
awilkinsAnd it's an explorer plugin ; having three of the damn things eats more memory than one. And there are issues with overlays (you're only allowed so many, etc)15:45
luksawilkins: I think the status cache is eating way more memory than the explorer plugin15:45
jdongawilkins: yeah and explorer's flaky enough without another massive plugin15:46
lukswhich runs in the background all the time and watches the whole filesystem15:46
awilkinsluks: Ah, yes, it does eat a lot. If you still have it turned on. Which I don't because I have too many large trees.15:46
rifI dont have acces to the branch that I want to create the bundle for, can I specify the last known revision ore something?15:47
awilkinsrif: is your current branch a branch of "that one"?15:49
rifawilkins: and I know the last revision that "that one" has in common with the current one15:50
awilkinsYou should be able to use -r [BASE_REV]..15:50
rifawilkins: I use "bzr bundle -r 25 ."15:52
rifand it gives me a very short output15:53
rifI am currently on rev 3315:53
awilkinsUse the ".." in your revision specifier15:53
awilkins-r 25..15:53
awilkinsIf there's no patch, just a bunch of base64, it's not worked properly15:53
rifit seem to work like this "bzr bundle -r 25.. ."15:55
rifawilkins: thanks15:55
awilkinsdo a "bzr help revisionspec" as well, for further tasty hints15:56
pygihey, me again :)15:56
* pygi was wondering will 1.2 go into hardy?15:57
jdongpygi: hope so16:33
* awilkins waits for shite-tastic java code to finish working.16:34
jdonglooks like it already made it16:34
* pygi checks16:35
pygijdong, ah, right, sorry ... had packages installed from bzr repo for gutsy, so it didnt upgrade16:36
jdongpygi: ah. well bzrtools and bzr-svn haven't followed yet, but I assume they will in short time16:36
pygiok, and python-central is broken as well xD16:36
* awilkins just pulls plugins into his plugins folder16:37
jdongpygi: yay.16:38
jdongawilkins: as do I, but a lot of people do use the system installed ones16:38
* pygi tries to compensate by switching to main server to see if it's fixed there16:40
jdongpygi: no still not fixed16:40
jdongbug 19299216:40
ubotuLaunchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/19299216:40
awilkinshow can you auto-remove files that have been deleted by something else?16:41
pygijdong, funny thing ... this bug seems to happen in every dev cycle :P16:42
jdongpygi: at least it's not as fun as the dpkg breakage some days back16:48
pygijdong, I didnt upgrade when that happened xD16:48
jdonglucky :)16:48
pygihaha, yea ... and I can workaround this issue with pycentral xD16:48
=== gotgenes is now known as gotgene|away
awilkinsIs hardy much better than Gutsy?16:53
=== gotgene|away is now known as gotgenes|away
awilkinsJust wondering whether I should wait for 2008.0416:54
pygiawilkins, depends on your needs? :)16:54
pygiright now it's broken xD16:55
* awilkins prefers non-b0rked software16:55
pygieven "Crash report" crashes :)16:55
jdongawilkins: I would recommend waiting unless you like living on the edge16:55
jdongawilkins: I run it on my macbook because the hardware support is significantly better, but it does break and have quirks from time to time which can be distracting (i.e. fixing a vim bug in the middle of writing a large paper) or prohibitive16:56
* awilkins likes the edge, but not that much, and not on the WifeTop16:56
jdongi.e. today pycentral is broken, so if you tried to install anything python...16:56
LarstiQjdong: oh oh, did you get that vim bug where it would segfault in certain cases when you hit o or O in normal mode?16:56
pygiit can be workarounded, but still .... it takes time :)16:56
jdongLarstiQ: yikes no :)16:57
pygifunny bugs xD16:57
jdongpygi: right, that's the thing. it's not impossible to work with, it just isn't all that convenient16:57
LarstiQjdong: it was horrible16:57
jdonginstead I'd recommend running Gutsy and pulling little things from hardy (i.e. updated packages) where appropriate16:57
jdongLarstiQ: i is next to o, too :D16:57
=== hexmode` is now known as hexmode
=== Toksyury1l is now known as Toksyuryel
BilbekOMG - bazaar is developed with light speed ;)17:38
BilbekI have a (frequently asked) question - how to ignore white spaces while merging?17:40
BilbekI could find anything in bazaar FAQ17:40
BilbekI'm using 1.0.017:41
BilbekI couldn't find how to ignore them in FAQ17:41
Bilbeknor in user's guide17:41
* dato heh's at 3152.2.217:53
jelmerBilbek: I don't think there's a way to do that18:05
thatchBilbek: I haven't seen that feature either... but how would it behave? Is is so one developer can use tabs and another spaces?18:07
Bilbekjelmer: well - I've found out about aliases, so at least diff won't tell me hundreds of changes when there is just one or two18:08
Bilbekthatch: well - sort of... or one developer uses windows and another linux18:08
jelmerBilbek: That only works if you use an external diff I think18:09
=== gotgenes|away is now known as gotgenes
jdonghmm would a "close enough" merge be implementable18:10
jdongwe can call it sloppy/lazy merge :)18:10
thatchI suggest the Windows develop use a real editor that has selectable line endings :)18:12
jelmeryes, it would certainly be possible to implement a merge algorithm that handled whitespace differently18:12
Bilbekok, so in short nobody really asked for it ;)18:14
thatchjelmer: I forget, does bzr have a notion of "binary" files?18:14
jelmerthatch: no18:14
thatchBilbek: I started writing a plugin to _display_ diffs with arbitrary options like that in Jul 07, but never finished it.18:15
Bilbekhm... if I define an alias for diff, will merge use that alias to determine changsets?18:16
jelmerBilbek: no18:17
jelmerBilbek: You may be able to use --diff3 somehow18:18
Bilbekjelmer: yes, but I can't see how I can set any additional parameters for external diff3 program18:19
jelmerthere isn't18:20
jelmeranyway, back later18:20
=== mrevell is now known as mrevell-dinner
Bilbekok, thank you for information18:27
jdongdoes bzr have a commit option similar to git's -v?18:27
jdongin that the diff is shown in the editor window for last minute review?18:27
jdongIMO that's quite useful except when the diff is massive18:28
beunojdong, you can just do bzr diff and it will do it on the working tree18:28
luksbzr commit --show-diff?18:28
jdongluks: does that exist?18:29
luksbzr help commit :)18:29
jdongbeuno: yes, but how long does your memory last when $EDITOR clears the scrollback?18:29
jdongluks: ok I'm an idiot18:29
luksbut I personally prefer "bzr qci"18:30
beunojdong, right. It's for a super-powered user target who can remember thousands of lines per seconds I guess  :p18:30
jdongluks: what's qci?18:31
luksqcommit from the qbzr plugin18:31
jdongoh cool a qt bzr18:32
jdongdidn't know that18:32
luksobviously I'm biased, since I wrote it :)18:33
luksbut I like things like text-completion in the commit message editor18:33
abentleythatch: bzr autodetects binary files according to whether there's a NUL in the first 1K18:55
mwhudsoncan i get bzrtools 1.2 debs anywhere?19:19
PengThe PPA, once someone uploads them? :)19:25
mwhudsonhm, guess so19:25
mwhudsoni guess i'll give that "poolie" character a poke when he gets up19:25
abentleynevermind the fact that bzrtools 1.2 was out several days before bzr 1.2...19:30
ubotuNew bug: #193412 in bzr-webserve "UI: In inventory, files and directories should have different colors?" [Undecided,New] https://launchpad.net/bugs/19341219:50
=== jkakar_ is now known as jkakar
PengI care way too much about ConfigObj than is healthy.20:23
* Peng wanders off.20:23
PengWe don't care about IronPython compatibility, right?20:24
=== cprov is now known as cprov-out
awilkinsPeng: I care about IronPython compat20:35
PengWell, do we try to support IronPython?20:35
awilkinsPeng: Any operation that is CPU bound should (?) be faster under IronPython ; and bzr pegs the CPU during most operations for me.20:36
* Peng wanders off.20:36
PengI'm missing General Hospital. :(20:36
* Peng wanders off.20:36
* awilkins has a MythTV box and never misses anything unless it crashes20:37
awilkinsPlus it would be awesomely cool to be able to write Powershell providers for bzr20:38
* awilkins reveals himself as a nasty smelly windows user20:39
jdongdoes bzr have a way to do a "partial checkout" yet?20:51
jelmerjdong: nope, not yet20:51
jdongaww :( that's a shame20:51
jdongI have acquired these directories of large compressible EPS files20:52
jdongwould be nice if I could just stash them in packs and only check out a working copy when needed20:52
lifelessjdong: you can; what dimension of 'partial' did you mean  ?20:56
awilkinsGah, I'm already hating older source control systems more every day21:00
* awilkins grumbles about stupid evil VCS that don't track renamed files21:00
awilkinsEspecially when they are polluting my nice bzr trees...21:01
lifelessawilkins: :)21:02
* awilkins is currently rebranching / merging his trees21:07
awilkinsIf this works I'll be pleased with my comprehension of things21:09
Penglifeless: Does bzr try to support IronPython?21:10
lifelessawilkins: what vcs are you working with21:10
Debolazawilkins: bzr should still in theory be able to deal with that though, since it knows the content of the file and can infer a rename has taken place in many cases.21:10
lifelessPeng: no21:10
lifelessPeng: if someone sends in tasteful patches to improve things there - fine. But we don't test or QA against it.21:11
awilkinslifeless: MKS Source Integrity21:13
lifelessawilkins: oooooh thats a beast21:13
awilkinsYeah, it's MD hash is "666"21:13
lifelessawilkins: I used to work at a place used that21:14
awilkinsPeng: A start would be running bzr selftest in both CPython and IronPython21:14
awilkinsPeng: I keep meaning to do it.21:15
awilkinsPeng: IronPython 1.1 or 2.0 (alpha 8)?21:15
PengI'm just messing around with ConfigObj for fun.21:18
PengIt has a try...except around an import that isn't supported in IronPython and I was wondering if I could remove the try...except.21:18
PengAnyway, again, I'm just doing it for fun. I won't submit that patch.21:19
datoPeng: what isn't supported by IronPython, you say?21:21
PengThe compiler module.21:22
PengI didn't confirm it, but that's what ConfigObj says./21:22
datoah, ok.21:22
jdonglifeless: ack sorry lost focus... partial as in I want to remove *.eps (or maybe path/images for that matter) from my working copy, and commit doesn't think I've deleted them and remove it... and it'd be nice if update didn't recreate them21:26
seb128how do I tell what log format bzr accepts?21:27
seb128     --log-format=ARG    Use specified log format.21:27
seb128 not really useful21:27
datoseb128: `bzr help log`21:27
lifelessPeng: if the module isn't supported, removing the try:except: will make loading fail :)21:27
seb128dato: where do you I got the line I copied?21:28
datoseb128: and three lines below it21:28
seb128dato: where do you thing I got the line I copied?21:28
lifelessjdong: no, we don't support that at the moment, sorry.21:28
Penglifeless: Well yeah. But do we care if it fails on IronPython?21:28
seb128dato: http://paste.ubuntu.com/4788/21:28
seb128dato: where?21:28
lifelessPeng: but why do you want to remove the try:except:21:28
dato--line              Log format with one line per revision21:29
dato--long              Detailed log format21:29
dato--short             Moderately short log format21:29
* dato shakes his head.21:29
seb128so --log-format=--line?21:29
seb128tha's weird syntax and help description21:29
elmoseb128: no, --line or --log-format=line21:29
dato--log-format=line or --line21:29
lifelessseb128: --line, or --log-format=line21:29
elmoit's spectactulary poor help UI21:29
seb128jockey is using a =gnu21:29
seb128has that being deprecated or is pitti getting that somewhere else?21:30
* dato would have never introduced --line, and always forced --log=line21:30
seb128I'm trying to be nice and update bzr rather than doing apt-get source, change, upload21:30
seb128but bzr is not nice to me there ;-)21:30
datoseb128: gnu probably is a plugin21:30
datos/probably//, even21:30
lifelessgnulog on there21:31
visit0ris there a way for sending commit emails for the remote branch changes without installing the commit mail plugin to every client?21:31
seb128ok, I'll just do apt-get source, update, upload21:31
seb128and explain to pitti tomorrow why I don't like packages maintained in bzr ;-)21:32
seb128thanks guys21:32
lifelessseb128: he should document his practices more :)21:35
lifelessseb128: I'm not sure why you need gnulog to update the tree though21:35
seb128we should just have one common interface to change packages21:35
seb128because he doesn't maintain a ChangeLog but generates one when doing an upload21:36
seb128and he's using this gnu format when doing that apparently21:36
lifelessseb128: indeed. But we don't - even with 'regular' trees there is much variation21:36
lifelessvisit0r: yes, there is a script that checks the branch and sends mail21:36
datovisit0r: http://launchpad.net/bzr-hookless-email21:38
datovisit0r: you'd run that on the server as a daemon, or from cron21:38
visit0rsounds exactly what we need, thanks. did you get that wortkt?21:38
datovisit0r: wortkt->working?21:39
datovisit0r: anyway I use it regularly, and know that several other people do as well.21:40
visit0ryep a collegue of mine, we are transforming from svn to bzr and trying to get things together21:40
datovisit0r: ping me if you get any trouble with the script21:40
visit0rdato: we will, thanks a lot21:40
* dato bbl21:41
visit0r(wortkt is a nick)21:43
schierbeckwow, bzr-avahi kicks ass!21:59
jelmerhey Daniel22:00
schierbeckhi jelmer :)22:00
lifelessspiv: ping22:14
pooliegood morning22:20
mwhudsonhi poolie22:21
mwhudsonpoolie: can you make bzrtools 1.2 debs?22:21
pooliethat's the first thing for me for today22:21
mwhudsoncool :)22:21
spivlifeless: pong22:44
lifelessspiv: ping-pong on the patch again :)22:45
spivlifeless: ping-pong-punged22:47
=== jamesh__ is now known as jamesh
schierbeckhi jamesh, nice work on bzr-avahi!23:10
schierbeckjust tried it out23:10
jameshschierbeck: thanks23:11
schierbeckjamesh: is it possible to have a server running, serving only explicitly advertised branches?23:12
schierbeckother than having --directory point to somewhere empty23:12
jameshschierbeck: I don't think so (although I haven't dug into the bzr server code that much)23:12
schierbeckjamesh: i'm just thinking it would be cool to simply have a config file with the paths to the branches you wish to advertise, and just launching a special server23:13
schierbeckof course, i could just write a script, but it would be cool23:14
jameshschierbeck: it might be possible with a custom transport that collates a bunch of branches and limits access to others23:16
jameshschierbeck: you can also run multiple servers if you want to restrict what you are sharing too23:17
jameshschierbeck: passing --port=0 to "bzr serve" will pick a random port to listen on23:17
schierbecki guess so23:17
schierbeckright now i'm trying using "bzr serve --directory=/dev/null"23:17
jameshwhat would you expect that to do?23:18
schierbeckand then just manually advertising the branches i want to share23:18
speakmanhi ppl!23:19
jameshschierbeck: to advertise the branch, you need to both turn on advertising with "bzr advertise" and run a server that covers the branch23:19
schierbeckjamesh: yeah, just found out. that's a bitch.23:19
* speakman wants to make a "init-repo" WITH tree, but even with --tree there's no working tree at the remote place.23:19
schierbecki was hoping for an opt-in model23:19
bob2schierbeck: "no working tree" after push?23:20
bob2er, speakman23:20
lifelessschierbeck: we don't ever create trees remotely23:20
lifelessschierbeck: trees are filesystem objects23:21
schierbeckstop it!23:21
schierbeckyou guys want speakman23:21
lifelessyup sorry23:21
schierbeckhehe, np :)23:21
speakmanno working tree after push...23:21
schierbeckjamesh: i guess running multiple servers is the solution, then23:21
speakmanI need a tree23:21
awilkinsso open a shell on the server and do bzr update23:22
schierbeckand with avahi, you don't need to communicate the port number, so it's not that much harder23:22
lifelessschierbeck: server hooks should tell anything listening about each server23:22
speakmanthe server havn't got either python nor bzr...23:22
awilkinsYou can't make a tree from a push, because you can't depend on which push method has been used.23:22
jameshschierbeck: bzr-avahi should handle non-default ports for the server just fine, so running multiple servers should work okay23:22
lifelessschierbeck: I wouldn't be surprised if it just works; certainly the bzr-dbus and lan-notify plugin will just-work with multiple servers23:22
jameshschierbeck: although it might get confused if you share the same branch twice23:23
jameshdue to naming conflicts23:23
bob2speakman: maybe rsync'ing everything but .bzr would be an ok workaround?23:23
schierbeckyeah, but all my branches are neatly organized, so it should be fine23:23
jameshlikely one will serve the branch as "foo" and the other as "foo #2"23:23
speakmanbob2: no, it has to go with each commit.. :/23:23
schierbeckjamesh: ohh, you mean aliases23:23
schierbeckyeah, i'm currently namespacing them23:24
bob2speakman: rsync from a post-commit hook ;)23:24
speakmanwhy can't I just have a working tree at remote?23:24
jameshschierbeck: no.  I mean mDNS name conflict resolution23:24
schierbecklike "bzr-gtk-trunk"23:24
schierbeckjamesh: is that the name you provide with --name?23:24
jameshschierbeck: if you run two servers that share the same branch, they can't both share it under the same name23:24
jameshschierbeck: yes.23:24
schierbeckthen we're on the same page23:24
speakmanwhy is there a argument "--no-tree" when I even CANT have a tree? :D23:25
jameshschierbeck: if there is a name conflict, the server automatically renames the branch23:25
awilkinsspeakman: You can have a tree, you just don't get trees from pushing23:25
schierbeckjamesh: i just got a lot of branches named "trunk", so namespacing is required23:25
speakmanawilkins: ok, not by commit either then?23:25
awilkinsspeakman: It's not implemented because it's so much less efficient than having bzr update the tree from the packs23:25
schierbeckjamesh: what characters are illegal in such a name?23:26
awilkinsspeakman: You have to havea tree to commit....23:26
jameshschierbeck: not sure.23:26
schierbecki'll just run a few through, see if they work23:26
awilkinsspeakman: If you can't install bzr on your server but you need a tree there, rsync or another file transfer method is your best bet.23:27
Pengpush-and-update plugin?23:27
PengOh, if bzr isn't on the server, never mind.23:27
awilkinspush-and-update requires bzr on the server23:27
speakmanokay, what I'm look for is a way to version-control a website, and for each commit all changes are visible in the repo working tree via apache.23:27
PengYeah. I just came into the conversation and didn't know that part.23:27
* Peng wanders off.23:28
speakmanis there a better way to do that?23:28
awilkinsspeakman: Without bzr on the server, file transfer is just as effcient anyway ; plus you won't have to transfer the repository23:28
schierbeckjamesh: colon works just fine, cool. now i can name the branch "bzr-gtk:trunk"23:28
speakmanawilkins: but we WANT our repo on the server since we're using it as a bzr repor too! :)23:28
jameshschierbeck: file bugs if you find problems23:29
awilkinsspeakman: You won't get the best performance without bzr on the server anyway ; bzr or bzr+ssh is the best speed.23:29
awilkinsspeakman: And you won't be getting a tree on the server from the repo without bzr23:30
speakmani see...23:30
speakmanthe server is running freebsd I'm a Linux guy.. :/23:30
awilkinsspeakman: File transfer, as said, is just as effcicient as implementing exactly the same thing in bzr.23:30
speakmanawilkins: hm, 66% is using Windows, so it won't be an easy task to automate...23:31
speakmani will consider insatlling bzr on the server though...23:32
awilkinsspeakman: I'd probably rig the tree-transfer from a single machine to which you push23:33
awilkinsspeakman: And write a script that did the push, followed by a ssh remote  call to the rsync script23:33
speakmanmaybe a make a cronjob to a "bzr update" on each 5 min or so :)23:36
lifelessawilkins: that script exists; its called 'bzr-push-and-update plugin'23:38
jdongare obsolete-packs safe to delete?23:38
speakmananyone know how to install it on freebsd?23:39
lifelessjdong: bzr will do so itself23:39
jdonglifeless: really?23:39
lifelessjdong: yes23:39
lifelessjdong: the directory must exist23:39
jdonglifeless: during what operation?23:39
lifelessjdong: during commit/pull/merge/push23:39
bob2the operation /after/ theey become obsolete, right?23:40
jdonglifeless: I just committed and obsolete-packs still contains 4.6MB of data?23:40
jdongbzr 1.2, on bound branch, if that makes any difference23:41
lifelessjdong: thats fine; it will get gc'd automatically. It doesn't make push or pull slower.23:41
lifelessbob2: when we do latency-management packing, we clean obsolete-packs before we put newly obsoleted packs into it.23:41
jdonglifeless: ah, ok, that's cool. But if I am ridiculously tight on space, bzr won't get mad if I remove all the files in there, will it?23:42
jdong(some bad little boy is guilty of borderline-exceeding his quota :D)23:42
lifelessjdong: you can manually trim if you need to; bzr will (rarely) use up to twice the repository size.23:42
lifelessjdong: one of those standard time vs space tradeoffs :)23:42
jdonglifeless: understood, and I agree with the decision :)23:42
jdongit's at 20% of the repository size currently, but 20% is significant on this particular storage location :)23:43
jdongand I can't say enough how much I'm enjoying bzr's performance these days23:44
lifelessjdong: right, so what I'm saying is that you need enough working space for it to peak at 100%23:44
lifelessactually in  theory it could peak at 200% additional, when you consider pending uploads.23:44
lifelessbut I think thats extremely difficult to trigger.23:45
jdongdoes the garbage collect also take care of stale uploaded packs or is that more of my job? :)23:45
lifelessno; theres no safe way to that automatically unfortunately; ctrl-C will cleanup stale uploads that that process created.23:46
jdongright, I think most of my stale issues have come out of broken dumb-protocol pushes23:46
jdongover a lossy network23:46
lifelessyeah network lossage sucks23:46
lifelessproblem is that a new bzr invocation can't tell that its not a concurrent push23:47
lifelessif you know that no bzr's are pushing, you can clean up that dir safely.23:47
jdongright, I'll just do it manually, since it's really one of those odd rare cases23:47
jdongI just wanted to make sure those two locations were safe to poke by hand ;-)23:48

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