#bzr 2007-12-03
<abentley> lifeless: What sort of thing would you like to me to put in the developer guide?
<abentley> And why this, rather than the many other things we're constantly adding to the codebase?
<lifeless> abentley: because I remembered to think about it.
<abentley> Well, it seems like it would be onerous to do this for everything.
<abentley> But where should it go, and what should it say?
<abentley> It doesn't seem to belong under "domain classes".
<abentley> Also, I've just found an optimization that gets it about as fast as the old implementation.
<abentley> On knits.
<lifeless> cool
<lifeless> ok 1.0rc1 debs are up; including dapper
<abentley> Oh, cool.
<abentley> lifeless: Can you give me some guidance on the documenation?  I'm otherwise ready to re-submit.
<lifeless> abentley: one sec, email frenzy
<abentley> Okay.
<jelmer> lifeless: no bzr-svn debs ? would be nice to have them up, at least for gutsy
<lifeless> jelmer: hmm, I'll see how far I get; I go on leave in two days
<lifeless> abentley: ok, with you know.
<abentley> Fire away.
<lifeless> so if the answer is 'there is no developer docs 'about merge' at the moment, then you're good - don't worry,.
<lifeless> starting something that covers the design, motivation, tricks n tips etc for people writing to the collection of apis that combine to make up 'do merge' would be nice at some point.,
<abentley> I don't remember writing any, so there probably aren't any.
<lifeless> I can't see any at a glance in doc/developers
 * lifeless -> food
<abentley> Okay.  Thanks.
<abentley> igc: Hi.
<igc> hi abentley
<abentley> Would you be able to review my criss-cross documentation?  http://bundlebuggy.aaronbentley.com/download_patch/%3C47505D5B.9030702@utoronto.ca%3E
<abentley> jam was a bit concerned about the style.
<igc> abentley: sure
<abentley> The bit about merge --weave being slow on packs may be obsolete soon.
<igc> ok
<Peng> Could someone mark https://bugs.launchpad.net/bzr/+bug/172612 as fixed? The patch is in bzr.dev now.
<ubotu> Launchpad bug 172612 in bzr "new commit is overly verbose" [Low,Confirmed]
<lifeless> done
<Peng> Thanks.
<lifeless> bbs
<jml> lifeless: have you written up anything in English describing the scenario stuff in bzrlib.tests?
 * igc lunch
<lifeless> jml: no
<poolie> jml, i know a bit about it, i can possibly describe it in documentation
<poolie> in fact, i did write something in HACKING, you could look at that
<jml> poolie: I'll take a look.
<lifeless> I should finish my in-file tweaks.
<poolie> questions welcome
<lifeless> might do that tomorrow
<lifeless> poolie: patch sent
<jml> how do you actually use DVC to commit?
<jml> add a log entry and then hit C-c C-c in the log buffer apparently.
<jml> seems kind of backwards.
<vila> jml: cou can hit 'c' in a dvc-diff or dvc-status buffer, it will open a buffer for the commit message and there you can hit C-c C-c
<jml> vila: ahh, ok
<jml> vila: I guess seeing as I review a diff before I commit anyway, that makes sense.
<vila> jml: yeah the dvc-diff buffer is handy, since it's based on diff-mode you can also very easily revert any hunk by using C-c C-a or mark the files for selective commit
<glatzor> hi, is there a document that covers running a bzr server using sshd?
<luks> you don't need to run a bzr server there
<luks> just install bzr on the server and bzr will run it on the remote side over ssh
<glatzor> luks: is there a way to limit the ssh access on the server?
<glatzor> luks: I don't want to allow full ssh access on my machine.
<luks> um, I'm not sure
<glatzor> for my subversion server I use the command option in the key configuration: command="/usr/bin/svnserve -R -t -r /srv/subversion"
<glatzor> ui, you are releasing 1.0 today? congratulations!
<mwhudson> glatzor: you can use something similar for bzr too
<mwhudson> i think it's "bzr serve --inet --allow-writes", but i'm not completely sure
<Peng> --directory=/ too.
<Peng> (And maybe even something else that gets cut off the edge of the screen.)
<dato> jelmer: sorry, I meant the trunk of 0.4, so "bzr-svn-0.4" branch.
<abentley> glatzor: You want to allow bzr access, but not normal shell access?  A restricted shell like rsh can do that.
<jelmer> dato: I would be interested to hear why the trunk version broke
<dato> jelmer: lemme pull and try again. what I saw a couple of days ago is that it didn't do anything after parsing the dump file.
<glatzor> mwhudson: Peng: so I would need a user/key for every repository
<Peng> glatzor: No.
<Peng> glatzor: Create as many users as you want. They just all need the proper file permissions on the repo.
<dato> jelmer: there must be something weird in my user setup; as my user, svn-import does nothing, as a newly created user it works.
<jelmer> dato: does removing ~/.bazaar/subversion.conf help/
<jelmer> ?
<dato> lemme check
<dato> yes
<vila> abentley: ping
<dato> jelmer: so, do you really recommend to use rich-root or rich-root-packs, instead of -with-subtrees ?
<jam-laptop> dato: I don't know that jelmer specifically does, but it was a compromise between him and Aaron
<jam-laptop> -subtrees is still considered experimental, because it enables nested tree detection
<jelmer> dato: yep, I do
<dato> right. so I have to choose between compatibility with < 1.0, using an experimental feature, or >1.0 with non-experimental stuff.
 * dato ponders, as this branch is for other people to use.
<dato> oh.
<dato> you cannot `bzr upgrade` -subtrees to rich-root, but you can pull from -subtrees into a rich-root repository :-?
<vila> jam-laptop: ping, who uses bundle format v4 ? It requires seeking backwards (or force me to wrap http.get() into a StringIO) :-/
<jelmer> vila: are you working on the ability to apply remote bundles ?
<vila> jelmer: no, on the ability to remove wrapping all http requests into StringIO
<jam-laptop> vila: I want to say that v4 is the newest form, so we *all* use them.
<jam> however, I haven't paged through it thoroughly
<jam> I know Andrew was working on making them more of a producer + consumer
<jam> so he could stream chunks as part of the response
<vila>     def get_bundle_reader(self, stream_input=True):
<vila>         self._fileobj.seek(0)
<vila>         return BundleReader(self._fileobj, stream_input)
<vila>     Invalid range access in http://localhost:52409/test_bundle at 28: RangeFile: trying to seek backwards to 0
<vila> That's the only remaining failing test :-(
<jam> vila: let me check
<jam> vila: the only code that seems to be using that is the bundle code itself
<jam> I'm guessing that BundleInfoV4 reads some of the header, etc to make sure that it really is a bundle
<jam> and then passes the stream into the BundleReader class
<jam> and the BR class was written to start from the beginning
<jam> But I notice that the first thing it does is chomp the first line off the file
<jam> So it is possible that we could just pass a "first line read" flag
<jam> vila: in general, I don't see why it needs to seek, other than maybe multiple calls to get_bundle_reader?
<jam> vila: which specific test?
<vila> TestReadBundleFromURL.test_read_bundle_from_url(HttpServer_urllib)
<vila> the strange thing is that all comments referring to stream_input says stream_input=False is currently faster but everywhere we use stream_input=True...
<jam> vila: that is because = False has to buffer the whole file in RAM
<vila> yeah I know ;-)
<jam> so we chose to be memory conservative
<jam> I also wonder how efficient IterableFile is
<jam> vila: ok, so it seems we have already read the whole file by the time get_bundle_reader() is being called.
<jam> I haven't figured out why yet
<jam> but that is why the seek is needed
<vila> well, I will punt on that one and mark the test as KnownFailure so that we can discuss that during review
<jam> ok
<vila> I think it occur because actually transport.get *seems* to always returns seekable files while ftp always returns StringIOs andd http did too
<jam> vila: we always returned seekable files
<jam> because gzip required it
<jam> gzip.GzipFile
<jam> expects to be able to tell() and seek()
<jam> I think tuned_gzip does not
<vila> seek in both directions ?
<jam> seek backwards, yet
<jam> yes
<jam> it would read a bit
<jam> and then put it back if it didn't like what it found
<jam> but I think that has been worked around in tuned_gzip
<jam> which predictively reads
<jam> but keeps a small buffer
<vila> the test suite triggers nothing related so you should be correct
<jam> vila: do you know pdb very well?
<jam> In gdb there is a way to go until you go up a frame
<jam> (something like Finish)
<jam> but I don't see that in pdb
<radix> r?
<vila> jam: can't answer that ;-)
<jam> ah, thanks radix
<vila> you mean 'r'
<vila> radix: I swear I didn't read your reply ;-)
<radix> hehe :)
<vila> up is handy too to inspect callers contexts
<jam> vila: I think we need it....
<jam> vila: yeah, I know about up
<jam> I just needed it for all the times we nest function calls
<jam> foo(bar(baz()))
<jam> I want to step into 'foo'
<jam> but it steps me into the others first
<jam> and I don't want to "n" my way out
<jam> list
<jam> sorry
<jam> vila: so.... the bundle code needs to read at least the start of the file
<jam> so that it can get the first line
<jam> to determine the bundle format
<jam> and return an appropriate serializer
<vila> yeah, got that, but then doing a seek to the beginning of the file *rude*
<jam> well, in my tiny bit of testing
<jam> we do:
<jam> for line in f:
<jam> ...
<jam> which we wanted to do so you could embed a bundle in the middle of an email
<jam> and still have it parsed
<jam> (so we ignore everything until we get to the end of the file)
<jam> anyway
<jam> even though "for line in f" has only yielded a single line
<jam> f.tell()
<jam> returns the end of the file
<jam> vila: anyway, I have the feeling that you will break merging from bundles if we cannot seek
<jam> so we won't be able to do "bzr merge http://bundlebuggy...." which is something that *I* do.
<jam> And I believe Aaron does as well
<vila> yeah, I will break something, sure ;-)
<vila> The question is how will we repair it :)
<jam> well, for starters, you are just trying to get rid of the StringIO() wrapper in HTTPTransport.get()
<vila> So far we *pretend* that we stream to be memory conservative *but* we do that by wrapping the url content into a StringIO.... Ecuse me ?
<jam> I'm not sure that is necessary for readv() support
<jam> I agree it is distasteful
<jam> but it is probably okay in the short term
<jam> we generally don't do get() on big files
<jam> indexes, bundles, etc.
<jam> Everything else we use readv() on
<vila> Not necessary, you're right, I will rollback my last change and leave http.get() wraps into a StringIO and be done with it, just a big red flashing FIXME ;-)
<jam> vila: thanks
<jam> If you are doing anything fancy, make a note of it
<jam> but I imagine you are just removing the StringIO wrapper
<jam> from what I can tell
<jam> for line in file:
<vila> Well, the FIXME was already there: # FIXME: some callers want an iterable... One step forward, three steps backwards :-/
<jam> buffers at 8192 pages
<jam> I'm curious if readline() in the middle would still work correctly
<vila> I will add a better explanaton
<vila> jam: in my case, it's a socket, and yes, read/readline share the same buffer
<jam> weird, the first real read is 8192
<jam> but the second is 10240
<vila> could be a read(-1)
<jam> and then 10240 from there
<vila> which can of file/socket ?
<jam> sure, I'm just commenting on the "open()" (file object) behavior
<vila> s/can/kind/
<jam> and doing "for line in file"
<vila> ok
<jam> start = 0
<jam> for line in f:
<jam>   start += len(line)
<jam>   print start, f.tell()
<jam> Gives interesting results
<jam> f.tell() is definitely being read in chunks of (8192, 10240, 10240, ...)
<vila> for a random text file ?
<jam> just something on disk
<jam> yes
<jam> a 238k file in this case
<jam> vila: anyway, if I was to propose a fix
<jam> it would be to change the bundle reading code
<jam> so that it reads a minimal amount of data
<jam> so it can get the header
<jam> and then it passes the header
<jam> along with the file object
<jam> to the serializer which supports that header
<vila> jam: +1 but I will not be able to do that in the coming days (new project starting in RL)
<jam> vila: I'll write up a bug on it
<vila> I search a bit in that direction but saw nothing obvious and came here for help
<vila> jam: thanks
<vila> s/search/searched/
<dato> vila: does http://dpaste.com/26608/ sound good?
<dato> vila: (re our conversation the other day)
<vila> s/to remote hosts/& with sftp/
<vila> s/is useful to ensure SSL certificates are always verified/is required to verify SSL certificates/
<dato> vila: didn't you tell me it was also needed for bzr+ssh?
<vila> dato: rats, yes, but that may well be a bug
<vila> jam: did you read the IRC logs ? It looks like smart/medium.py requires paramiko, aaron and I thought it should be able to use openssh only
<jam> vila: at one point, we could start a bzr+ssh connection without paramiko
<jam> if we can't
<jam> then it is a regression
<jam> kind of hard to test for...
<vila> jam: look at smart/medium.py I didn't test
<jam> vila: I think it is a bad comment
<jam> It used to "from bzrlib.transport import sftp"
<jam> which *does* need paramiko
<jam> 'ssh' should not
<jam> I'm a little concerned that we use "paramiko.SSHException" in the connect_sftp code
<jam> such that if we don't have paramiko, and we fail to connect
<jam> we will get an AttributeError exception
<jam> vila: but other than that, everything should work without paramiko installed
<vila> dato: as jam said ;-)
<vila> dato: so forget my first comment, but please use the second one, it's the only remaining bit that urllib does not handle today and it looks like for some people it's more a problem than an help
<vila> so there are really two kinds of users, those that want certificate verification and those that absolutely don't want them
<dato> vila: ok. re "more a problem than a help" that's what I wanted to reflect in my wording, like "only install it if you're really sure you want such verification"
<jam> vila: I just removed paramiko from my system
<jam> and "bzr log bzr+ssh:// " worked fine
<vila> great
<dato> oh, good
<jam> I'll post a simple patch to the list
<jam> hmm... it is only in connect_sftp() and our sftp subsystem *does* require paramiko to be present...
<jam> dato: the reason why we went with Requires for paramiko (IIRC) was that people expected sftp support out of the box
<jam> Since we now at least have bzr+ssh, I suppose we could relax it a bit
<dato> paramiko has always been in Recommends AFAICR, but tools are supposed to install recommends by default. my question the other day was whether to demote pycurl to suggests, which I'm doing right now.
<jam> dato: for Ubuntu, I'm pretty sure it was set to Required
<jam> but I could be remembering that incorrectly.
<ubotu> New bug: #173689 in bzr "BundleReader cannot stream" [Wishlist,Triaged] https://launchpad.net/bugs/173689
<james_w> dato: the parallel build check showed that some of bzr refuses to build parallel, at least the docs. I think this is because rules calls 'make docs', when it should be '$(MAKE) docs'.
<james_w> dato: mind if I correct that? A grep didn't show any other uses.
<dato> james_w: please do
<james_w> it might actually cause build failures, or even allow a broken package to be build, if a parallel make is used, but I'm not sure how to test.
<dato> dpkg-buildpackage -j2 ?
<mwhudson> hmm
<mwhudson> so for a test, i want to lock a branch with a given lock id
<mwhudson> this seems to be pretty hard
<dato> james_w: if you don't mind, please use dch -t in the future (leaves the footer alone; so it gets added when opening a new version, and when preparing a final upload)
<james_w> dato: ok, thanks for telling me.
<jam> mwhudson: for any branch format, or just for a specific one?
<jelmer> james_w: Hi James, did you get my merge request for bzr-builddeb?
<jam> because you could just override
<jam> branch.control_files._lock
<mwhudson> jam: er, no, not really
<jam> ?
<jam> otherwise, I guess you could override bzrlib.lockdir.rand_chars
<jam> since that is the final lock token
<james_w> jelmer: yeah, the first one is fine, the second I want to think about a little.
<james_w> jelmer: also is exposing the file properties planned/wanted/not wanted?
<jelmer> james_w: planned/wanted. It depends on support for custom file properties in bzr core though
<jelmer> james_w: what are your thoughts on the second one?
<mwhudson> jam: let me try to explain what i'm trying to do
<bialix> jelmer: do you saw bzr-svn selftest results?
<mwhudson> jam: obviously, branch puller on launchpad locks branches while they are being updated
<mwhudson> jam: if things go wrong in a particular way, these branches can be left locked
<jam> k
<jam> with you so far
<mwhudson> so what i'm doing is have the puller use a particular lock id
<jam> and you want to make the branch puller use specially formatted nonces?
<mwhudson> (by setting BZR_EMAIL)
<mwhudson> so for a test, i want to lock a branch with the same id
<jam> (just realize that pack repositories don't have lock ids at that level)
<mwhudson> then run the puller and check that the puller still runs
<mwhudson> (it will look for and break such a lock)
<mwhudson> jam: ah, that's interesting
<mwhudson> jam: so how would you solve this problem? :)
<jam> pack repositories don't take out a physical lock at 'repo.lock_write()'
<jam> time
<jam> they take a physical lock only when they go to update the 'pack-names' file
<james_w> jelmer: I guess I'll just wait for that, it's not a massively urgent to implement this. I suppose I could guess in the meantime as well, and there is always the command line option.
<lifeless> moin moin
<jam> morning lifeless
<jam> mwhudson: are you trying to get a custom lock token (aka nonce)
<bialix> privet
<jam> mwhudson: or are you trying to set the username inside the lock to that specified by BZR_EMAIL
<james_w> jelmer: as for the second one, I think it's a fine aim, I just want to work out if it is the most natural way to do it. Your final example command line is great, so I guess it may well be.
<jam> mwhudson: I think you are trying for the latter
<jam> such that peek_lock() will give you back what you want
<jam> versus having token = repo.lock_write() give you back what you want
<jam> mwhudson: do you understand the difference?
<mwhudson> jam: i don't think i care
<jelmer> bialix: hi
<bialix> jelmer: evening
<mwhudson> jam: i want to be able to say "is this branch locked?  if so, did i lock it?"
<mwhudson> then, "if all that, break the locks"
<jelmer> bialix: all tests should actually be succeeding, from what I understood from reports
<jelmer> james_w: ok
<mwhudson> if a custom nonce is an easier way of achieving that, then maybe that's what i want to be doing
<jam> mwhudson: well the string returned by "branch.lock_write()" is only part of the whole info on disk
<jam> but lock_write() will spin rather than returning right away
<jam> (default timeout of 5 minutes, etc)
<mwhudson> jam: right
<jam> are you trying to avoid that as well?
<jam> (you *can* set bzrlib.lockdir._DEFAULT_TIMEOUT_SECONDS if you want)
<mwhudson> i'd like to, yes
<bialix> jelmer: I has firewall on my machine. do you want me to run tests one more time with disabled firewall?
<jam> mwhudson: so... Branch.lock_write() will take out a physical lock right away, so it is probably best to think about starting from there.
<mwhudson> my impression is that lockdir.py has all this configurability and flexibility and branches have lock_write() that takes no arguments
<jam> mwhudson: pretty much
<jam> and I assume you are trying to do it without too much surgery into bzrlib itself, right?
<mwhudson> jam: well, i want to deploy this code within the next two weeks, so yes
<lifeless> mwhudson: pack repositories have no over-the-wire locks at all
<dato> hm, suddenly log in bzr.dev is very slow?
<lifeless> mwhudson: if the hpss decides to lock a pack repository itself, it will be because the hpss is performing the write.
<mwhudson> lifeless: this is for the mirror puller
<lifeless> mwhudson: ok; it will take a lock during insertion of the repository for a couple of ms
<jam> dato: with 1.0rc1 or bzr.dev?
<mwhudson> lifeless: so the hpss doesn't come into this
<dato> jam: bzr.dev
<mwhudson> lifeless: it does sound like this is not going to be a problem for packs
<jam> bug #172975, bug #172567
<dato> jam: logging in bzr.dev
<ubotu> Launchpad bug 172975 in bzr "bzr log slower with packs" [Medium,Triaged] https://launchpad.net/bugs/172975
<ubotu> Launchpad bug 172567 in bzr "Per-file log is *very* slow with packs" [Undecided,Incomplete] https://launchpad.net/bugs/172567
<mwhudson> (or at least, not a very real one)
<lifeless> mwhudson: the branch object will have a longer lock held open
<dato> jam: thanks
<jam> dato: I have a workaround in 1.0rc1
<jam> we are trying to implement the "right fix" for bzr.dev
<dato> ok
<lifeless> jam: ah it did get merged straight to 1.0 ?
<mwhudson> lifeless: oh, well, we'll have the same problem then
<lifeless> jam: good
<jam> lifeless: I believe martin put it in the 1.0 branch
<lifeless> jam: I checked bzr.dev; didn't see it there. I don't know if 1.0's code has the fix or not. And he's off today.
<jam> I'll peek
<lifeless> jam: anyhow, I have a considerably better idea of how to get my point across :). I might write something up about it
<jam> he did a "merge updates for 1.0"
<lifeless> jam: did he? good. :)
<jam> but I'm not sure what that included
<jam> (and, of course, bzr log is slower now :)
<jam> lifeless: it looks like my workaround is *not* in 1.0rc1
<mwhudson> jam, lifeless: so now i'm more confused than i was when i first asked in here :)
<mwhudson> (that i started work 11 hours ago may be related to this)
<jam> mwhudson: so... basically you want to be able to trap when a branch is already locked, peek to see if it was another process that you would have been controlling, and break it automatically when necessary
<mwhudson> jam: yes
<jelmer> bialix: nah, it shouldn't do any network access at all
<jam> interesting, we don't even use the per-branch config username, just the global one...
<jelmer> bialix: what version of windows are you on?
<bialix> xp sp2
<bialix> xp home actually
<lifeless> mwhudson: So, you want to depend on bzr's branch locking, but be willing to ignore it :)
<lifeless> mwhudson: don't we write the pid in the extra metadata?
<jam> when opening a branch
<jam> I would probably monkey patch .lock_write()
<jam> so that it used self.control_files.attempt_lock()
<jam> and if that fails, then you can peek, etc.
<mwhudson> lifeless: not really sure how that helps?
<lifeless> mwhudson: 'when is it safe to break_lock' ?
<lifeless> mwhudson: so you know that all locked branches are from other pullers right?
<jam> mwhudson: when you find a locked branch, you can check the host name, see if it is your current host, and then check to see if the pid is still alive
<lifeless> jam: it has to always be the current host
<jam> if host == 'localhost' and pid is not present (as given by ps, or whatever)
<jam> then you know you have a stale lock
<luks> umm, is there some kind of semantic difference between RevisionSpec.in_branch, in_store and in_history?
<lifeless> jam: the public area is not directly writable by users
<luks> they are all aliases, but I guess each was meant for something different?
<mwhudson> lifeless: well, no not necessarily, sometimes for better or worse operators end up touching branches
<lifeless> mwhudson: on the public side the most operators should do is delete them :)
<mwhudson> lifeless: not going to argue with that
<lifeless> luks: the idea was in_branch -> in the left side history. in_store -> in the repository, in_history -> in the ancestry of the branch. or something.
<mwhudson> lifeless: this complication wasn't my idea :)
<lifeless> luks: overly engineered we suspect
<jam> lifeless, luks: probably true, but I think we only implemented in_store... :)
<mwhudson> maybe the code should just break all locks it finds
<jam> and a lot of code expects in_store ability
<jam> mwhudson: sounds aggressive :)
<lifeless> mwhudson: do you mutex branches against concurrent pullers?
<mwhudson> lifeless: lost my nickserv password i'm afraid, can't pm you here
<jam> I finds 'em, and I breaks 'em
<mwhudson> (until it expires :)
<mwhudson> lifeless: yes
<bialix> jelmer: at work I use win2k sp4
<lifeless> mwhudson: if you mutex them yourself, just do:
<lifeless> if branch.get_physical_status(): branch.break_lock()
<lifeless> unconditionally.
<jam> mwhudson: "get_physical_lock_status()"
<lifeless> you'll need to do something to handle the prompts for y/n that the ui layer will make
<jam> which returns a True or False
<lifeless> break_lock is rather ui centric
<mwhudson> ah, i wrote code to break the locks already somewhere
<mwhudson> though i'm getting the feeling that it may not work with packs
<lifeless> it will
<lifeless> its tested to, *if* you do get a pack repo with a locked pack-names, break-lock will work, as will get_physical_lock_status
<mwhudson> http://paste.ubuntu-nl.org/46736/
<mwhudson> right, what you said will probably work, i was talking about what i wrote last week :)
<lifeless> mwhudson: so, I think if an operator fiddles with these branches, they get what they deserve; if you add more public mirrors it will be impossible for an op to fiddle them all manually.
<lifeless> mwhudson: so being complex here to support oeprators doing the wrong thing; is nutz.
<mwhudson> lifeless: that sounds good and simple
<mwhudson> and like something to do tomorrow
<lifeless> that code will work on packs
<lifeless> its not long term portable
<lifeless> poolie is cleaning up that interface; please file a bug about needing a programmatic break-lock facility\
<lifeless> so that he doesn't shoot you in the feet
<jam> lifeless: how will that not work with packs?
<mwhudson> lifeless: ok
<jam> They also go through control_files
<jam> when the go to "lock_names()"
<lifeless> jam: 06:24 < lifeless> that code will work on packs
<jam> lifeless: oops, bad read on my part
<lifeless> jam: :)
<mwhudson> the _lock stuff was a clue that i was breaking the rules :)
<jam> I'm not sure where I got a "not" in there
<mwhudson> lifeless, jam: strange, i misread it the same way too
<jam> mwhudson: well, it probably won't work for SVN branches
<mwhudson> anyway, it's REALLY time to stop for today
<jam> mwhudson: have a good evening
<mwhudson> jam: i find it moderately hard to care
<mwhudson> :)
<mwhudson> bye all
<lifeless> see in you jan mwhudson
<mwhudson> lifeless: oh right yes, enjoy your time off
<mwhudson> lifeless: after something like one more working week of us both on, we'll be in much closer timezones :)
<mw> if i initialise a repo with bzr init-repo --trees whatever, and then create a branch inside of it based on, say, "cvs checkout -r something_old", what is the best way to then check out something new inside that same repo?
<mw> would it be better to branch that branch i just created, and cvs update to something newer?  or would another direct checkout be the same or better?
<mw> after that point i expect to keep those branches untouched, except for occasinoally cvs updating and bzr committing inside them
<lifeless> mw: 'the same' - no need to do any extra or specific work
<jam> mw: I'm not sure I follow completely, but if doing "another direct checkout" would involve doing a "bzr add" of the whole tree, then I would do 'bzr branch' first.
<mw> maybe i should explain better:  i created a repo, and then inside of that i did a cvs checkout of firefox 1.5.
<mw> that won't be updated much anymore :)
<mw> but i'd like to maintain a "parallel" checkout of firefox 2.0, which of course continues to be updated pretty often
<mw> they share lots of files, so i'd like a) patches for one to apply relatively easily to the other, and also to conserve space
<mw> a) being more important than the unlabeled b)
<jam> mw: then I would do a "bzr branch" first
<jam> actually, since you have a CVS checkout you might try using lightweight checkouts, and switching between branches
<jam> then you can leave the CVS checkout in-place, and just update it pointing at different Bazaar branches / Firefox CVS tags
<jam> the only problem is accidentally committing something to the wrong branch, but you could always bzr uncommit, and fix it
<mw> nod
<mw> i'm not terribly worried about screwing up my pristine branches, since i can uncommit or revert easily enough
<jam> mw: so do you know how to do switch, etc, or do you want some help with that
<jam> vila: isn't there a '-Dtransport' ?
<mw> jam: i don't
<jam> mw: so I would start off with a repository with no working trees
<jam> (bzr init-repo --no-trees repo)
<vila> jam: don't think so, may be you mean the trace+ decorator ?
<jam> and then create a branch underneath there
<jam> bzr init repo/branch-name
<jam> then you create a lightweight checkout pointing at that branch
<mw> jam: hold that thought -- i need to run out for an hour or so
<jam> bzr checkout --lightweight repo/branch-name working
<jam> mw: ok
<jam> vila: does trace+file:/// work?
<jam> I tried "bzr log trace+file:///PWD/" and it gave me the log output
<jam> but no extra data in ~/.bzr.log
<vila> jam: yes, but the collected data are available only in the transport object, what kind of data are you after ?
<jam> vila: to help the guy on the ML who was saying: Branching bzr.dev 'hanging'... no CPU activity, no net IO,	no disk IO...
<lifeless> coffeedude: hi there, how are you going?
<vila> jam: my transportstats plugin may help, but it more love (the decorator approach showed its limits with readv)
<vila> s/but it/but it needs/
<jam> lifeless: you scared him away
<mrZeby> what's new in 1.0 ?
<vila> jam: finally tried the _max_readv_combine for pycurl since we can't get the data as it arrives
<jam> vila: you can, but you need to pass pycurl a custom write function
<jam> which would also mean it doesn't hang forever
<jam> vila: but anyway, how was it?
<vila> jam: how passing a write function will allow me to return from readv ? pycurl will not give me the return code of the request until it returns
<vila> jam: it went nicely but from here the latency is low so I can't really measure the degradation
<jam> vila: http://people.ubuntu.com/~jameinel/test/
<jam> has the branches I gave you
<jam> that is at least in London
<jam> but that may not be far enough for you
<vila> argh, still haven't extracted that repo...
<jam> vila: Also, I believe if you set up a custom write function, you can get the headers
<jam> which means you get the "200 OK" right away.
<vila> --- people.ubuntu.com ping statistics ---
<vila> 6 packets transmitted, 6 received, 0% packet loss, time 5399ms
<vila> rtt min/avg/max/mdev = 19.597/20.679/21.470/0.613 ms
<jam> well, 20ms isn't a lot of overhead
<vila> indeed
<jam> vila: where is your branch, mine is 115.685/145.808/226.214/42.441 ms
<vila> I made my tests with http+urllib://bazaar.launchpad.net/~lifeless/bzr/repository should be the same
<vila> the one that leds to bugs #165061 and children
<ubotu> Launchpad bug 165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Fix released] https://launchpad.net/bugs/165061
<jam> vila: sure, my question is more about where your code is, so I can pull it here and give you some benchmarks
<vila> jam: oh! Just finishing to update NEWS and I'll mail the list with the patch, I can send it to you privately if you want
<jam> vila: if you send it to the list, I can just grab it from there, and let you know
<vila> ok
<vila> I just set it pretty arbitrarily to 25 but I'm not in a good place to judge, anyway it *feels* already better, the pb is alive ;)
<vila> jam: I seem to remember you had a trick under linux to check the peek of memory consumed by a bzr command, I'd like to look at the benefits provided by this new readv in that respect
<jam> vila: I have a "watch_mem.py" script
<jam> which dumps the /proc/PID/status
<jam> well, polls it
<jam> while a child process runs
<jam> I can send it to you
<vila> jam: please do ! thanks
<jam> vila: it should be in the mail
<jam> wow, I just ran into an old project that was in Weave format still
<jam> (it was my 'scripts' catchall project)
<jam> good thing we've kept around at least read support for everything
<vila> jam: in the worst case you just had to checkout an old bzr version...
<jam> true
<jam> I wonder if I have any of the flat-file branches anymore
<jam> I ran into some a couple months back when running "bzr heads"
<vila> jam: not only true, but also a pretty strong argument against people whining about our multiple formats, bzr has now an impressive experience in smooth migrations from one the format to the other
<jam> vila: you may be interested in http://rafb.net/p/JUvJkI89.html
<vila> jam: finishing my mail first ;)
<lifeless> jam: are you going to review vila's patch?
<jam> lifeless: the one he just sent?
<jam> I was giving it a look now
<lifeless> cool
<lifeless> no need for two sets of eyes
<jam> lifeless: did we ever get your comments on the reconcile code (the ones I asked for) merged?
<lifeless> jam: I thought so
<jam> ok
<lifeless> wasn't spiv proxying me for that ?
<dato> what are the chances of getting into core a -u switch to push, that works only for the smart protocol and makes it update a remote tree? I see why it could be rejected (functionality depending on transport), but IMVHO it'd be quite cool to have in core.
<vila> jam: I forgot to mention: http.readv avoid some caching why yielding directly if possible, that may be applied to sftp as well.
<lifeless> dato: how should it handle conflicts?
<lifeless> dato: how will the user resolve them?
<lifeless> dato: will the push fail if there are conflicts?
<dato> warn; ssh; no.
<lifeless> vila: some caching is good if it allows network + python concurrency
<lifeless> dato: and if there are *already* conflicts, will it make them worse?
<dato> plus I think most people that'd be using it would not be editing the remote tree.
<dato> can you pull in a tree with conflicts?
<lifeless> dato: I'm not against it per se; but I think it needs real careful consideration as to UI impact.
<beuno> lifeless, what dato is proposing is actually *exactly* how we work here
<lifeless> beuno: do you use jam's plugin?
<beuno> everybody merges locally, then pushes to the main branch
<beuno> lifeless, I used to, now I just have a cron job updating all repo's every 2-3 minutes
<beuno> ~90 branches at this point
<lifeless> beuno: ok. Merging locally is orthogonal to this though.
<beuno> which is sub-optimal
<beuno> well, we only push changes without conflicts
<lifeless> beuno: if your wt is different to your branch tip; then changes to the branch can conflict with the wt.
<beuno> lifeless, nobody works on the wt, just pushes to it
<beuno> it's always "clean"
<lifeless> beuno: sure. Its still a case for the code to have to handle.
<lifeless> beuno: which is why I asked the questions I asked.
<beuno> :D
<beuno> that's just my +1 for dato's proposal
<jam> vila: you only return if the current string fits the whole buffer, which seems like it would rarely hit
<jam> since usually you have already combined a couple ranges
<lifeless> dato: branches can be updated regardless of the tree's state; thats orthogonal to UI
<jam> oh wait...
<jam> you are buffering everything into a file object first
<jam> and then seeking on that
<vila> lifeless: judging by my perfmeters the concurrency is increased, the network never starves anymore
<lifeless> cool
<vila> jam: RangeFile reads the body of the response on demand so we should process the data as soon as it arrives which means our code don't wait more than needed
<dato> lifeless: er, but pull finally updates the wt.
<dato> lifeless: (sorry, I was lagged)
<lifeless> dato: I'm sorry, I don't get your point then.
<jam> vila: do we know that the offsets will always be in increasing order for _coalesced_offsets... I think we do as we do sorted_offsets = sorted(offsets)... so we should be ok
<vila> jam: yes we do
<dato> lifeless: you asked what happens if you push -u into a remote tree where conflicts already exist. I'm comparing it to pulling in a local tree where conflicts already exist.
<jam> we probably should add a line in the _coalesce_offset function that we expect the (start, length) pairs to be sorted
<vila> what could happen is that the offset are not in the same order as the coalesced offsets, and in that case only we have to cache
<lifeless> dato: I don't think they are equivalent, because bzr:// access does not imply ssh access.
<vila> jam: true, but I reviewed all actual uses and they all sort the offsets before calling (now, that I have said that we can as well sort inside _coalesced_offsets ;-)
<dato> lifeless: the people who edited the remote tree in the first place does have ssh access, and they'd be the one with the responsibility to fix.
<lifeless> vila: hmm, not all readv are sorted
<vila> lifeless: true, I'm talking about _coalesced_offsets callers
<jam> vila: I wouldn't sort, I would just comment on the api that it expects them to be sorted
<lifeless> dato: maybe. Maybe a bug caused the conflict.
<jam> (It won't work anyway if they aren't)
<vila> jam: indeed, so why not sort them ?
<lifeless> dato: but should it be made progressively worse if they are not around?
<jam> vila: because they are already sorted
<jam> and you don't really need to pay to sort a sorted list
<vila> lol
<lifeless> dato: it just seems unfriendly to progressively wedge a tree that the user has no guaranteed access to get at and fix. I don't think it should allow any conflicts ever.
<vila> yeah, right, we better check they are not sorted before sorting them then
<lifeless> uhm
<lifeless> if you mean manually checking, thats slower than sorting anew, in python
<lifeless> bytecode--
<jam> vila: right, much more performing :)
<vila> lifeless: joke man
<jam> lifeless: I'm pretty sure he was being sarcastic
<fullermd> Oh, that's easy to unwedge.  You just use bzr --pretend-you're-in bzr://[...] revert
<dato> lifeless: yeah, if you want to help users not shooting themselves that'd be the thing to do. which I also think that makes sense, since personally I'd only recommend -u for remote trees that are never edited by hand. and in such cases there'll be never conflicts, so... qed/whatever.
<vila> of course, as soon as I made a joke, who's coming ?
<jam> vila: http readv of aa3ab464f867aaa3609bc8ba20f1e342.pack  offsets => 14672 collapsed 6211 ...
<jam> (with my repository, which seems to be significantly less clean than roberts)
<fullermd> vila: It would be quicker to find the last item in the list, then append a random earlier range to it.  Then you'd know it had to be sorted   :p
<lifeless> dato: anyhow, I'm not against the idea of push-to-branch-triggering-update. I *am* against the idea of it ever adding a remote conflict.
<vila> jam: haaa, nice one
<lifeless> dato: so I think a mail to the list, and discussion about policy is a good next step.
<jam> hmm... then later we get: http readv of aa3ab464f867aaa3609bc8ba20f1e342.pack  offsets => 14672 collapsed 20
<lifeless> we've beena round this much before, and the basic issue is always the radical difference between on-my-disk vs remote-disk
<lifeless> jam: revisions + inventories.
<dato> lifeless: ok, noted in my TODO
<jam> lifeless: sure, revisions versus inventories versus texts.
<jam> just interesting that one section is very unclean
<jam> the other is relatively clean
<lifeless> jam: do you have other projects in there?
<jam> lifeless: yep
<jam> just like I do in real life
<lifeless> thats likely it
<jam> sure, I know *why* it is happening, just interesting to see it
<lifeless> cool
<jam> hmm. it still says it is copying inventory texts
<jam> vila: when you were doing "count of data sizes downloaded" was that using your transport stats plugin?
<lifeless> brb; fooding
<vila> jam: yes
<jam> also, shouldn't we not log every readv collapse unless we have -Dhttp ?
<vila> jam: what ?
<jam> vila: do a plain "bzr get" and it will show you every time it does a readv
<jam> and how much it collapsed
<jam> (it was an old bit that I wrote)
<jam> I'm thinking we should probably only mutter() that if " 'http' in debug.debug_flags"
<jam> though I certainly find it useful right now
<vila> jam: ha, ok, I thought you wanted more mutter but you want less
<jam> yeah, double negatives are bad
<vila> in fact there is only one mutter by readv, even if there is several GET requests issued
<jam> hmm... so I currently have 28 pack files, which means that we actually have *more* round trips
<jam> well, probably not for all the text data
<jam> but for the inventories
<jam> we have have a lot of rix round trips
<jam> then a more reasonable .iix round trips
<jam> hmm.... it seems vila's code goes in a slightly different pack order than bzr.dev
<jam> I wonder if he is just missing some of the newer patches
<vila> I had to merge during the patch writing when I hit is_ancestor test failing
<vila> I still wonder how I get a version from bazaar.org that fail to pass the test suite...
<jam> vila: upgrading to packs broke the is_ancestor test
<jam> is_ancestor just used the default format
<jam> packs required the test to lock first
<jam> but other than that, I don't know how you would have gotten a bzr that had the no-lock is_ancestor, but packs set to default
<vila> hmmm, and I realized it only when I ran the full test suite, could be
<jam> vila: and I do have to say, I get to see the blinkenlights
<vila> haaaaaaaaaaa :-)
<jam> that little guy, its spinning just fine
<jam> it has 60s to beat bzr.dev's time
<vila> jam: pycurl or urllib ?
<jam> urllib
<jam> it just made it
<jam> 20s faster
<vila> he he
<jam> 9m40s versus 10m
<Peng> Is it a good idea to run pack reconcile now?
<vila> jam: can you try pycurl too ?
<jam> hmm.... 64MB / 10m == 6.4MB/min or 106 kB/s... I should be able to get 160 or so, but my connection might be in use somewhere
<jam> vila: sure
<jam> I suppose I can install it
<jam> I haven't to date, because I prefer urllib
<vila> really ? Wow, nice suprise ;)
<jam> yeah
<jam> ^C during download is a pretty big downer for pycurl
<jam> but also, I felt I wanted to get away from it anyway
<jam> so might as well dogfood urllib
<jam> I don't think I have it on any machines right now
 * vila <whisper> you can ^C pycurl now, but don't tell anyone ;)
<vila> at least I succesfully did a couple of times now
<jam> vila: just because it downloads in smaller chunks at a time?
<vila> yup
<jam> or can you actually interrupt the data stream
<vila> no, just because the probability is lower to break at bad times now
<jam> well, I'm doing memory dumps as I go, too
<jam> so I'll let you know
<jam> initial reports look good
<jam> (just browsing the memory log file, maybe 20M or so less consumed.)
<vila> so peek mem before/after patch: pycurl: 173M/95M urllib: 131M/85M
<lifeless> nice
<jam> vila: "peak"
<vila> jam: rats
<lifeless> Peng: yes, my fix for it landed in bzr.dev about 20 minutes ago
<jam> I get 120MB versus 99MB VmPeak for urllib
<jam> vila: is that with robert's repository ?
<lifeless> 32/64 bit maybe?
<vila> yeah, still the one from bug #165061, by the way lifeless, do you intent to update it ?
<jam> vila: so pycurl still gives blinkenlights, but more intermittently
<ubotu> Launchpad bug 165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Fix released] https://launchpad.net/bugs/165061
<jam> so you see nothing for a few seconds, then a bunch of updates
<jam> while urllib gives a steady stream of updates
<jam> which is pretty expected
<vila> jam: yes, tweak the 25, I was happy with it, but as I said my latency is low so I can't really be the one to judge
<jam> I think this is about right for my latency
<jam> I still prefer urllib
<lifeless> whats the number mean ?
<jam> but at least it doesn't hang for minutes
<jam> lifeless: number of ranges to collapse
<lifeless> hmm
<lifeless> many ranges are small
<jam> well, on top of that, we have 200 ranges per request
<lifeless> I would rather suggest to do it on the total byte count in the collapsed ranges
<jam> so really it is 200*##
<jam> lifeless: I agree that would probably be better
<lifeless> because its byte count vs latency that the real world operates on
<jam> (raw ranges => collapsed ranges => request)
<lifeless> right
<lifeless> so I'm saying raw ranges => collapsed ranges => byte count filter => requests
<lifeless> or something like that
<lifeless> because
<lifeless> if I ask for a 5MB single text
<jam> at the moment it is "raw ranges => count filter => collapsed ranges => requests"
<mwhudson> ~/src/bzr/173010/bzr branch http+urllib://bzr.arbash-meinel.com/branches/bzr/0.93-dev/extra_range_collapse_165061
<lifeless> should that give no output while it reads ?
<mwhudson> is still taking at least a few minutes to show any ui life
<jam> mwhudson: can you wait a bit to let my tests run?
<lifeless> rofl
<mwhudson> jam: uh, sure
<jam> before my pipe gets killed
<jam> I'm just finishing one
<vila> mwhudson: where the hell did you get that ? :-)
<jam> it should be done in ~ 5min
<mwhudson> vila: your patch on the mailing list
<vila> hehe
<vila> lifeless: I concentrate on the readv implementation, but I noticed that indeed the pb pops up a bit lately
<Peng> lifeless: 3070, "Fix an ordering insertion issue with reconcile of pack ..."?
<lifeless> Peng: yes
<vila> at least 10 requests are issued before it shows up
<Peng> Ohh..
<Peng> I think I already reconciled it a while ago.
<lifeless> then it should be trivial
<vila> before I forget, yes _max_readv_combine generates many coalesced offsets which results in contiguous ranges, so we waste header space here, so lifeless is right that should be reworked
<Peng> It took 35 minutes to check and 1 minute to reconcile then.
<lifeless> vila: more than header space is the latency of issuing new requests.
<lifeless> vila: clocking on the wire is less expensive than going around the world
<vila> lifeless: sure, one more reason to use the header space efficiently to issue less requests
<Peng> fewer
<Peng> </Peng's mom>
<lifeless> lol
<vila> Excusez-moi madame, je ne parle pas tres bien l'anglais, et en plus je n'ai pas les accents pour le francais (ni la cedille pour le c ;)
<lifeless> cedille ?
<lifeless> c'est quoi cedille?
<lifeless> </BAD french>
<vila> cedilla and you french is correct :)
<vila> by the way, keep correcting me
<lifeless> oh, Ã§ ?
<vila> yes
<vila> or \,c C-M-" under emacs >-)
<lifeless> have you set up composing in your gnome keyboard foo?
<lifeless> Ã§ is left-windows+comma c, for me.
<vila> composing is not available everywhere, I make enough typos by constantly using different keyboards, I settled with US layout everywhere and manage to type less and less french outside emacs... :-)
<jam> vila: mabye it was because of mwhudson, but pycurl with your patch was 14m22s
<vila> I have three keyboards here: one Apple, one Dell, one Sun...
<jam> vila: you are right about the extra header stuff, but you also need some granularity so that you can break at appropriate points
<vila> jam: yes, blinkenlights needs more requests so more latency.... told you ! ;-)
<vila> jam: yes, trade off, *my* plan is to drop pycurl ;-)
<lifeless> vila: I have a US keyboard. gnome lets you set the compose key
<jam> lifeless: I understand your point about a single 5MB text... but at the moment we don't really have a way to do progress while downloading
<lifeless> jam: nested_progress_bar().tick()
<Peng> vila: Which is your favorite keyboard?
<vila> lifeless: I know, but I prefer to stay with a simple setup that I can use under Ubuntu, Solaris, Mac OS, windows, etc (including VMs which loves to break that sort of thing), add synergy in the scheme (to use the same keyboards between different X servers and....)
<jam> mwhudson: you can abuse my net connection now
<mwhudson> jam: thanks
<jam> mwhudson: I also have: http://people.ubuntu.com/~jameinel/test/
<mwhudson> jam: i'm only testing the abuse you ask launchpad to give it :)
<vila> Peng: I code therefore I use software designed by people with US keyboards, so having ZXCV (undo/cut/copy/paste) on the same line is a win
<jam> up with a bunch of real branches which is a copy of my working repo
<jam> mwhudson: yeah, except LP only does that 1 time, and then at least quiets down afterwards
<jam> though I do notice in my server logs
<mwhudson> jam: expect not at the moment
<jam> that I get a whole lot of 404's from LP
<mwhudson> https://code.edge.launchpad.net/~jameinel/bzr/extra-range-collapse-165061
<mwhudson> because it takes over 15 minutes for the progress bar to appear
<jam> mwhudson: why is LP failing on that branch?
<jam> do you have any idea?
<mwhudson> jam: yes
<jam> oh, the LP branch is locked
<vila> then having {} just above [] and () all easily accessible are far better than french layout (and don't talk about windows where { is something like alt-156 or whatever)
<mwhudson> jam: that's just a symptom
<mwhudson> jam: the real problem is that i landed a branch that kills the puller worker if there is no progress bar activity for 15 minutes
<jam> ah
<jam> hmm....
<jam> mwhudson: well, that branch is in knit format
<mwhudson> because we've had problems with pullers getting stuck for days
<jam> so it is downloading most/all of inventory.knit
<jam> before it does much
<mwhudson> jam: to some extent
<mwhudson> jam: i'm not interested in your excuses :)
 * vila calling it a day
<vila> night all
<lifeless> gnight
<jam> It is about 25MB at 30KB/s...
<jam> vila: night
<jam> which is 14 minutes
<mwhudson> it's still bad for bzr to show no activity at all for 25 minutes or however long it will take
<jam> 13.9
<lifeless> mwhudson: preaching. Choir.
<jam> mwhudson: oh, I'm not saying it isn't bad form for bazaar to act that way
<lifeless> mwhudson: hear the angels?
<jam> vila's change will do a lot for that
<mwhudson> lifeless: yes, they're singing "give it up for today"
<jam> mwhudson: I thought you gave it up about 3 hours ago
<mwhudson> jam: that's why i'm testing vila's change
<mwhudson> jam: i should have done
<jam> packs will help a lot, too, as they copy in a different fashion that gives better progress anyway
<jam> I'm just being stodgy on my public repo
<jam> and forcibly testing pack => knit stuff
<jam> mwhudson: I did notice a lot of 404 in the server logs, every time LP tries to mirror a branch and finds it is in a shared repo
<lifeless> which is good
<mwhudson> jam: launchpad just does branch.pull()
<jam> well, it might be nice if it could check Branch.last_revision() and see that it has not changed without doing any more work
<jam> mwhudson: sure, I know why
<mwhudson> jam: little chance for funny business here
<lifeless> jam: opening the branch finds the repo
<jam> lifeless: the way our code is written, yes, it wouldn't *have* to
<jam> I don't really mind
<jam> I just don't read the server logs
<lifeless> jam: I really think it should stay the samme
<jam> mwhudson: Did the puller get updated, it seems to mirror 5x per day now
<jam> lifeless: I think having WT act differently based on what repo it is connected to is a layering violation... and we shouldn't have to poll everything when we only need 1 bit of info
<jam> but it isn't critical to me
<lifeless> jam: I agree about the layering violation, that's a compromise (everyone is unhappy), but; I think the knowledge that the stack is good is valuable.
<mwhudson> jam: 4x is the defaul
<mwhudson> t
<jam> I just get to see this in my logs: http://rafb.net/p/gHjqDX47.html
<mwhudson> and has been for ages and ages, afaik
<lifeless> much better than operating on something for X time and *then* finding out it's corrupt.
<jam> mwhudson: ok, I just see 5 queries
<jam> I used to see 1, IIRC
<jam> I haven't looked at it in quite a while
<mwhudson> probably since before i started :)
<jam> what I really need to do is update all of those to Branch6 format
<jam> so it doesn't have to download the full revision-history file each time
<mwhudson> my pull against jam's repo is spinning the bar now
<mwhudson> didn't notice when it started though
<mwhudson> pretty sure it's quicker than without vila's patch though
<Peng> Hey, it's been more than 1 minute since I started reconcile.
<vila> lifeless: one last thing, regarding obsolete-packs, what about replacing [t.remove(f) for f in t.list_dir('obsolete-packs')] by t.remove_tree('obso-packs'); t.mkdir('obso-packs') ?
<lifeless> vila: race conditions FTW
<jam> wow, 279 Branch5 branches...
<vila> don't you have more race conditions with a listdir ?
<jam> vila: race conditions, and permission issues
<jam> vila: you don't have anyone who will try to rename a file into a missing directory
<jam> versus having a file that was deleted for you
<jam> or missing a file that showed up
<jam> (which we don't really care about anyway)
<vila> jam: permission issues I understand but what race conditions, isn't the repo locked ?
<jam> vila: no it isn't
<vila> ha, ok
<jam> you only have to lock while updating pack-names
<jam> once you've updated that
<jam> nobody will try to access the packs you are moving
<vila> ok, thks
<vila> bye ;-)
<jam> vila: kthxbye
<jam> You really need to work on your spelling
<jam> :)
<jam> hmm... upgrading to branch6 saved me about 30MB
<n[ate]vw> jam: I'm wondering if any decisions have been made yet regarding handling Unicode normalizations?
<jam> no new decisions
<jam> I don't think it was discussed much recently
<jam> we've got a lot of other stuff on our plate
<jam> n[ate]vw: if you want to start up a discussion, you are welcome too
<jam> I sort of burned out on trying to make everything work
<jam> as I seemed to be the only person who cared...
<jam> well, that, and it would always break for someone
<n[ate]vw> yeah, understood
<jam> I felt that penalizing Windows/Linux users because Mac likes to change filenamse
<jam> filenames, was a bit sadistic
<n[ate]vw> jam: I'm still very much just a user at this point, but I have read up on Unicode a bit
<n[ate]vw> I'm still kinda trying to pick between bzr/hg
<jam> n[ate]vw: did you try my patch?
<jam> It would be pretty easy to get that merged in
<jam> so at least it would let a single platform stay compatible with itself
<jam> even if branching from Unix => Mac might break stuff
<jam> (well, filenames would show up as missing, etc)
<jam> we recently merged some code which helps with the case insensitivity problems
<lifeless> spiv, jam, igc call in 5
<n[ate]vw> jam: I haven't tried the patch, not much of a python hacker. do I apply that to the "source" tarball d/l, or can it apply straight to the installed bzr "excectuble" in bin?
<jam> n[ate]vw: probably recommended to go for the source
<jam> you probably could apply it to the library in
<jam>  /usr/lib/python2.4/site-packages/bzrlib/*
<dato> hm, I'm also noticing pull being much cpu-intensive now, at least pull -v
<jam> but I would probably recommend running from source if possible
<n[ate]vw> np, the source is fine
<jam> n[ate]vw: also, you can run bzr directly from source (without installing)
<n[ate]vw> looks like there's a new rc out since I was testing it last
<jam> just run 'make' so you get extensions built
<jam> (if you don't, it will still run, but just slower)
<igc> morning
<n[ate]vw> that's good to know
<n[ate]vw> jam: I just read an interesting article by Drew Thaler on case sensitivity, and he happened to defend OS X's normalization in the comments: http://drewthaler.blogspot.com/2007/12/case-against-insensitivity.html#comment-2279674399335241896
<jam> n[ate]vw: I understand (in theory) why normalization is the "right thing" but because nobody else does it
<jam> it just means yours is the only platform which breaks stuff
<n[ate]vw> yeah, and it looks as though you guys are trying to push 1.0 out the door so I don't want to harass you about this at the moment
<n[ate]vw> it'd be nice to see a good cross-platform solution eventually, but I understand it's a tough nut to crack
<jam> lifeless: conference call ?
<logankoester> What package do I have to install to get the "bzr" command on my system?
<lifeless> jam: yes, distracted by code.
<logankoester> I have bazaar
<lifeless> bzr
<lifeless> logankoester: ^
<lifeless> igc: conf call time if you are not already in
<logankoester> heh
<igc> in
<logankoester> thanks ;)
<jam> n[ate]vw: well, the small patch I gave you might be a simple thing to get into 1.0
<jam> code-wise it is nice and small
<jam> politics wise, a bit more involved
<jam> But as I was the one who spent an irrational amount of time trying to get it all working in the first place.
<abentley> vila: pong
<n[ate]vw> jam: I will try to test that patch tonight after work (unless work continues to be waiting on others, in which case sooner!) and post my results to the ticket
<abentley> lifeless: Should I be merging my 1.0 patches into bzr.dev?
<abentley> lifeless: Conflict detection is done before the merge is applied, so it would be possible to error out if push would trigger conflicts.
<Peng> Reconcile finished in 20 minutes.
 * Peng wanders off.
#bzr 2007-12-04
<lifeless> jam: ping
<lifeless> abentley: re smart server conflicts - good;
<lifeless> abentley: I don't know re: 1.0 -> .dev, what patches are they ?
<abentley> 1. the plan merge thing you reviewed  2. The warning for criss-cross. + docs
<lifeless> yeah merge those to .dev
<lifeless> and I'd mail martin once they land with revnos to merge to 1.0
<lifeless> .dev is open AFAIK
<abentley> Yeah, it's just more complicated later if we merge 1.0 into dev.
<abentley> And it reduces the visibility of the merge requests for Martin.
<lifeless> OTOH once they are in .dev they get experiential testing, and he can run 'missing bzr.dev;
<abentley> jam: ping
<jkakar> Does anyone know when bzrtools is expected in the Bazaar repositories for gutsy?
<jkakar> As a suggestion, it would be very appreciated if bzr and bzrtools were released in tandem.  I know that creates more work, but it's disturbing to lose often-used commands for hours or days at release times.
<lifeless> jkakar: its already there isn't it ?
<lifeless> jkakar: http://bazaar-vcs.org/releases/debs/gutsy/ has bzrtools 1.0.0
<jkakar> lifeless: I keep getting 'bzrtools: Depends: bzr (< 0.93~) but 1.0~rc1-3bazaar1 is to be installed' after fresh apt-get updates.
<lifeless> ah, will fix.
<lifeless> I hate this strict versioning; its bogus.
<jam> lifeless, abentley : pong
<jkakar> lifeless: Thanks!
<thumper> he bazaar dudes
<thumper> I have some fella saying that bzr doesn't have GUIs (on windows)
<thumper> what do we have?
<thumper> links would be good
<thumper> s/he/hey/
 * thumper needs to check more before pressing enter
<jam> bzr-gtk
<jam> works on Windows
<jam> TortoiseBzr is at least in the works
<thumper> jam: is it any good
<jam> I know it "works"
<jam> but I haven't used it myself
<thumper> jam: eta on TortoiseBzr ?
<fullermd> AFAIK, both -gtk and qbzr work OK, but are also both pretty manual to install and not as comprehensive as one would like.
<thumper> fullermd: is qbzr able to work on windows?
<jam> thumper: it should be
<fullermd> That's what I understand from snooping on list/IRC discussions.
<jam> You just need the QT 4 libs
<thumper> how's the eclipse plugin?
<jam> but there should be GPL QT 4 libs for windows
<thumper> usable?
<jam> thumper: a lot of active development recently
<lifeless> jam: pong
<jam> Verterok: thumper wants to know about bzr-eclipse
<jam> lifeless: hey, just getting some family time before they sleep
<thumper> who's working on TortoiseBzr ?
<jam> do you want to talk by phone?
<jam> thumper: it is part of the bzr-gtk package, so jelmer is at least aware of it
<jam> I believe it was a google SoC thing
<abentley> jam: I was thinking of working on a pack format using mpdiffs, but I got the impression you're going to do xdelta packs.
<jam> but I can't remember his name off-hand
<lifeless> jam: now is good
<abentley> I don't want to duplicate the effort.
<jam> lifeless: do you want by phone or by skype?
<lifeless> skype
<abentley> jam: Alexander Haro was working on TortoiseBzr
<jam> lifeless: logging on now
<jam> abentley: did he have an IRC nick?
<abentley> I don't remember.
<jam> abentley: talking with robert, will ping when done
<abentley> 'kay
<jelmer> tortoisebzr is not actually part of bzr-gtk, nautilusbzr is
<jelmer> tortoisebzr was somewhat of a fork of bzr-gtk though
<jam> abentley: back
<abentley> Hey.
<jam> so I certainly have some ideas of how to get there, but there are several steps to be done before we can really have an "optimal" pack layout
<jam> like, just getting the non-redundant index data put into the real data
<Odd_Bloke> What's the plan for 1.n versioning?  Will 1.0.n releases go on until a certain set of features are complete and then the next version will be declared 1.(n+1)?
<jam> (the fact that this is a delta versus a fulltext, eol, compression parent, etc are all *only* in the index)
<jam> Odd_Bloke: well, Martin posted 1.1 in January
<abentley> Oh, I get what you mean.  Making the index be redundant data.
<jam> which would hint at continuing the 1.(n+1) we have now
<Odd_Bloke> Ah yeah, I recall now you mention it.
<jam> abentley: right, that is one of the steps
<jam> also, in talking with Robert, a good intermediate is to allow pack repos to mix their deltas
 * Odd_Bloke returns to House.
<jam> since as you commit you really only generate deltas from previous
<abentley> Err, really?
<jam> but after repacking you would probably want to generate reversed ones
<abentley> what do you mean by mix?  Different formats?
<jam> xdelta & knit deltas co-mingled was an idea
<jam> partly because when you commit
<jam> we would like a knob to turn on annotation building at commit time
<jam> and for that, we would need to generate some form of line-delta
<jam> which would be a shame to waste
<jam> and do 2 deltas at commit time
<jam> it might be okay
<jam> but it is something to think about
<abentley> Yes.
<jam> Also, it would make it a lot easier to phase in a change
<lifeless> spiv: ping; whats the bug regarding your web proxy?
<abentley> Another thing I've talked about is having a comparison cache.
<jam> if it had a way to migrate without spending 40-hours reformatting the data
<jam> abentley: well, we would probably have that, and fill it at commit time
<abentley> But with the C-optimized sequence matcher, comparisons are far less expensive.
<jam> if the knob was turned on
<abentley> So we seem to do fine without it.
<jam> abentley: even for whole-file annotate
<jam> gannotate is pretty slow last I checked
<jam> but I haven't tried your new stuff
<abentley> My new stuff is just for merging.
<abentley> But I was talking about a comparison cache, not annotation cache.  We definitely need cached annotations.
<jam> abentley: couldn't you use the comparison for annotation data?
<jam> or I guess that has too small a view?
<abentley> Well, we already are using cached comparisions about 3/4 of the time.
<jam> (1 text to 1 previous text, not the full history for that file)
<abentley> I think you can't annotate to the origin everytime and expect good performance.
<jam> srue
<jam> sure
<jam> 10k to the origin is a long way to go
<jam> what if the annotation cache was the 'fulltexts' and the rest was comparison cached
<jam> just as a thought
<jam> also, what is the overhead of doing an actual delta, versus the I/O of reading it in from a cache
<jam> I seem to remember there wasn't much of a win depending on the circumstances
<abentley> Yeah, right now I haven't seen a huge win for cached comparisions.
<jam> I suppose it also depends if you have to extract the texts as well
<abentley> I think we should start with cached annotations.
<jam> if you don't have the I/O of getting the full text
<jam> you wouldn't have the texts around to do a memory comparison
<abentley> Yes, that does tend to negate the IO win of doing a comparision from scratch.
<jam> so, the very first step for any of this
<jam> is that we should merge in a truly experimental format
<jam> into bzr.dev
<jam> so that it can be played with
<jam> we could do it all in a feature branch
<jam> but those tend to rot a lot more than a bzr.dev branch
<abentley> I think that's okay with me.
<abentley> So what I'm interested in is implementing iter_files_bytes in a way that it can read everything in a single pass.
<jam> so... iter_files_bytes, you're thinking of that for TT, and build_tree, right?
<abentley> That means writing a new revision builder, which is affected by the delta format.
<jam> which means that you will tend to want only 1 version for a given file-id
<abentley> Well, also operations that use a lot of different revisions of a file.
<jam> but you will want lots of file ids
<jam> diff is the only other one that comes to mind for wanting multiple versions of a file
<jam> and that is only 2 versions per file-id
<jam> I guess annotate...
<jam> but we would like to not have to do that as much from a raw iter_files_bytes point of viwe
<abentley> And simple revision fetching.
<jam> view
<jam> abentley: but would you want to fetch as full texts?
<abentley> iter_files_bytes returns an iterable.
<abentley> So you can certainly take advantage of common lines.
<jam> abentley: right, but wouldn't you want to fetch the deltas, etc, not the full text each time?
<abentley> For annotate?
<abentley> Oh, for installing revisions.
<jam> abentley: not for annotate... for "simple revision fetching"
<abentley> For simple revision fetching, you assume the repos have incompatible delta formats.
<abentley> Like that fetch code you wrote recently.
<jam> interesting, I'm curious how things would be buffered
<jam> it does seem like *most* use cases are across a revision
<abentley> Oh, probably using that handy LRU of yours.
<jam> not across a file's history
<abentley> True.  But I think the abstraction of just asking for a bunch of keys, not caring whether they're from the same file, is pretty nice.
<Verterok> moin
<jam> abentley: oh, I agree. I believe in moving away from VF as a concept, to putting more of that on Repo
<Verterok> jam, thumper: hi
<jam> hi Verterok
<jam> how is bzr-eclipse going?
<jam> is it in a "useable day-to-day" or still more experimental?
<Verterok> it's not feature complete, but sure it's usable in a day to day basis.
<lifeless> jkakar: uploading now
<Verterok> jam, thumper: I recently write a draft of the roadmap at http://bazaar-vcs.org/BzrEclipse/Roadmap
<spiv> lifeless: my proxy bug is 172701
<thumper> Verterok: thanks
<Verterok> np
<jkakar> lifeless: Ta!
<Verterok> thumper: I'll be around, shoot any questions that might araise :)
<thumper> Verterok: so were are we now with bzr-eclipse?
<Verterok> in which aspect? (integration with bazaar? integration with eclipse?)
<Verterok> thumper: about the  java-bazaar integration, almost all relevant commands have a counterpart in the BazaarClient java library
<jam> abentley: another small thing, I'm looking at the Mine page, and it seems to list some things that I've merged.
<jam> like http://bundlebuggy.aaronbentley.com/request/%3C20071130201555.3F94855FFA@juju.arbash-meinel.com%3E
<jam> Have you not updated from bzr.dev in a while?
<jam> I was trying to clear out accepted but unmerged things
<abentley> I've seen that too.
<jam> but my list isn't reflecting it
<abentley> I know it is doing the right thing some of the time.
<Verterok> thumper: I'm still waiting for jython 2.5 :P
<abentley> But sometimes it seems to missing things.
<jam> Verterok: what happened with the JEPP (etc) wrapper for bzrlib?
<jam> I know it happened for a Mono/.NET port
<jam> as part of the Visual Studio integration
<abentley> This is likely because I switched that operation to be internal.
<abentley> But I'm not getting any failure reports or anything.
<jam> k, it just would be easier for me if i could look at the list of things I haven't merged yet
<jam> I can do it manually
<jam> but I didn't want to step on anything
<jam> in case you wanted to use it as a test case
<abentley> No, please go ahead.
<abentley> I'm aware of the problem.  Sorry for the inconvenience.
<jam> abentley: could it be that the tip wasn't merged?
<jam> I committed another rev on top of it and merged that
<Verterok> jam: about jepp, I played a bit but it seems too complex to install from the user perspective, the CLI wrapper is a bit slower but works fine and only requires xmloutput plugin
<abentley> It shouldn't be that, but I think my test cases are against the tip.
<Verterok> jam: also jepp requires a LOT of work to get a usable interface, and jython 2.5 is comming (they have a new compiler that understand cpython bytecode ;) )
<jam> Verterok: good to hear
<jam> last I tried jython it was pretty limited
<jam> It is a shame we probably won't ever get the bzrlib test suite to run there
<jam> as we use 'os.chdir()' a lot to ensure each test is sandboxed
<jam> (afaik, we use it 0 times in actual bzrlib code, but the test suite uses it a lot)
<Verterok> sure it's a shame, maybe when time of jython 2.5 comes, I can put some work to make a custom os.chdir as a native jython module
<jam> I thought it wasn't allowed because of Java limitations
<Odd_Bloke> JNI could do something I would've thought...
<Verterok> you'r right, I was thinking in a workaround and not a real fix to jython :D
<Verterok> just to make the bzrlib test suite run
<thumper> Verterok: I was meaning 0.1? 0.2? on your roadmap
<Verterok> thumper: oh, ok. I'm currently working in the quickdiff integration
<thumper> k
<Verterok> the next thing to do is basic merge support and conflict resolution with the strutctured merge, and with this working I plan to make a new build
<Verterok> s/strutctured merge/strutctured diff/
<spiv> lifeless: call?
<ubotu> New bug: #173807 in bzr "Branching from RepositoryFormat7 standalone branch from a smartserver fails" [Undecided,New] https://launchpad.net/bugs/173807
<lifeless> spiv: yup
<spiv> lifeless: ok, will call in a sec
<lifeless> kk
<edencane> Hi
<edencane> I have a question about bzr versions
<edencane> ...
<edencane> Anyone?
<lifeless> sure
<edencane> Ok. I've got ubuntu 7.10 want to install bzr
<echo-area> hello, I branched bzr's main repository, and after that, I need to take 2+ hours to update my repository (getting 200+ MB at 30 kB/s for a 80 MB repository), is this normal?
<echo-area> thanks
<lifeless> echo-area: thats not normal; our repository is only 50 mb total.
<lifeless> echo-area: and updates should be a few seconds or a minute at most
<lifeless> edencane: please, ask your question
<edencane> Thanks.
<echo-area> hmmm, what could be possible wrong in my case?
<fullermd> lifeless: Actually, my bzr repo is about 75 meg.  It's got a handful of my revs in it, but they can't add up to 100k.
<fullermd> echo-area: When did you branch it?
<lifeless> fullermd: oh hmm, I'm considering core data.
<echo-area> around Nov 20 I think
<edencane> latest release is 0.92, yet when I add the repository to sources.list for use with aptitude, the available version is 1.0.0.candidate.1
<lifeless> echo-area: ah, perhaps you missed the announcement that I sent out that bzr.dev is now in pack format.
<edencane> Ive installed that version
<fullermd> echo-area: Ah.  Try a 'bzr info' of your branch; I'll bet it'll say 'dirstate' for the format, and is trying to pull the new pack'd bzr.dev.
<lifeless> echo-area: you should: let the current pull finish. Then 'bzr reconcile' and then 'bzr upgrade', using the bzr in the branch itself.
<echo-area> OK thanks guys :)
<lifeless> edencane: yup
<edencane> So whats the deal with different version numbers
<edencane> ?
<lifeless> edencane: we're getting ready to release 1.0
<edencane> Ok, great!
<edencane> congrats
<edencane> If I use 1.0 on a branch thats being used with 0,92 by other developers, will that cause inconsistencies?
<lifeless> edencane: no, it will be fine.
<lifeless> edencane: the main difference is that 1.0 will be default create new branches in 'packs' format. This is faster, but not supported on < 0.92, and not as well supported on 0.92 as in 1.0.
<edencane> will that impact on doing a pushes and pulls or creating new branches?
<spiv> edencane: when pushing or pulling a branch to a new location, so bzr needs to make a new copy, bzr will make that in the same format as the original.
<spiv> edencane: so it should work just fine.
<edencane> so if I push changes with 1.0 and theother pulls those changes we'll be fine?
<spiv> edencane: 0.92 users will want to upgrade to 1.0 anyway, because of the bugfixes and optimisations ;)
<spiv> edencane: right
<edencane> Cooool
<edencane> Thanks so much guys. That was great help, Best with the new release and cheers for an overall great product (-:
<chiefinnovator> how do I back up bazaar?
<beuno> chiefinnovator, all the information is stored in the .bzr directory
<chiefinnovator> But it looks too small to be holding everything
<Peng> chiefinnovator: Unless you're using a lightweight checkout, it is holding everything.
<beuno> chiefinnovator, are you sure all your files are versioned?
<chiefinnovator> well, I had a directory of existing files
<chiefinnovator> and I did bzr init
<chiefinnovator> and bzr add
<beuno> chiefinnovator, and commit?
<chiefinnovator> ohhh
<beuno> :D
<chiefinnovator> Yeah, that's better
<chiefinnovator> thanks
<chiefinnovator> So anything I do some work, I just do a commit when I'm done?
<chiefinnovator> I'm just using it to track my own files
<chiefinnovator> anytime*
<Peng> Okay, running reconcile on bzr.dev made it go from 49 to 0 unreferenced text versions, and it used to say 108 inconsistent parents and now says nothing.
<echo-area> fullermd: Sorry but where can I find your announcement?  Is it in https://lists.ubuntu.com/archives/bazaar/2007q4/thread.html ?  Thanks
<Peng> Still 2 ghost revisions and 2 revisions missing parents.
<beuno> chiefinnovator, yeap, just commit when you're done
<beuno> remember, commiting is cheap with bzr, so you can be very granular about what you do
<beuno> you will have a more useful history and easier to rollback
<chiefinnovator> how do I rollback?
<fullermd> echo-area: I think you mean lifeless, not me.  Check Nov 28th, if you mean the announcement I think...
<edencane> Doing a bzr status on with 1.0 on 0.92 tree, If I do a bzr upgrade, will that affect the operation of another developer who is still using 0.92?
<beuno> chiefinnovator, there are several ways, bzr uncommit (undo last commit) bzr revert (to a specific revision if you like), or bzr cat (to a specific file in a specific revision)
<echo-area> Oh, thanks
<chiefinnovator> thanks
<Peng> edencane: Well, there are some issues with packs in 0.92. He should really upgrade.
<abentley> jam: is it intentional that the C version of Patience only allows strings?
<edencane> Thanks peng
<Peng> edencane: (No data loss or anything, but "bzr cat" fails and so does pushing over bzr+ssh, and some other things are slow (which aren't all sped up in 1.0rc1).)
<edencane> Ok.
<edencane> Thanks again.
<spiv> Peng: cool, that sounds like reconcile is working as expected for you.
<Peng> spiv: Okay.
<Peng> Urrgh. I shouldn't run "bzr check" before and after to see what reconcile does. It takes 5x as long.
<Peng> Or 4x. I dunno.
<Peng> check takes about 2x as long, and I do it twice . .
<lifeless> check does more :)
<lifeless> okies
 * lifeless waves
<igc> see ya lifeless
<Peng> If reconcile doesn't find anything to do, the repo is left unmodified?
<spiv> Peng: yeah, it should be.
<Peng> Okies.
<Peng> Hey, I have a .pack that is 1024.0 KB. Nice.
<Peng> 1,048,531 bytes, with 1 MB being 576. :)
 * igc lunch
<Peng> jelmer: FWIW, running reconcile on bzr-svn fixes some inconsistent parents.
<Peng> I wonder, would running reconcile over sftp be any faster than just uploading a new copy of the repo (I have a reconciled copy on my PC)?
<fullermd> Peng: My Magic 8-Ball considers it unlikely.
<fullermd> (based on no real knowledge; just guessing)
<spiv> I would expect reconcile over sftp to be pretty slow.
<spiv> I haven't measured, but I don't think that code is written to minimise round-trips.
<lifeless> i386: hi
<lifeless> when do you return ?>
<i386> 11th :)
<i386> still up for doing dinner?
<lifeless> ya'
<lifeless> on leave now
<i386> oh right
<i386> :)
<i386> Im leaving Seattle tomorrow morning
<i386> its a bit of a shit hole
<i386> lifeless: how long are you on leave for?
 * igc dinner
<jelmer> Peng: thanks
<jam-laptop> abentley: I don't think it is a requirement that the C version work only on strings
<jam-laptop> My guess is that strings were the most important
<jam-laptop> I wouldn't want to see it slow down much, but I could certainly see supporting tuples
<jam-laptop> would be nice for annotated texts
<jam-laptop> It is nice to have a simple "compare_lines" function that can use something fast like "memcmp"
<jam-laptop> we could experiment with using "PyObject_Hash()" instead of a custom hash func
<jam-laptop> and maybe PyObject_Compare
<theSoftMan> hello all.. i am looking for some QBZR screenshots on windows systems...
<luks> theSoftMan, http://bazaar-vcs.org/QBzr has some, but they are from old versions
<luks> it easier to just install it :)
<luks> it's
<theSoftMan> i have try ti install but it does not work :-)
<luks> file a bug report
<luks> theSoftMan, http://users.musicbrainz.org/~luks/tmp/qbzr.png this is a screenshot of the dev version
<luks> theSoftMan, what exactly didn't work for you?
<theSoftMan> luks, when i lauch bzr a message appear to said that some modules are not found
<theSoftMan> luks, i try to define some path variable but qbzr never start
<theSoftMan> luks,
<luks> bzr 0.92 and qbzr 0.7.1?
<theSoftMan> luks yes sir :-)
<luks> both installer using the windows installers?
<luks> *installed
<luks> that is, the bzr.exe one
<luks> if you use your own python, you have to install pyqt4
<luks> if you use bzr.exe, everything should be included in the installer
<jam-laptop> abentley: I think I put together a patch to make it allow generic objects, (as long as they are hashable), I'll clean it up and post it to the list.
<theSoftMan> luks, sorry i was disonnected... yes i use my one python installation 2.5
<theSoftMan> luks, i will try to install pyqt4
<theSoftMan> luks, thanks
<theSoftMan> one more question : the 1.0 will be ok in hom many times ? in your humble opinion :-)
<eschava> Hi guys. Could you suggest correct way to solve text conflicts using bzr-gtk ?
<ubotu> New bug: #173941 in bzr "hard to programmatically break a lock" [Undecided,New] https://launchpad.net/bugs/173941
<ubotu> New bug: #173944 in bzr "adding files below symlink causes error" [Undecided,New] https://launchpad.net/bugs/173944
<jam-laptop> vila: ping
<jam> I'm fixing the nick for once and all, bbiab
<jam> vila: ping again
<vila> pong
<jam> hi vila, how is it going?
<jam> I was wondering if you were going to be extra busy this week
<jam> or if you would have time to work on your patch
<vila> pretty nicely, new project starting, may be fun :)
<vila> I will be extra busy, but I already take your remarks into account
<vila> Hmmm, Did I sent the email or did I just made the commit ? Let me check
<jam> Is this the one that you had to speculate your bug fixing effectiveness for the next 12 months?
<jam> I saw the commit email, I guess
<vila> yup
<jam> so did you go with 10 as I mentioned ?
<vila> hmmm, I think we went with 3/months ;-)
<vila> but given the subject (argh, NDA), well, bugs can be pretty hard
<vila> so it's still a bit stupid, but at least I get a mention added: "Any bug will first diagnosed before an evaluation is made for fixing"
<jam> vila: no problem, what is your feeling on your changes for 1.0?
<jam> I'd really like them, do you feel like it is logically small enough to do so?
<vila> jam: just sent the email, I agree some real life testing should be good, but since we are still in RC, I pretty confident
<vila> basically I went TDD on that one and the test suite was a real pleasure
<vila> granted I had to rewrite most of the RangeFile tests, but that was pretty obvious.
<vila> Once *that was done, I get pnlu trivial bugs and typos (of course) to fix.
<vila> s/pnlu/only/
<vila> hehe
<fullermd> Somebody, help!  The irony is choking me!
<vila> I just can't type about typos without doing at least one, and when I don't it's bad english
<vila> Anyway, once the test suite passed, I had a bad surprise since our http tests servers are all speaking http/1.0, not 1.1, but that was a good thing finally since I ended up handling the http pipe even more cleanly that I was hoping
<vila> jam: bbl. early dinner time
<jam> vila: enjoy your food
<somerville32> Are there any branch commit notification bots?
<jam> somerville32: well, Launchpad will let you subscribe to branches.
<jam> There is an atom-feed plugin
<jam> there is bzr-email to send a message after commit
<jam> but if you just want to poll a bunch of branches, and send emails when they change...
<jam> I think there was something for that
<fullermd> It was called 'hookless mail' or something like that.
<dato> launchpad.net/bzr-hookless-email
<somerville32> I host it on launchpad though
<somerville32> So I'll just need a bot to parse the e-mails?
<somerville32> Preferably, I'd like a bot that polls the branches and just sends a message to my channel (and preferably I'd like it already coded, haha)
<jam> fullermd, dato: should bzr-hookless-email be listed on http://bazaar-vcs.org/BzrPlugins?
<jam> somerville32: I know there is also a dbus plugin, which is meant to alert the local network when there are changes
<jam> And lifeless was looking into an irc-notify plugin
<jam> but was hesitant to finish that before he had a way to make it scale well
<dato> somerville32: there is bzr-cia, but all people who commit there should install it themselves for it to be useful.
<jam> (1000s of people announcing all there changes would get *really* noisy.)
<fullermd> jam: No clue.  I just work her...   well, actually, I don't...
<jam> you work him ?
<fullermd> Only on weekends and special occasions.
<jam> (bad choice of ellipsis)
<dato> hehe
<fullermd> (available for birthdays and bar mitzvahs by prior arrangement)
<jam> hmm... it seems like bzr-hookless-email isn't strictly a plugin, as it provides its own 'main()' function.
<somerville32> Is there a python module for interacting with bazaar-vcs?
<fullermd> It strikes me more as a 'helper script' than a 'plugin' per se.
<jam> somerville32: if you install 'bzr' then you get 'bzrlib' in python
<jam> fullermd: but we certainly should link to it from bazaar-vcs.org somewhere
<dato> jam: yes, it's an external watcher
<jam> as people would want the functionality
<dato> jam: which I sorely needed
<fullermd> Probably, yah.
<jam> dato: do you have it linked anywhere?
<dato> nope; maybe I can add it to a subsection of BzrPlugins
<dato> and maybe could be extended to perform random actions on branch updates
<dato> like, with a plugin sistem O:-)
<dato> actually, it would be interesting to have it running actual bzr hooks (email, cia, dbus) on the server
<dato> 0 code duplication, etc. I wonder why I didn't think of that before
<jam> dato: if you said something, I missed the last couple of messages, last I saw was "plugin system"
<dato> 18:51 <dato> and maybe could be extended to perform random actions on branch updates
<dato> 18:51 <dato> like, with a plugin sistem O:-)
<dato> 18:52 <dato> actually, it would be interesting to have it running actual bzr hooks (email, cia, dbus) on the server
<dato> 18:52 <dato> 0 code duplication, etc. I wonder why I didn't think of that before
<dato> how does that sound?
<jam> so, one thing you could do, is change some of those plugins to hook into 'post-pull'
<jam> and then just have them installed on the server
<jam> so that when you 'bzr pull' into the mirror branches
<jam> it sends notifications
<jam> as an idea, at least.
<dato> pulling into what, when?
<dato> the use case was notification for branches where people were pushing to
<dato> where these people don't have bzr-email etc. installed or configured, or you can't rely on them doing so
<jam> dato: so you mirror them ... :)
<jam> or hook into post-push, and get that working for the bzr+ssh stuff
<jam> I have tested that post-push doesn't fire (at the moment) over bzr+ssh
<dato> well, I like watching the live branches in the server better, with inotify and stuff. it's very responsive in that case.
<abentle1> jam: Bundle Buggy is working for me now, and I'm finished messing around with it.  Is it still down for you?
<jam> abentley: It seems to be up for me
<jkakar> lifeless: FYI, the bzrtools package is still not upgradeable.  It's failing in the same way it did yesterday: bzrtools: Depends: bzr (< 0.93~) but 1.0~rc1-3bazaar1 is to be installed
<somerville32> oh noes :(
<somerville32> I pushed to the wrong series.
<zeasier> having some trouble with bzr where we changed some directories to symlinks and now the working tree won't update on our other branches
<jam> zeasier: what is happening when you try to update
<jam> I wonder if our commit code didn't properly delete things
<jam> and now it things you have children underneath the symlink, or something odd like thaht
<zeasier> we get a sequence of errors
<jam> that
<jam> zeasier: can you paste it ?
<jam> !paste
<ubotu> pastebin 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)
<zeasier> trying to find one, one moment
<zeasier> bzr: ERROR: Tree transform is malformed [(ânon-directory parentâ, ânew-1650â)]
<zeasier> though we've found a work around for that
<somerville32> Is it possible to go back and modify a commit message?
<bialix> privet
<zeasier> it has to do with the directories that were changed to symlinks
<bialix> I have question about English
<bialix> mini-tutorial title is "Bazaar in five minutes"
<jam> somerville32: only right at the moment by using 'bzr uncommit' and then 'bzr commit' with a new message
<beuno> somerville32, only uncommiting til that revision (thus, loosing al intermediate history/changes)
<zeasier> if you remove the directory the update works fine (though i'd like to file a bug, if you all thing it's unique)
<bialix> any suggestions how better translate "in 5 minutes"?
<jam> zeasier: sounds unique to me
<jam> bialix: is there a russian term for "in a short amount of time"
<jam> or "give a quick summary of how to get going with X" ?
<zeasier> i ran a bzr check and got, "10 inconsistent parents" at the end
<jam> zeasier: I don't think the inconsistent parents is specifically related
<jam> that is a checking for something differennt
<zeasier> ah
<jam> (revision parent... over history, not over the files)
<zeasier> thing is after the work around i just told you we run into a 2nd problem
<zeasier> bzr: ERROR: Key secureimages-20071030155234-zswi43l3yzmiegcj-182 is already present in map
<zeasier> this is after we delete all the directories that have changed into links
<bialix> jam: yes, we have stable idiom about 1 minute, 5 minutes. I mean what is synonym for this. is it means: "teach bzr in 5 minutes" or "5 minutes acquaintance with bzr" or?
<zeasier> don't have a work around for that yet
<beuno> bialix, seems close to "5
<jam> zeasier: well, if you can paste a traceback, that would help (the tail of ~/.bzr.log)
<bialix> jam: because in russian I can't say simply "bzr in short amount of time". the sentence is icomplete for russian
<beuno> minutes acquaintance with bzr"
<jam> bialix: it isn't a complete sentence in English, it is just a common idiom
<zeasier> alright i'll get to that, one moment
<bialix> hence and question
<jam> bialix: maybe "get aquianted with bzr in 5 minutes"
<zeasier> http://paste.ubuntu-nl.org/46862/
<zeasier> that's only the trackback, let me know if you want stuff from futher up the log
<bialix> or "5 minutes for acquiatance with bzr"? it's seems good variant in russian.
<jam> zeasier: so ... off-hand it sounds like you have the same file versioned 2 times.
<jam> bialix: well, that would be bad in english, but if it makes sense in russian :)
<jam> acquianted
<jam> acquainted
<jam> finally, correct spelling :)
<bialix> jam: we have song in one old movie about New Year, "five minutes, five minutes -- it's too much or too small?". I'll try to use something consonant.
<somerville32> I love bazaar :]
<zeasier> do bzr branches traverse syslinks? will bzr add . add something like i-am-a-link/subfile?
<jam> zeasier: As I mentioned earlier, it sounds like when you changed dirs to symlinks, we didn't properly mark the children of the symlinks as removed.
<jam> zeasier: 'bzr add .' will not
<jam> 'bzr add link/foo' might
<zeasier> ah
<jam> zeasier: bug #173944
<ubotu> Launchpad bug 173944 in bzr "adding files below symlink causes error" [Medium,Triaged] https://launchpad.net/bugs/173944
<zeasier> i saw that one
<zeasier> though our problem is a little different
<zeasier> we added files in a directory then changed that directory to a link
<jam> zeasier: right, I just wanted to mention that "bzr add link/foo" can do funny things
<zeasier> yeah
<jam> changing it underneath us... needs better testing
<jam> the code that notices when a file/directory becomes a symlink
<jam> needs to be a bit smarter about the repercussions
<zeasier> i've been impressed with the softwares stability so far
<zeasier> not too disapointed we screwed it up this way
<zeasier> just want to contribute a bug you all can use
<vila> jam: back
<jam> zeasier: yeah, a few versions back we wouldn't let you change a directory into a symlink without a 'bzr rm; bzr add' change
<jam> we got rid of that
<jam> but obviously didn't catch all the edge cases.
<zeasier> here's the commits that created the problem
<zeasier> http://paste.ubuntu-nl.org/46863/
<zeasier> is this enough to reproduce the issue?
<zeasier> you can see the changed directories and a list of files in one of them
<bialix> or maybe "get started with bzr in 5 minutes"?
<dato> that sounds good to me
<dato> and seems close to the meaning in English
<vila> bialix: get in the bazaar in five minutes ?
<jam> bialix: I think "get started with Bazaar in 5 minutes" the most
<jam> zeasier: well, having a simple test script is the nicest, but that does look like it would be reproducible
<zeasier> alright hopefully i'll get that bug filed by the end of today
<jam> zeasier: what version of bzr are you using?
<zeasier> we're using rc1
<jam> (bzr --version)
<jam> zeasier: did you do the commit with rc1?
<zeasier> no
<jam> do you know what version you used?
<zeasier> timestamp: Thu 2007-11-29 17:45:48 -0500 through timestamp: Fri 2007-11-30 18:03:53 -0500
<zeasier> from our commit log
<jam> my simplistic test shows the child file as deleted
<zeasier> we're using whatever the lastest release in your apt repo is
 * dato wonders why bzr.dev claims it's 0.93
<jam> dato: well, bzr-1.0 claims it is 1.0candidate1. just that bzr.dev claims 0.93.dev.0
<dato> yes, I said bzr.dev ;)
<jam> mostly because when 0.92 was finalized, we didn't know whether it would be 0.93 or 1.0... so we went conservative
<jam> I'd be happy to review a patch :)
<jam> zeasier: well, at the moment, I haven't been able to reproduce it with a very simple test
<jam> so it *might* have been fixed
<zeasier> yeah, i know that feeling
<jam> but I have the feeling it might be a deeper seated bug
<jam> having to do with your directory layout
<zeasier> i might try to reproduce by uncommitting that branch and redoing those changes
<zeasier> though i did find a work around for the 2nd error
<zeasier> bzr: ERROR: Key secureimages-20071030155234-zswi43l3yzmiegcj-182 is already present in map
<fullermd> You could do it without uncommit just by branching the previous rev and doing it in another copy.
<zeasier> if we bzr rm instead of just rm it seems to go away
<zeasier> bzr must of cleared out what ever the conflict way
<batoms> if am at my computer at home and i want to branch from server A to server B does bzr have to download everything to my computer first from server A to then upload it to server B
<batoms> or is there a way to make A and B communicate directly
<beuno> batoms, can you ssh to one of the servers?
<beuno> (seems to me that you want something like fxp protocol)
<batoms> the servers are both launchpad....i haven;'t actually tried
<batoms> bueno: something like fxp is what i had in mind
<batoms> they repos use bzr+ssh protocol
<ubotu> New bug: #173980 in bzr ""unknown branch format" for unknown repository" [Medium,Triaged] https://launchpad.net/bugs/173980
<beuno> batoms, I'm not sure if you can ssh into launchpad que execute bzr branch in the shell, but you can try  :D
<beuno> I know you can SSH to it, just not sure if you can run bzr on it
<beuno> (would seem to me like you should't be able to)
<jam> beuno: you can't ssh to it, only sftp or bzr+ssh
<jam> batoms: at the moment, it has to download and re-upload everything
<beuno> I know LP has the ability to mirror branches, won't that work for you?
<jam> well, I don't think he wants to have LP mirror a branch to itself
<jam> it is more of a "ask the server to branch for me"
<jam> which has been requested in the past
<jam> but hasn't been implemented yet
<jam> I believe it is expected (or at least something to make creating new branches easier) in the next 6 months
<batoms> jam: exactly what i'm looking for
<batoms> guess i'll just have to sit throught it.....i'm on a slow satellite connection
<beuno> jam, can't you register a new branch and specify it to checkout from a LP url?  that won't create a branch, but at least a checkout of it
<jam> beuno: last I checked you couldn't change a mirrored branch into a hosted branch
<batoms> bueno: i think it can mirror a branch but you can't then push to the new branch
<jam> batoms: I've been offering a service up creating new branches (myself) by ssh'ing to london
<jam> batoms: to help in instances like this
<beuno> jam, but you can registed a new one, and when you do, it allows you to specify a mirror URL
<beuno> s/registed/register
<jam> batoms: what branches do you have/ what do you want to have?
<jam> beuno: right, but as mentioned, that creates a "mirrored" branch, an you cannot manually "bzr push" to one of those
<beuno> jam, ah, yes, right. Not that useful
<batoms> bazaar.launchpad.net/~bauble/bauble/trunk to bazaar.launchpad.net/~bauble/bauble/0.7
<batoms> i started the 0.7 branch already but it got cancelled before it was finished
<jam> batoms: go ahead and delete ti
<jam> it
<batoms> so the directory is there but anything that might be inside it is garbage
<jam> batoms: if you go to: https://code.edge.launchpad.net/~bauble/bauble/0.7
<jam> it should have a "delete this branch" option
<jam> well: https://code.launchpad.net/~bauble/bauble/0.7
<jam> I'll upload it under my account, and then transfer it to you
<batoms> deleted
<batoms> jam: fantastic, yer a star
<jam> batoms: in the mean-time, what version of bazaar are you using?
<batoms> 0.92
<batoms> .0
<jam> ok.
 * beuno wonders if sftp supports FXP-like commands
<jam> you might try upgrading to packs (I think in 0.92 it was --knitpack-experimental, but in 1.0 it is --pack-0.92)
<jam> beuno: I don't believe so
<jam> I've looked into it in the past
<batoms> jam: what is packs?
<jam> batoms: it is a different repository format, which is a lot better when you have high-latency links
<beuno> jam, it seems there a few clients out there that support it. LP probably doesn't though.
<jam> beuno: I assume you don't mean: http://en.wikipedia.org/wiki/FXP
<jam> (I found the correct link, but I thought that one was funnier)
<beuno> jam, e resources on both servers.
<beuno> ah
<beuno> (pasted garbish)
<beuno> :p
<jam> It is "double leveraged to deliver twice the inverse of the daily performance"
<jam> batoms: https://code.launchpad.net/~bauble/bauble/0.7
<jam> should be correct
<batoms> jam: so the only drawback with packs is that bzr clients <0.92 can't read them
<jam> batoms: correct.
<jam> oh, and you should change the author of that branch
<jam> I forgot to do so before I transferred it to you
<batoms> well since i'm the only developer for my project then that shouldn't be a problem
<batoms> jam: thank alot
<batoms> that saved me a ton of time
<jam> batoms: also, there are a few rough edges in 0.92
<jam> which should be greatly smoothed out in 1.0
<jam> 1.0rc1 has a bit of polish already (and, in fact, makes it the default format)
<beuno> jam, googling around makes me thing most sftp setups support fxp by default
<beuno> looking for a client to test it with LP
<jam> beuno: well LP is using a customized sftp server, using Twisted as the sftp implementation
<jam> beuno: and googling for 'sftp fxp' doesn't give me much
<batoms> gotta go, thanks again for the help
<beuno> jam, I'll give it a try anyway, just to make sure
<beuno> http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/fxp-short-reads.html
<jam> sure
<beuno> that makes me think it might work, mainly due the ssh's nature
<jam> beuno: I think "FXP" in that case stands for FileTransferProtocol
<jam> and is just referring to SFTP commands
<jam> I don't think it is true cross-domain commands
<beuno> jam, right, seems reasonable
<jam> considering, as near as I can tell, all of the sftp commands are prefixed with FXP
<jam> FXP_OPEN, etc
<beuno> (seems all fxp implementations are on windows, so it doesn't give me much hope)
<luks> heh, bzr used to have plugins in bash? (contrib/fortune)
<jam> luks: we used to support arbitrary executables
<jam> we might still support it
<jam> though I've wanted to nuke that code for a while
<jam> luks: I still see "ExternalCommand" in the codebase, though
<jam> luks: so if you set "BZRPATH" to /usr/bin
<jam> things could get interesting
<jam> bzr cp
<jam> bzr ln
<jam> etc
<jam> bzr python
<jam> I guess
<luks> bzr bzr :)
<bialix> have another question about translations. I want to start russian translation project at launchpad. what kind of license i need to chose?
<luks> `bzr bzr` errors with AtributeError: 'NoneType' object has no attribute 'startswith'
<bialix> i mean russian translation of bzr docs
<jam> bialix: well, bzr the codebase is GPL, but I don't know that we have settled on a documentation license
<jam> bialix: ask the list, I guess
<bialix> does launchpad already understands pack format?
<thumper> bialix: yes
<bialix> great
<thumper> bialix: launchpad is currently running with 0.92
<bialix> ok
<beuno> thumper, really??  LP is running ? 0.92?
<thumper> yes
<beuno> ah, pretty cool
<thumper> 1.0rc1 coming soon
<bialix> why not waiting for 1.0 final?
<thumper> bialix: if you look at the bottom of https://code.edge.launchpad.net/ you'll see "Launchpad uses Bazaar  0.92.0."
<thumper> bialix: it may end up being that
 * beuno is impressed with LP admins
<jam> thumper: i just responded to your email
<thumper> jam: ta
<jam> thumper: can you give me the output of "locale" on that machine?
<jam> I think it is just using a locale that doesn't support all unicode characters
<jam> like iso-8859-1 instead of UTF-8
<thumper> jam: I'll ask Tom
<bialix> thumper: thanks, now I'm too know kung-fu :-)
<thumper> jam: Tom isn't around right now, and the other person I'd normally ask is lifeless
<thumper> jam: emailing might be more likely to get him in a timely manner
<jam> thumper: not a big deal
<jam> If you don't have access that is fine
<jam> more curiousity
<jam> or confirming what I already believe
<bialix> have another question about english
<bialix> Bazaar User Guide, section "Team collaboration, central style"
<bialix> central or centralized?
<zeasier> this is as close as i could get to the bug i was talking about
<zeasier> https://bugs.launchpad.net/bzr/+bug/174027
<ubotu> Launchpad bug 174027 in bzr "Replacing a directory with a symlink fails after status" [Undecided,New]
<zeasier> doesn't seem exactly the same
<zeasier> but it's close enough
<ubotu> New bug: #174027 in bzr "Replacing a directory with a symlink fails after status" [Undecided,New] https://launchpad.net/bugs/174027
<ig1> morning
<poolie> hello
<jkakar> It's interesting to note that my workflow is so dependent on bzr that I find doing "basic" things terrible without it.
<jkakar> It's one thing to intellectually think, yeah, bzr has changed the way to do things.  It's another thing to *feel* it when bzr (or parts of it like bzrtools) aren't available.
<jkakar> Oh... uh.. bzrtools still doesn't install on gutsy. :)
<fullermd> The phrase you're groping for the use of is "It's not MY fault the rest of the world sucks."   :p
<jkakar> fullermd: Hah, yeah, I think you're right. :)
<dato> jkakar: if you mean with bzr 1.0rc1, you could grab the package from http://packages.debian.org/sid/bzrtools. should install fine.
<jkakar> dato: Ah, thanks, that's a good idea.
<jml> jkakar: my problem is that it's hard to explain that.
<fullermd> jml: I like to use copious profanity and stomping around.
<jml> jkakar: so that the svn projects I work on will get around to upgrading.
<fullermd> (it doesn't really work either, but it's good for the soul)
<jml> heh
<jml> I was about to say that :)
<jkakar> jml: I have a very hard time explaining it, too.
<jkakar> jml: The experience I've had with Bazaar is that branch-based development is a better way to do things than shared-branch development.  I usually try to communicate the benefits of branch-based development and then talk about Bazaar as a tool to help effectively practice it.
<jkakar> jml: So far the results are that the people I've talked seem to believe me about the benefits of branch-based development but want to use Subversion to implement it.
<fullermd> Which would be kinda fun to watch from the outside, if they didn't drag you into it.
<jkakar> jml: The other problem is that some of people are Windows developers and the lack of a solid GUI is a show-stopper.  CLIs are not acceptable and I don't think it's reasonable (or possible) to change that in a Windows-based environment.
<jkakar> One of the other big problems I seem to run into when trying to advocate branch-based development is that existing projects often have deployment warts (particularly when it comes to databases) that make switching between branches hard.  Overcoming those problems is usually seen as expensive and, when you have no experience with branch-based development and why it's good, hard to justify.
<abentley> Evening, all.
<naitandu> hello everyone
#bzr 2007-12-05
<poolie> hello naitandu
<igc> jkakar: the latest User Guide might help. It's currently online here: http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html. The section on Reusing a checkout explains some ways around the "switching locations configured in tools/databases" issue. The very first chapter puts the case for Bazaar as well.
<naitandu> where can i get current information on bazaar for Visual Studio? The bazaar-site did only mention it as part of GSoC ?!
<jkakar> igc: Thanks!  I'll check that out.
<igc> jkakak: no problem. Also see http://bazaar-vcs.org/BzrWhy, particularly my paper on Why DVCS matters.
<Peng> Hahaha. Reconcile over sftp took 230 minutes. I think it takes 20 locally, and it might take up to an hour to upload; don't remember.
<Peng> (This was of bzr.dev. Well, close it it.)
<Peng> Augh!
<Peng> I have a copy of bzr.dev there too that I could reconcile.
<poolie> hm
<Peng> Also, there were 12-13,000 SFTP.readv()s in .bzr.log. :)
<jml> igc: thanks
<igc> jml: can you tweak that and submit to pqm or do I need to?
<jml> igc: I've tweaked it, but you need to submit it to PQM.
<igc> ok
<ubotu> New bug: #174055 in bzr "can't run bzr info while dirstate is locked" [Low,Confirmed] https://launchpad.net/bugs/174055
<ubotu> New bug: #174059 in bzr "test__create_temp_file_with_commit_template_in_unicode_dir fails if test platform doesn't allow unicode filenames" [High,Confirmed] https://launchpad.net/bugs/174059
 * igc food
<jml> igc: I've found the cause of the selftest failures: I wasn't unregistered my test transport.
<bac> spiv: ping
<spiv> bac: pong
<lifeless> jkakar: 'bzr switch'
<xjjk> hi... I think I'm going in circles trying to find something
<xjjk> I want to use the latest bzr packages from bazaar-vcs.org's Ubuntu repositories, but bzr-svn is not included... are there up-to-date packages of that somewhere as well?
<igc> jml: cool. Can you submit an updated patch for me to land?
<jml> igc: yep. in a sec
<jml> sent
<igc> hi WeirdArms
<WeirdArms> Hey
<WeirdArms> Had a talk with our QA lead
<WeirdArms> he's not interested in Bazaar
<igc> did he say why?
<WeirdArms> was just wondering if you had suggestion for two-way tools to cross import
<WeirdArms> pretty much what we discussed
<WeirdArms> so badly burnt on baz
<WeirdArms> and far enough into choosing Hg to reconsider
<WeirdArms> So I'd like to try it out
<igc> two-way tools are a two-edged sword as you know
<WeirdArms> but would need to be able to import out central repo into Hg and then push Bzr comments back to Hg
<WeirdArms> yeah
<igc> we do have bzr-hg but I suspect it's more about migration that full two-way interaction
<WeirdArms> ok
<igc> by migration, I include local mirroring
<fullermd> Last I heard (which was long ago), it could at least pull from local hg branches, but wouldn't work with remote.
<fullermd> I don't think it's had much love.
<fullermd> igc: Was that checkout/bound mail reasonably clear (or at least, definitively muddy)?
<igc> fullermd: it was great thanks
<igc> I like your explanation but I wonder whether most people think that deeply about it?
<fullermd> Well, most people probably have lives instead   ;>
<igc> :-)
<igc> it does matter though ...
<fullermd> I tend to /think/ that most of the people using those capabilities are wanting checkouts, but there's probably a core of people wanting bound branches.
<igc> particularly when implementing switch on heavy checkouts
<fullermd> (but those impressions aren't based on anything real concrete)
<igc> I think switch ought to be the same as "unbind; pull --overwrite URL;bind URL" ...
<fullermd> It's stuck me as one of our low-level (in the sense of 'minor', not 'architecturally fundamental') stress points for a while.
<igc> i.e. to make the local cache a true reflection of the remote branch
 * fullermd nods.
<igc> there's an argument for switch meaning "bind + update" though
<fullermd> I think you can probably mostly ignore the schism as far as 'switch' goes; people who really want 'bound' probably wouldn't use it.
<igc> i.e. be safe and don't throw away any local changes
<fullermd> Is there a difference?  I know 'pull' merges WT changes...   never tried --overwrite.
<fullermd> I guess it might.  You'd probably want '--overwrite-branch-but-merge-wt'.
<igc> it's necessary if the branches have diverged
<fullermd> It gets a little sticky if you have --local commits; do you want to throw them away?  Can you even tell, without contacting the upstream (which may have gone away)
<igc> not sure if I can tell
<mlh_> tee hee Is this naughty of me: http://svn.haxx.se/users/archive-2007-12/0065.shtml
<mlh_> "Watch out though - you may like them (bzr or git) so much you might not want to
<mlh_> go back to svn.
<mlh_> It's weird though, time and time again I see questions that would be suitable addressed by using a DVCS.
<Peng> What would be weird is if someone *did* want to go back to svn...
<dash> so, um... I typed "bzr add" by mistake and added a bunch of files I didn't want to
<mlh_> And yet the SVN bigwigs say they don't see the demand
<dash> will "bzr added|xargs bzr revert" get me back to where I was? :)
<fullermd> I'd use "bzr rm --keep" instead of revert, but I think the result would be the same.
<dash> oh, what's the difference
<fullermd> I'm not sure there is one.
<fullermd> Just 'feels' clearer to me what I'm doing.
<dash> errrrm hm
<dash> 'bzr added' does not print anything, despite 'bzr status' showing a pile of added files
<fullermd> added might go down from $CWD instead of the tree root...
<dash> weird
<dash> well, that worked
<dash> thanks!
<Peng> How important do you think it really is to back up before running reconcile? I mean, is it just in case something goes *really* wrong, where reconcile would traceback? If "bzr log -r -1" works and check seems fine, is it okay to delete the backups?
<spiv> Peng: if check passes, then I'd be pretty comfortable with the reconcile.
<spiv> Peng: I guess it depends on how much you trust our code vs. how much it's costing you to keep a .bzr.backup directory lying around :)
<Peng> spiv: Well, I'm on a very small partition, so the cost is > nothing.
<spiv> Peng: In that case, I'd just delete the backup.
<spiv> Peng: If bzr check is happy, then the branch is pretty healthy.
<Peng> But on the other hand, all of my backups are just another 60 or 70 MB.
<spiv> Peng: if you can "bzr check" a branch, you know that every revision is intact.
<Peng> Also, I still have a few ".bzr.knits.tar.7z" files from when I converted to packs, so I guess the clutter doesn't bother me much, either.
<Peng> Okay.
<Peng> Well, I'll keep 'em around anyway.
<Peng> Anyway, thanks
 * Peng wanders off.
<Peng> bug 165080
<ubotu> Launchpad bug 165080 in bzr "Quick Start Guide doesn't document "bzr send"" [Medium,Fix committed] https://launchpad.net/bugs/165080
<Peng> Thanks ubotu.
<Peng> Sorry for the interruption. Now back to your silence.
 * mlh_ finishes counting out 4'13" of silence, sends royalties to John Cage
<AfC> Silence is underrated.
<mlh> AfC: hypocrite!  :-)
<Peng> Oh no, the foam slip my DS came in is slightly rotn.
<Peng> rotn?
<Peng> torn.
 * Peng wanders off.
<Peng> Erk.
<Odd_Bloke> Peng: Erk?
<Peng> I ran 'bzr remove-tree' to save some disk space, and it didn't delete a bunch of directories due to .pyc files, so then I tried to run 'bzr clean-tree', but it wouldn't run because there was no working tree!
<Peng> So now I ran 'bzr co' and I'm going to try clean-tree again.
<ubotu> New bug: #174105 in bzr "move glossary from web site into user docs" [Medium,Confirmed] https://launchpad.net/bugs/174105
<lifeless> igc: pull overwrite clobbers local changes doesn't it? switch shouldn't do that ;).
<terdmonk> hi, im new to bzr and am trying to see if it fits RCS model my team is looking for
 * terdmonk is trying to understand where branches fit in
<terdmonk> if i start a project called foo-1.0
<terdmonk> and also start project foo-2.0
<terdmonk> should both projects belong under a foo branch?
<terdmonk> or is foo-1.0 and foo-2.0 put under their own branches?
<terdmonk> and if so, how will a developer be able to check out the latest branch without knowing what version is the latest?
<terdmonk> i could see how a developer could checkout the latest branch if i had foo/foo-{1,2}.0 as a branch
<terdmonk> could someone kindly shed some light? :)
<Odd_Bloke> terdmonk: What you would tend to do is have your main development taking place in one branch, normally called 'trunk'.  When time for a release comes, you branch from 'trunk' to 'foo-n.n' and any release-specific stuff goes into 'foo-n.n' while development can continue in 'trunk'.
<Odd_Bloke> So unless a developer is specifically working on a release branch, they should always be referencing 'trunk'.
<terdmonk> Odd_Bloke, ah yes. i see :)
<terdmonk> so my directory structure would be project-foo/{trunk,foo-1.0,foo-2.0}, where trunk, foo-1.0 and foo-2.0 would be their own branches?
<Odd_Bloke> Something along those lines, yeah.
<terdmonk> Odd_Bloke, excellent. thanks mate
 * terdmonk continues digging at bzr doco
<Odd_Bloke> You would want 'project-foo' to be a shared repository (look at 'init-repo'), so that any shared history from the branches will only be stored once.
<terdmonk> ahh, init and init-repo do different things :)
<terdmonk> gotcha
<Odd_Bloke> Yeah, 'init' creates a branch, 'init-repo' creates a shared repository.
<terdmonk> and a shared repository is meant for hosting branches?
<Odd_Bloke> terdmonk: All branches have a repository, where revisions are stored.  Having a shared repository simply reduces duplication.
 * terdmonk nods
<Odd_Bloke> So they should be used wherever more than one branch with the same history will be stored.
<Odd_Bloke> They also make using branches for features and bug fixes a lot easier.
<Peng> terdmonk: FWIW, I like it better when the main branch of a project is called "foo" or "foo-dev" or something rather than just "trunk". That way if I just want to get a copy of that branch and no others, the directory has a useful name.
<Odd_Bloke> +1 on that.  bzr uses 'bzr.dev'.
<Odd_Bloke> s/trunk/foo.dev/ throughout. :)
<lifeless> you can also have foo - a repo and foo/foo-1.0
<lifeless> a branch at the root which is trunk :)
<Peng> lifeless: Bleh, that would be confusing.
<Lo-lan-do> Hi all
<Lo-lan-do> Quick question: is bzr-git more-or-less usable?
<Lo-lan-do> Also, would you happen to know whether there's a git-bzr floating around somewhere?
<Odd_Bloke> Lo-lan-do: Toward the less ATM, I believe.  Enough for bzrk, the Launchpad page claims.
<Lo-lan-do> Yeah, but that page doesn't seem very recent, hence my quest for someone alive
<Odd_Bloke> Lo-lan-do: I believe the 'refactoring' branch is still the most recent work that has been done...
<Odd_Bloke> jam would know more.
<Odd_Bloke> (implicit ping :p)
<Lo-lan-do> Yeah, I'm told jelmer also has an interest in it since Samba apparently moves to git
<ubotu> New bug: #174127 in bzr "Requesting a --names-only option for bzr diff" [Undecided,New] https://launchpad.net/bugs/174127
<blauwal_> Hi, I've got a question about bazaar workflows. Assume we have an existing workspace and want to work on a new feature branch: With Subversion I would do: svn copy REMOTE:SOURCE-URL REMOTE:DEST-URL; svn switch REMOTE:DEST-URL; with git I would do git branch feature; git update feature. With bzr I guess I would have a shared repository with trees and would do an bzr branch foo feature inside the repository. This would still require to copy the whole w
<blauwal_> orking tree, albeit without the history. Is there any way around it?
<Peng> Not at this time, and I don't think they plan one.
<blauwal_> Peng: Thanks for your answer. It's a pitty though, copying 1.8 GB of sources is a pain in the ... :)
<ddaa> is there a way to bypass the confirmation prompts of "bzr break-lock"?
<Peng> Is there a --force?
<ddaa> nope
<abentley> then I guess you can't use the --force.
<ddaa> and "< /dev/null" causes it to busy-loop printing the confirmation message
<Peng> Oh.
<Peng> I recently found out uncommit has a --force. Why not break-lock? Too dangerous?
<abentley> Breaking a lock that is actually being used can cause data corruption.
<ddaa> abentley: I figure you know that I realize that :)
<abentley> ddaa: Yes.  I was answering Peng.
<abentley> ddaa: I think you would have to use bzrlib.
<abentley> I'm not sure it would be wise to provide a way to bypass break-lock's prompt.
<Peng> What about some shell thing to pass it a few "y\n"s?
<Odd_Bloke> 'yes' FTW. :)
<mwhudson> ddaa: you have to supply a ui factory
<Peng> I think I tried yes for something, and it didn't work.
<mwhudson> ddaa: hm, are you reviewing my launchpad branch by any chance?
<mwhudson> ddaa: if not, you should and your questions will be answered :)
<mwhudson> also 173941
<mwhudson> bug 173941
<ubotu> Launchpad bug 173941 in bzr "hard to programmatically break a lock" [Wishlist,Triaged] https://launchpad.net/bugs/173941
<ddaa> actually, I'm just trying to fix up stale locks in a ad-hoc way
<ddaa> I already grepped the oops report into a list of bzr break-lock commands
<mwhudson> ah
<mwhudson> find ... -name held -type d | xargs rm -f ?
 * mwhudson runs away, terribly fast
<ddaa> mh
<mwhudson> not serious, at all :)
<ddaa> that actually sounds like a plan
<mwhudson> i guess it would work
<ddaa> I'll be a bit more specific though :)
<ddaa> function h4X0rL0cK () { rm -rf $1/.bzr/{repository,branch}/lock/held; }
<ddaa> while read b < tobreak.txt ; do h4X0rL0cK $b ; done
<ddaa> that should do it
<ddaa> abentley: does that sound okay to you?
<abentley> ddaa: It looks like it would probably work, but it doesn't seem to prevent you from deleting non-stale locks.
<ddaa> the tobreak.txt file is a list of branches with known stale locks
<ddaa> at least, known stale assuming nobody else broke the stale locks without telling me
<abentley> Well, you're no doubt aware it isn't 100% safe.  But it looks like it will do what you are asking.
<ddaa> anything more specific about unsafety than "it's a scary hack"?
<abentley> Just the race condition.  A lock that you think is stale may no longer be stale.
<ddaa> how's that
<ddaa> if there's a stale lock, then the branch cannot be locked
<ddaa> so it cannot become unstale
<abentley> Someone can run break-lock after you have generated tobreak.txt
<ddaa> right
<abentley> And then commit.
<ddaa> it's assuming nobody else is breaking locks
<abentley> Right.
<ddaa> mwhudson: please do not break stale locks kthxbye
<ddaa> race condition fixed :)
<ddaa> okay mass stale lock cleanup done
<muffinresearch> Hi I am preparing a presentation about decentralised VCS and bazaar in particular. Can anyone explain what makes bazaar's diff algorithm better than others?
<muffinresearch> Having looked here http://bramcohen.livejournal.com/37690.html  there's not a lot of detail that will make it straight forward to explain.
<ddaa> abentley: this is for you
<ddaa> bzr does not even use Bram's patience diff exactly, but a modified version.
<ddaa> In a nutshell, the intent is to make the diff as close as possible to something that reflects the intent of the programmer, for changes typically found in source code.
<ubotu> New bug: #174153 in bzr "bzr export --format=tar should have excludes options" [Undecided,New] https://launchpad.net/bugs/174153
<ddaa> I cannot tell you how that translates in algorithmic technicalities though.
<naitandu> hello
<Lo-lan-do> Um.  Wasn't the packs format supposed to be faster than dirstate?
<Lo-lan-do> "bzr missing" takes 5.2 seconds on a dirstate repo, and 7.7 seconds on a copy of that repo upgraded to packs...
<Lo-lan-do> (Between branches stored in the same repo, both times)
<mwhudson> Lo-lan-do: "it depends"
<mwhudson> missing sounds like one of those operations that might read the entire index
<mwhudson> which is slower with packs
<Lo-lan-do> Oh.  Hm.  What's faster then? :-)
<mwhudson> well, it depends what you're doing
<mwhudson> in this case what probably needs to happen is that missing needs to be rewritten to use more graph based apis
<mwhudson> Lo-lan-do: for example "pull" is waaaaaaaaaaaaaaay faster with packs
<Lo-lan-do> status?  diff?
<mwhudson> i think status might be slower, with a band-aid applied to the 1.0 branch
<mwhudson> diff is likely about the same
<Lo-lan-do> Okay, I'll keep my dirstate-with-subtree then :-)
<mwhudson> well, you can keep both around easily enough
<Lo-lan-do> Is there some doc on rich-root?
<dato> not sure. but for bzr-svn is preferred over d-w-s
<jelmer> Lo-lan-do: what sort of documentation are you looking for?
<jelmer> bzr init --help lists the rich root formats
<Lo-lan-do> jelmer: What it's supposed to bring :-)
<jelmer> it doesn't bring anything additional except the bits required to be used by bzr-svn, and is stable as opposed to dirstate-with-subtree which is experimental
<Lo-lan-do> Hmm.  So I should upgrade my repo to rich-root then.
<Lo-lan-do> I'll try that right away :-)
<jelmer> I don't think you can downgrade from dirstate-with-subtree to rich-root yet
<dato> I've done it by pulling, I think
<vila> Lo-lan-do: you should file a for any operation that is slower with packs than with knits, they are likely to fixed quickly
<vila> s/file/file a bug/
<Lo-lan-do> Okay
<Lo-lan-do> I've started branching one branch of my dirstate-with-subtree repo into my rich-root repo about 20 minutes ago, it's still going.
<Lo-lan-do> Not much disk I/O, but lots of CPU eaten.
<dato> is it safe to rm repository/obsolete_packs/*? does bzr automatically do that, and when?
<Peng> dato: I think they're deleted next time it repacks.
<dato> riiight, placing the new old ones there. so it's never empty, it seems.
<james_w> dato: yeah, you should only ever have one generation of obsolete packs, and so the disk usage wont grow indefinitely.
<james_w> but you are right, it will never be empty after the first repack (except if you delete it, and the short time before the new packs go there).
<james_w> but yes, you should be safe to delete it.
<dato> ok, fair enough.
<dato> I can see it being ok when pushing over sftp, since it's just a mv.
<dato> but I push all my personal branches (those I'm the only commiter) with plain rsync since day 0, so I'd find a bit annoying having to sync obsolete_packs as well.
<dato> which is what I'll do, pass --exclude obsolete_packs to rsync.
<Peng> Why use rsync?
<Peng> It's probably faster, but unless you have gigs od data here it shouldn't be that dramatic.
<bialix> privet
<bialix> is Ian here?
<dato> Peng: rather than remembering to push after each set of changes in *each branch*, I just run `sync-code` once at the end of the day, or so.
<james_w> bialix: no, it's a bit early yet I think.
<Peng> dato: Huh.
<Peng> dato: There's like a repo-push plugin.
<bialix> heh, people from Oz
<Peng> Erk, I can't keep track of who's who.
<dato> Peng: huh wtf, kthxbye.
<jam> bialix: He won't be in for about 3 hrs
<jam> dato: use checkouts for everything (it is what I do between by desktop and laptop and my server)
<bialix> ok
<jam> He will definitely be around in 5
<jam> but that may be too late for you
<bialix> may I ask anybody else, about our user-guide
<jam> (the other problem with igc is that he is in a different part of Oz, which doesn't do DST, so he is an hour off of lifeless and poolie)
<jam> bialix: you can ask, I may not tell :)
<dato> jam: nah, this suits me very fine. :)
<jam> I believe Aaron uses a local treeless repository and lightweight checkouts which he rsyncs between home and office
<jam> but that may have changed over time
<jam> since he has "repo-push" and "multi-pull"
<jam> in bzrtools
<Peng> jam: Part of Oz doesn't do DST? Cool.
<bialix> repo-push is not the part of bzrtools
<dato> jam: plus, I like to sync the trees as well
<jam> IIRC igc is in Brisbane (north east AU)
<jam> bialix: separate plugin... hmm, sounds a lot like bzrtools material, though.
<jam> bialix: anyway what is your user guide question?
<bialix> it's a small and picky question actually, http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#introducing-bazaar section about history
<Peng> You guys seriously use rsync? You know, you added push and pull commands like 20 versions ago.
<bialix> generations: 1. file versioning tools, e.g. SCCS, VCS <-- is VCS correct here? perhaps it should be RCS?
<bialix> Peng: I don;t use rsync, because I'm win32-guy
<Lo-lan-do> bialix: I usually collapse generations 2 and 3 together, as well as 4 and 5.
<Lo-lan-do> To me, distributed VCS is 3rd gen.
<bialix> Lo-lan-do: right now I ask as translator
<Peng> bialix: You == Alexander Belchenko, the guy who's been working on repo-push and -pull?
<bialix> repo-push only because James Henstridge don;t support this plugin
<bialix> I'm not aware about existence repo-pull
<Peng> Oh.
<Peng> Okay, then.
<Peng> I'm not either, then.
<Lo-lan-do> jam, jelmer: By the way, any details on bzr-git?  The Launchpad page is sketchy, as is the wiki page, but Odd_Bloke tells me you're both involved in it.
<jam> Peng: I haven't used rsync since 0.8
<jam> But then, I wrote the original Transport code to make remote operations possible.
<Peng> jam: Oh, good. :)
<jam> bialix: The one you are looking at should be RCS
<jam> 1. file versioning tools, e.g. SCCS, RCS
<jam> is the correct programe
<jam> program
<jam> Lo-lan-do: I was working on it a bit back at our company meeting
<jam> I started working on the ability to build git branches to spec, so that I could make sure they get transformed into Bazaar branches properly.
<bialix> what's actually difference between revision control and version control -- for english speakers?
<jam> But I got side-tracked by everything else.
<jam> bialix: in effect, not much
<Lo-lan-do> jam: Heh, that tends to happen :-)
<bialix> jam: revision -- is one of the hardest term to translate
<jam> bialix: http://www.m-w.com/dictionary/revision
<jam> 2:  a revised version
<jam> So a revision is... a version
<jam> that is somewhat modified from another version
<bialix> :-)
<jam> so "revision" has a bit more of the concept of evolving from another version
<jam> (the "re" part)
<jam> well revise maybe..
<jam> So a "version" is a bit more standalone, and "revision" makes you think there was another one it came from
<jam> but they are pretty much interchangable
<bialix> oh, thanks. version is frozen, revision is vivd
<bialix> vivid
<jam> bialix: bzr.dev has already been updated to say RCS
<jam> we probably just need to regen the docs
<bialix> hmm, then my mirror of bzr.dev is out-of-date
<Peng> jam: You need to regen http://doc.bazaar-vcs.org/latest/developers/ anyway so packrepo.html will work! And create a redirect from knitpack.html to it!!
<Peng> Should I have filed a bug on that?
<bialix> btw, question about HistoryHorizon
<bialix> in ru_bzr one guy asked about such feature
<bialix> he said git already has it. It's true?
<Peng> Hah!
<dato> yes
<jam> bialix: git has the ability to 'graft' in history
<jam> which  means your local tree claims to have more history
<bialix> heh
<jam> than what gets pushed and pulled
<Peng> In doc.b.o/bzr.1.0, packrepo.html works but it links to knitpack.html which 404s!
<jam> I know you can start with a snapshot, and graft in history
<jam> I don't know if you can take something that already has history
<jam> and break it
<bialix> sounds very good
<jam> but I guess  if you just did a fresh import
<bialix> i'm thinking about this
<bialix> many times
<jam> bialix: but it is one of the key items that Canonical wants in the next 6 months
<bialix> also sometimes I think about semi-commit
<jam> bialix: semi-commit?
<bialix> when actual work is not finished to do fullcommit, but I need to go home/work and somehow I need push my changes to server or my USB stick
<jam> something wrong with "commit + push + uncommit" ?
<bialix> repo-push plugin don;t like uncommits
<bialix> and I'm a bit worrying about repo history pollution by temp garbage
<jam> just make a 'repo-clone' which supplies "overwrite=True".
<jam> bialix: not a lot of garbage, and when people pull from it, it doesn't get transferred
<jam> otherwise, you could commit to the side, generate a Merge Directive for that
<jam> and send the MD
<jam> and merge it on the other side
<jam> but that still installs the revisions into the repo
<bialix> yeah
<Peng> Any way to get the LCA of two branches?
<jam> The other is to just use "bzr shelve" and copy your .shelf across
<jam> but you need "patch" for that
<lifeless> jam: bialix: you can only graft on a local client in git
<jam> Peng: yes
<lifeless> it doesn't propogate
<jam> lifeless: right,
<jam> I think the point is that it doesn't
<bialix> no shelve is not silver bullet. it's still don;t support binary files
<jam> Peng: "bzr log -r ancestor:../other-branch .
<jam> the final '.' is probably not needed
<jam> Peng: or are you in bzrlib itself?
<Peng> jam: Not in bzrlib.
<jam> lifeless: good to see you around, now go play WoW :)
<bialix> IMO shelf should operate more like temp branch, not as side patch
<Peng> (Actually, I just want to create a small patch that can go in bzr.1.0 and bzr.dev without cherrypicking.)
<dato> jam: (jfyi, GFDL's invariant sections are optional, and Debian will happily take GFDL material if it does not make use of such sections)
<jam> dato: thanks
<jam> Peng: hmm.... I think you can do
<jam> cd bzr.dev; bzr revision-info -r ancestor:../bzr.1.0
<jam> and then bzr branch -r XXX  bzr.dev bzr.ancestor
<Peng> Right.
<Peng> Thanks.
<jam> If there is no revision number, then you need to use "revid:..."
<jam> Though when I just tested it, it seems to give the dotted revision number in the current branch.
<Peng> Oh.
<Peng> Well, I hope it did, because I just used that.
<bialix> jam: I just thought: is it possible to generate snapshot of working tree packed in zip or tar.gz as semi-commit?
<bialix> generating patch is not enough, because we need to know fileid for newly added files
<bialix> is it safe to save snapshot of dirstate and then apply it to fresh tree?
<Lo-lan-do> Ouch.  Branching from dirstate-with-subtree to rich-root took 108 minutes.
<jam> Lo-lan-do: ouch and a half... I don't know why it would be that slow....
<Peng> knit -> pack?
<jam> bialix: I believe if you take a snapshot of the WT and .bzr/checkout/dirstate it will work
<jam> Peng: no, rich-root is still knits
<jam> (rich-root-pack is packs)
<jam> And knit => pack is reasonably fast
<bialix> jam: I think it will enough to pack unfinished work for me. will try to write plugin
<jam> pack => knit is slow
<jam> bialix: if you want to get extra fancy
<jam> you can use "tree._iter_changes" to only pack up files which have been modified
<jam> which would make for a smaller .zip file
<bialix> nice, thanks
<Peng> jam: Oh.
<Peng> Right.
<Peng> I think the LCA should be 3055, but 3052 works.
<jam> Peng: remember, both sides need to have it, so A merging B isn't enough, B also needs to merge A
<jam> Well, A merging B will give you the last revision of B as the common ancestor
<Lo-lan-do> Same branching into a pack-0.92-subtree repo takes 5 minutes.
<jam> Lo-lan-do: it sounds like it is doing something like regenerating all of the inventory files
<jam> since the source might have fields that aren't allowed in the target.
<jam> but man... almost 2 hours is something that should be looked at.
<Peng> jam: 3053 in both branches is identical.
<jam> (not necessarily by me... :)
<Lo-lan-do> I'll report it, just after I report the regression in bzr missing.
<Peng> jam: 3054 was merged from bzr.dev into bzr.1.0.
<bialix> I'd like to ask one more question about english (or maybe australian?) recently Andrew Bennets wrote in reply about criss-cross: "wiggeda wiggeda wack". It's sounds very funny, but I have no idea what's it
<jam> bialix: there was a rock group named "Criss-Cross"
<jam> well, a hip-hop group
<bialix> "jump jump"
<Lo-lan-do> The two youngsters wearing their clothes the wrong way?
<jam> bialix: http://www.lyrics4all.net/k/kriss-kross/totally-crossed-out/jump.php
<jam> Kris Kross will make you Jump Jump
<jam> ...
<jam> And inside-out is wiggida wiggida wack
<jam> bialix: or if you prefer: http://www.youtube.com/watch?v=4UgficQpYE4
<radix> o/`
<jam> radix: yes?
<jam> (Assuming that is a person putting their hand up)
<Lo-lan-do> I think maybe he means âª
<jam> ah
<jam> probably
<radix> o/` some-o-them try ta rhyme but they can't rhyme like this o/`
<radix> jam: yeah. you're confusing o/` for o/ :)
<Peng> What do we lose when doing cherrypicking?
<lifeless> data
<bialix> history
<Peng> Very specific. :P
 * dato gives o/~ to radix ;)
<fullermd> Hopefully, we can lose evil 90's hiphop references...
<bialix> jam: thanks, LOL * 100
<radix> dato: pshaw. o/` is superior to o/~. but of course u"\N{EIGHTH NOTE}" is the best :-)
<Lo-lan-do> There.  Debian bugs #454503 and #454504.
<ubotu> Debian bug 454503 in bzr "bzr: Performance regression with pack format" [Normal,Open] http://bugs.debian.org/454503
<ubotu> Debian bug 454504 in bzr "bzr: Large performance regression with rich-root format" [Normal,Open] http://bugs.debian.org/454504
<Peng> :D
<Peng> "And what have you been busy with this holiday season?" "Creating large performance regressions!"
<Lo-lan-do> Sorry about that
<Lo-lan-do> But, well, 108 minutes is a tad long for me.
<Peng> :P
<Peng> The missing thing is probably known and related to logs or complete-history-traversal or something. Did you check Launchpad?
<Lo-lan-do> I checked the BTS, and I checked on IRC, and IRC told me to report it, so I report it.
<Peng> Ah, okay.
<bialix> jam: can't pull your branch https://code.launchpad.net/~jameinel/bzr/index-buffer-all
<bialix> so, can't test your patch
<bialix> for #172975
<Peng> bialix: If it's a missing revision, the branch might be against bzr.1.0 instead of bzr.dev.
<bialix> no, it's just absent at launchpad
<bialix> "This branch has not been mirrored, as Launchpad has been unable to access it."
<Peng> Oh oh.
<bialix> jam's server may be down
<Peng> Serves me right for replying before opening the link. :P
<bialix> or as daemon in Grim Fandango said: the server is never down - it's temporarily unavailable ;-)
<Peng> :)
<Peng> Launchpad has actually given up on trying to mirror it? How long was it down?
<Jammer> is there way to see who has edited certain line last time?
<elmo> Jammer: bzr annotate
<Jammer> elmo, thanks... dunno how I missed that >_<
<Peng> Wait, bound branches != checkouts?
<jam> mwhudson: any luck on getting the importer to mirror my slow branches?
<Peng> jam: Poke about https://code.launchpad.net/~jameinel/bzr/index-buffer-all not being mirrored because Launchpad couldn't access it?
<fullermd> Peng: I keep my bound branches in the closet.  That way I can't hear them scream.
<jam> Peng: that is what I was pinging mwhudson
<jam> about
<jam> I'll hit try again
<Peng> jam: Oh oh. Okay.
<jam> but basically it was failing because it was taking longer than 15min to get progress
<jam> which is because inventories.knit is big enough
<jam> that it cannot stream all of it over my slow pipe in 15 minutes
<jam> vila's patch should help that
<Peng> You haven't upgraded to packs?
<jam> Peng: not on my main public repository
<Peng> (Well, I guess a 50 MB pack would be even worse than a 5 MB kndx. :P )
<mwhudson> jam: haven't tried to be honest
<mwhudson> jam: maybe you can mirror them off people.ubuntu.com to start with?
<jam> mwhudson: well, the whole point is I don't want to have to go manually uploading my branches to launchpad
<jam> if I wanted to do that, I would just push there directly
<jam> I use "bzr register-branch" and then I can just forget about it from there forward
<mwhudson> jam: it should be fixed by the next rollout
<mwhudson> i guess we could bump up the timeout too
<ig1> morning all
#bzr 2007-12-06
<tjs> lifeless: G'day
<tjs> just wondering if there is an overview of pqm anywhere
<tjs> the lp page suggests it has a web ui, magically manages trunk etc.. I installed it via apt and it has no doco, I browsed the repo and found a readme that is fairly silent on what it actaully does :)
<Peng> If we knew how to use it, what fun would the Canonical wizards have?
<tjs> heh
<spiv> tjs: There's my OSDC talk (and paper) from last year, I guess, which briefly covered what PQM is useful for from a high level.
<spiv> tjs: But I'd hope there's something more specific and useful than that :)
<tjs> spiv: ah cool, I'll check it out. jml mentioned yesterday that I might find it useful, we started with combinator last week and due to how our build system works (buildout) combinator just wont work for us, we're going to switch to bzr
<spiv> tjs: hooray!
<spiv> tjs: If it helps, I can probably answer most questions about PQM.
<spiv> tjs: (lifeless isn't around atm)
<tjs> ah neato
<tjs> so jml called it a robot, the lp site says it has a web UI, yet the .deb has nothing that looks like a daemon
<tjs> or a config file
<spiv> I believe it's typically kicked off by procmail.
<tjs> as we're moving from svn we'll be using bzr initially like svn, central repo etc. the company wants their assets backed up and central
<tjs> oh
<jml> tjs: I never said "robot"
<spiv> The way we use it for bzr is that we use the "bzr pqm-submit" command (from the bzr-pqm) plugin to generate and send gpg-signed emails asking PQM to merge such-and-such a branch onto such-and-such a branch.
<spiv> PQM will receive that email, check its configuration to make sure the GPG signature is from someone that is allowed to change the relevant branch, then do the merge, and run a configured command to verify that the merge is good (e.g. "make check").
<spiv> And then it'll email back the results.  Obviously if the merge has conflicts or the "make check" (or whatever) command fails, it won't commit the merge.
<tjs> aah
<spiv> tjs: There is also a web UI so that people can see the queue of merge requests.
<spiv> There's an instance at https://pqm.bazaar-vcs.org/, although there's not much to see right at the moment :)
<jml> tjs: did I give you that link to http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html
<tjs> jml: I'm reading it atm :)
<tjs> so under 5.2 Publishing a branch, it mentions your central repos should be built with --no-trees so that it holds history only and no source files
<spiv> tjs: Btw, browsing the source for PQM, I see stuff like http://codebrowse.launchpad.net/~lifeless/pqm/trunk/annotate/173/manual.xml
<tjs> wouldnt that proclude people being able to 'check out a branch' ?
<spiv> tjs: which sounds like more docs than you've found in the .deb package.
<spiv> No.
<jamesh> tjs: no.  You only need the .bzr dir to pull from a branch
<spiv> tjs: a --no-trees repo just doesn't hold checkouts.
<tjs> aah
<spiv> tjs: that's just like a SVN repo.
<tjs> so with the central server workflow outlined in http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html#team-collaboration-central-style, devs bzr checkout, update, commit, all is well. When they want to create a new branch on the central server, do they do that locally then 'push' to a new location on the central server? then they delete their local branch and check out the one they pushed?
<thumper> anyone know what version of bzr-svn works with bzr 1.0rc1?
<tjs> that sounds a bit clumsy
<Peng> thumper: The latest one, I guess. The bzr-svn page mentions it.
<igc> tjs: no need to delete the local branch then checkout - just use bind to turn the local branch into a checkout
<tjs> ah
<spiv> tjs: you don't need to delete the local branch, you can use "bzr bind REMOTE_URL" instead.
<spiv> (And similarly you can unbind a checkout to turn it into an independent branch)
<tjs> ok
<igc> tjs: section 5.3 explains that I hope
<ubotu> New bug: #174275 in bzr "Test and improve Mac OS X installation experience" [Medium,In progress] https://launchpad.net/bugs/174275
<lifeless> tjs: full docbook docs
<lifeless> tjs: if you want drop in bzr for svn, you want the bzr+ssh server
 * spiv -> lunch
<fullermd> Hm...
<fullermd> viz seems to be on strike.
<poolie> fullermd, how do you mean?
<fullermd> It bombs out trying to import from 'about'.  I see about.py there in the root of .../plugins/gtk/, so...
<fullermd> Wasn't there some discussion recently about fiddling with import paths?
<Peng> Removing the current working directory from the path, yes.
<fullermd> Well, I'm nowhere near that dir.  Just the only thing that sprang to mind.
 * Peng shrugs.
<Peng> I'm not sure a patch even came from that.
<fullermd> Well, that just means it's not tested.  Obviously at fault, then   :)
<lifeless> tjs: 'bzr branch remoteurl otherremoteurl'
 * igc lunch
<tjs> lifeless: by 'bzr+ssh server' do you mean 'just use bzr over ssh to a server' or do you mean the 'smart server' thing there is a blueprint for?
<spiv> tjs: if you have bzr installed on the remote server, you can literally use e.g. "bzr push bzr+ssh://host/path"
<spiv> tjs: e.g. "bzr push bzr+ssh://bazaar.launchpad.net/~spiv/bzr/feature-X"
<tjs> *nod*
<spiv> (Which is the "smart server".  You can also use it over TCP ("bzr://") or with some effort HTTP, but bzr+ssh is most common.)
<tjs> cool
<tjs> and that allows server side commit hooks ?
<spiv> It will.
<tjs> :)
<spiv> It doesn't quite yet, although it's fairly close.
<spiv> If you wanted, I could point you at the right bits to hack on the close the gap :)
<tjs> naw, its ok for now
<ubotu> New bug: #174337 in bzr "bzr diff ERROR [bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (win32)]" [Undecided,New] https://launchpad.net/bugs/174337
<vila> spiv: thanks for the review, top class one :)
<Mez> hmm,
<Mez>     use_revno = global_config.get_user_option('cia_send_revno', default='f')
<Mez> NameError: global name 'global_config' is not defined
<terdmonk> hi, me is very new to bzr and is still digging around to see if its the RCS he should use amongst his team
<terdmonk> ive just pushed a branch in my central sftp locatoin
<terdmonk> bzr push --directory project-foo sftp://server/srv/bzr/repo/project-foo
<terdmonk> i can list the contents of sftp://server/srv/bzr/repo/project-foo with bzr ls sftp://server/srv/bzr/repo/project-foo
<terdmonk> but how do i list the contents of sftp://server/srv/bzr/repo/
<terdmonk> so my developers can see what other branches have been pushed to this central location?
<Lo-lan-do> With sftp, I guess
<terdmonk> i cant do it with bzr?
<Lo-lan-do> Actually, I don't know, don't listen to me :-)
<terdmonk> Lo-lan-do, thanks for the suggestion though. :)
 * terdmonk keeps reading bzr doco
<ubotu> New bug: #174389 in bzr-eclipse "bzr command limited to one file" [Undecided,New] https://launchpad.net/bugs/174389
<spiv> terdmonk: the "bzrtools" plugin adds a "bzr branches" command that can do that.
<spiv> terdmonk: but it's not built-in to bzr yet.
<spiv> vila: thanks!
<spiv> vila: I just hacked up selftest to use the trace stdlib module, and got this result: http://rafb.net/p/9LizHs38.html
<spiv> vila: the >>>>>> lines are lines that "./bzr --no-plugins selftest '(?i)http'" did not execute
<spiv> vila: thus these appear to be gaps in your test coverage :)
<spiv> vila: e.g. your implementation of RangeFile.seek(..., 1) seems to be untested.
<spiv> vila: otherwise it's mainly error handling, which is a good sign.
<terdmonk> spiv: cool.. ill check out bzrtools.. thanks!
<vila> spiv: wow, any chance your hack get into bzr.dev ?
<vila> indeed RangeFile.seek(...,1) has not been tested, in fact bzr requires only seek(...,0) seek(...,2) is only used by dead code, but I didn't to be controversial ;-)
<vila> s/to/ want to/
<vila> and yes, some seek(.., 2) can be implemented even if we can't seek backwards ;)
<spiv> vila: interestingly, the whence=1 case appears to get exercised by the same selftest invocation in bzr.dev (i.e. without your change).
<spiv> vila: so superficially at least it looks like you're keeping a feature but losing test coverage for it.
<spiv> vila: I find it very easy to believe it's unimportant, but I'm also extra paranoid given how close 1.0 is :)
<vila> spiv: indeed, the feature is not used in bzr.dev
<spiv> vila: Hmm, but there was a test for it?
<vila> spiv: no problem, go, be paranoid ! So that I can relax a bit ;)
<spiv> Or a test that used it.
<spiv> Heh :)
<vila> spiv: from memory yes, only tests and only :
<vila>  def test_seek_and_tell(self):
<vila>         # Check for seeking before start
<vila>         self.fp.seek(-2, 0)
<vila>         self.assertEqual(0, self.fp.tell())
<vila>         self.fp.seek(5, 0)
<vila>         self.assertEqual(5, self.fp.tell())
<vila>         self.fp.seek(-2, 1)
 * vila don't use memory when looking at the code is faster
<vila> That's the only place
<vila> and since it's a backwards seek it explains why I deleted it
<vila> but I will add tests for whence in (1,2)
<vila> spiv: even if you hack didn't find its way into brz.dev, I'm *very* interested in a patch ;-)
<spiv> vila: I posted it to the list already (I hope!)
<spiv> vila: http://bundlebuggy.aaronbentley.com/request/%3C20071206121348.GA32675@steerpike.home.puzzling.org%3E
<spiv> vila: I've updated my vote on your change to tweak, btw; see my latest post to the list.
<Zindar> hello
<vila> spiv: really, great ?
<vila> spib: regarding this xUnit book your pointed me at, have you a better book in mind on TDD or can I safely buy this one ?
<spiv> vila: basically I decided that I couldn't pick any significant holes in your code, so we may as well start get people using bzr.dev testing it in the real world :)
<spiv> vila: and I also decided to stop worrying about the 1.0 branch and let poolie2 make that call ;)
<vila> spiv: good, time to write that tiny plugin to make urllib the default http implementation then
<spiv> vila: for TDD, I'd probably recommend Kent Beck's _Test Driven Development By Example_ over the xUnit Patterns book.
<spiv> vila: the xUnit Patterns book is pretty good, but Beck's book is *much* shorter :)
<spiv> They're about pretty different topics, though.
<spiv> The xUnit Patterns book isn't really about TDD, it's about refactoring test code (whether or not you're writing tests first).
<spiv> vila: If were to buy two books though, I'd buy both :)
<vila> looking into it, but only the first is available at amazon.fr so it will be here sooner ;)
<vila> and since my birthday was last week, I can afford both \o/
<vila> done
<spiv> vila: merry christmas and happy birthday :)
<vila> hehe, thks :)
<spiv> Also, thanks to jam's swift approval, selftest --coverage is with PQM already!
 * spiv -> bed
<ubotu> New bug: #174414 in bzr "bzr unable create lightweight checkout in the root of shared repo" [Undecided,New] https://launchpad.net/bugs/174414
<ubotu> New bug: #174437 in bzr "--coverage leads to traceback" [Undecided,Confirmed] https://launchpad.net/bugs/174437
<bialix> privet, guys
<bialix> I'm thinking about idea "sam on top of bzr", and I'd like to discuss it a bit
<bialix> s/sam/scm/
<jelmer> dato: Hi
<jelmer> dato: Can you sponsor another upload?
<jelmer> dato: bzr-rebase 0.3, I've already uploaded packages to http://samba.org/~jelmer/debian/
<jelmer> This matches the version in bzr on bzr.debian.org
<dato> noted; it may take a couple days this time
<jam-laptop> bialix: what do you mean by "on top of bzr"
<bialix> hi, jam. I mean this: for my current job project I have about 15 different branches. I nee the way to somewhat organize them all
<bialix> need the way
<bialix> Because currently bzr don't help in my needs, I should some tool on  top
<bialix> sorry, I need some tool on top of bzr
<bialix> today I finally start writing some code. I highlight 3 base concepts I need: Project, Branch and Subproject
<bialix> Project build up form Branches and Subprojects. Subproject is just link to another Project
<bialix> so I can build hierarchical structure of my actual project
<bialix> http://pastebin.com/d65d7215f
<bialix> and here example of project.conf: http://pastebin.com/d346379b9
<bialix> it's just fast draft to start playing with indea
<bialix> idea
<bialix> When I will have valid project.conf with description I'd like to have ability to (lightweight) checkout project for work
<bialix> something like modules in CVS
<bialix> back in my TortoiseCVS days I've used modules in one big and complex project
<bialix> I know that I'm reinventing the wheel
<bialix> I just can't find ready-to-use solution
<bialix> and can't stopping my idea flow
<bialix> The main idea: I can list existing defined projects, do full checkout of big project, or only some subproject and so on
<bialix> I'm also need somehow keep information about different variations for one project, per example for different customers some branches will be different, but body of project will stay the same
<bialix> And I'm sure it's not the same as NestedTree we very long time talked about
<bialix> It's just the way to describe relations between branches
<bialix> I really like to talk about this idea with someone
<mrtuple> could someone assist with a 'not a branch' error in bzr 0.91?
<jam-laptop> bialix: you might try "config-manager" as a way to track multiple sub-projects for a meta project
<jam-laptop> and getting things properly built, etc.
<jam-laptop> Last I heard it was rather crufty, though. But it might give you a starting point
<bialix> jam-laptop: I try to look at this tool several times in the past. It looks too linux-centric
<jam-laptop> mrtuple: we can try, but certainly not without more information :)
<jam-laptop> mrtuple: the #1 thing I would check is that you really are giving it the right path
<mrtuple> I have a .bzr/branch-format and a .bzr/branch/format files.
<mrtuple> I'm pretty sure of the right path... one moment and I'll prove it (at least to myself)
<mrtuple> yep
<mrtuple> ssh-agent sbox$ ssh 138.67.142.48 cat ./sbox/pfind/.bzr/branch-format
<mrtuple> Bazaar-NG meta directory, format 1
<mrtuple> but
<mrtuple> bzr branch bzr+ssh://138.67.142.48/sbox/pfind ./pfind-repository
<mrtuple> yeilds
<jam-laptop> mrtuple: you need the absolute path
<jam-laptop> not relative to your home dir
<jam-laptop> also
<mrtuple> a;dkjfa;ldkjfal;kdflee3jaa;lkadfah;akldf
<mrtuple> sorry to waste your time.
<jam-laptop> mrtuple: no problem :)
<mrtuple> many thanks.
<bialix> jam-laptop: config-manager's last commit was 1.5 years ago
<jam-laptop> bialix: doesn't mean it doesn't work :)
<jam-laptop> bialix: but really, I think NestedTrees *are* what you want, but we don't really have them yet
<jam-laptop> so in the short term, you need something else
<jam-laptop> I think it could easily just be a plugin
<bialix> yes, may be as plugin
<jam-laptop> with stuff like "bzr build-project" etc
<bialix> I don;t understand how NestedTree supposed to store meta-info about projects?
<jam-laptop> well, it is supposed to store locations of where you are updating your branches from, etc.
<jam-laptop> There may be some parts of what you want
<jam-laptop> that are not covered by NT
<jam-laptop> but I think a lot of it is
<jam-laptop> You may want to write up your use case on the NT wiki page
<jam-laptop> just to have another data point for how it should work.
<bialix> I don't know how NT should work
<jam-laptop> bialix: the point is for you to write up what you want
<jam-laptop> (your use case)
<jam-laptop> and then people implementing Nested Trees
<jam-laptop> can take that into account
<jam-laptop> it may not do everything you have requested
<jam-laptop> but at least that gives us a starting point.
<bialix> but I need several level of NT at the same time
<jam-laptop> bialix: NT should support several levels
<bialix> and somewhat describe different variations for the same project
<jam-laptop> I'm not sure about different variations of the same tree
<jam-laptop> but I think it would be reasonable to have that concept mentioned
<bialix> I mean some branches in NT may be different
<jam-laptop> bialix: sure
<jam-laptop> I certainly would expect to be able to create a NT for different releases
<jam-laptop> 1.0 would have different branches than 0.9
<jam-laptop> and someone working on feature X would probably want their own branches
<bialix> I don't mean different set of branches
<bialix> I mean for some lib foo I have trunk, bar and spam branches
<bialix> and I need the way to specify configuration when instead foo in NT will be used either trunk or bar
<jam-laptop> bialix: that is a 'different set of branches', IMO, and is definitely something NT needs to support.
<bialix> NT wiki page, summary, item 2: Can we do better than configs?
<bialix> so my idea with config is step backward?
<jam-laptop> well, for the existing configs, maybe
<bialix> so nested tree itself should be some standalone being?
<bialix> substance
<jam-laptop> I'm not sure what you mean by "standalone being" it is functionality we want as part of bzr core
<bialix> not just the way to work with set of branches?
<bialix> I mean separate object
<bialix> I lack english terms here
<bialix> something separate from branch/wt/repo
<bialix> additional block in bzr model?
<jam-laptop> bialix: Not necessarily, it may just be that WT has the ability to do NT
<jam-laptop> at least, that was my feeling
<bialix> I can't imagine how it will works in reality
<jam-laptop> some of why NT would be better than configs is that it would integrate with general workflow
<jam-laptop> rather than remembering "oh, I need to commit the snapshot of my set of branches" it would just be a "bzr commit" at the top level
<bialix> what about log?
<bialix> it will be summary log for all sub-branches?
<bialix> what about tags?
<bialix> I need tag all branches at one time
<jam-laptop> bialix: well, if you tag a top-level tree, then it implicitly references all sub-trees
<jam-laptop> With NT each tree keeps a reference to the current version of the sub tree
<jam-laptop> so if you tag a sub-tree, then it *effectively* marks that node, and everything underneath it
<jam-laptop> because a committed revision refers to everything underneath it
<jam-laptop> I would certainly expect NT to allow  you to create a "release-1.0" tag for just a library
<bialix> so I'll need to create some empty top-tree to put all my subprojects in?
<jam-laptop> (or at least a lib-release-1.0 tag)
<jam-laptop> bialix: Project is your top level tree
<bialix> currently my set of branches is very loosely coupled
<jam-laptop> whether it is empty or not is probably just dependent on how you want to divide things up
<bialix> I have sources to compile on Linux, another sources for Windows, some for microcontrollers, docs, schematics
<bialix> it just a big basket
<bialix> so most of the time I'm working only on some subtree
<bialix> I probably never will checkout the whole project
<jam-laptop> I think this is all worthy of being put on http://bazaar-vcs.org/NestedTreeSupport
<jam-laptop> even if it amounts to "stuff that NTS is not meant to solve"
<jam-laptop> I think part of what you are discussing is a "branch registry" of sorts
<bialix> I read http://bazaar-vcs.org/NestedTreeSupport but I still can;t imagine how it supposed to work in reality
<jam-laptop> so you can refer to things without having to use raw URLs
<jam-laptop> Which would also fall under some of our discussions about branch aliasing
<bialix> I don't remember about branch aliasing
<jam-laptop> bialix: just being able to use an alias to refer to a full url
<bialix> btw, I'm starting to put all my unrelated branches in one pack repo. I have about 44 MB of packs and about 23MB in obsolete_packs section. Is it normal?
<jam-laptop> bialix: in a couple of commits you will get 44MB of packs, and probably a few hundred KB in obsolete_packs
<jam-laptop> Well, as long as you are using something newer than 0.92
<bialix> do I need time-to-time run repack manually?
<jam-laptop> IIRC, 0.92 didn't clean up obsolete_packs
<bialix> I'm using 1.0rc1
<jam-laptop> bialix: 'bzr pack' is purely optional, but probably beneficial at the moment
<jam-laptop> Robert has a patch which will make it do a bit of extra sorting for Revisions which helps 'bzr log'
<jam-laptop> but right now managing the extra indexes is the actual overhead of multiple pack files
<bialix> yes, I read your mail
<bialix> so my use case is more about keep set of loosely related branches together
<bialix> than actual NT?
<jam-laptop> I think NT could do it, but you may want them to be looser than that
<jam-laptop> but I've thought about using NT to manage a repository of branches
<jam-laptop> which some might consider heretical
<jam-laptop> (bad)
<bialix> need to go, bye
<fbond> Hey, if I do 'bzr merge -r x..y', is it normal for 'bzr missing' to indicate to me that I don't have y?
<radix> fbond: As I understand it, cherry-picked revisions don't get recorded as included in a branch
<fbond> radix: I think I understand why (I merged a diff, not a revision) ... but that seems a bit confusing for users, doesn't it?
<radix> fbond: rich cherry-picking support is a known limitation of bzr, (again) as I understand it.
<fbond> Okay. So there really isn't any difference between using 'bzr merge' and creating a patch and applying it via 'patch', right?
<fbond> (for cherry picks)
<radix> fbond: well, yeah. if you use "bzr merge" without "-r" it records all the information wonderfully :)
<fbond> radix: right :)
<radix> but indeed. I think what you said is pretty close to the truth.
<radix> I'm not a bzr developer, though.
<fbond> radix: okay, thanks!
<fbond> Well, I did notice one thing, though:
<fbond> If I have two branches (a and b) and I do 'bzr merge -r 2..3 a b' and then do 'bzr merge a b', changeset 2..3 only gets merged once (like I want).
<fbond> So bzr must be tracking *something* ...
<radix> fbond: well, bzr just goes "oh, this hunk of diff looks like it's already there"
<fbond> diff/patch wouldn't be quite so smart ...
<fbond> Yeah.
<radix> it's not really rich revision tracking that's doing the work here, it's just resilient diff application
<fbond> I guess you can tell patch to ignore already applied diffs ....
<radix> so yeah, it's a bit smarter than patch
<radix> oh. well then :)
<fbond> Okay, I'm just trying to understand what's happening.
 * radix nods
<fbond> -N  or  --forward
<fbond> Ignore patches that seem to be reversed or already applied.  See also -R.
<fbond> That's from patch(1)
<fbond> Anyway, thanks for your help, I understand the situation now.
<fbond> It seems like cherry picks deliberately lose information that other merges wouldn't.
<fbond> I wonder if the user should be notified that metadata is not merged with cherry picks.
<ita> what is the command for reverting the changes in a file ?
<fbond> ita: bzr revert <path>
<dato> ita: with `bzr revert` you'll undo any changes, and will get the file back to the last committed revision. it'll make a backup copy just in case.
<ita> thanks
<jelmer> hi dato
<jelmer> dato: did you see my message earlier?
<dato> 17:15 <dato> noted; it may take a couple days this time
<jelmer> dato: no hurries, thanks :-)
<lifeless> fbond: also, if you cherry pick at the tip of a branch its recorded as a regular merge
<fbond> lifeless: like 'bzr merge -r 3..4 a b' where rev 4 is the tip of a?
<ita> bazartools is .. wtf??
<ita> Please send this report to bazaar@lists.ubuntu.com with a description of what you were doing when the error occurred.
<jml> lifeless: good morning
<ita> converting an arch repository to bzr looks really complicated
<ita> ah, btw, what is the opposite of  "python setup.py install"  - how to uninstall ?
<jml> ita: there isn't one, I don't think.
<bialix> is PQM down again?
<ita> jml: am i the only one to think that really sucks ? :-)
<ubotu> New bug: #62275 in bzr "pull and update with lightweight c heckouts should only affect the	working tree" [Undecided,Incomplete] https://launchpad.net/bugs/62275
<bialix> ita: not the one
<jml> ita: I'd only go so far as "kind of"
<jml> ita: mostly because I rarely use 'install'. :)
<ita> jml: no, completely, because if you install once again it does not tell you what files are installed
<gokr> Aha, I am #100! :)
<gokr> jelmer: I just got an error trying to do a co of an Svn trunk.
<gokr> (guessing you are the one to talk to)
<jelmer> gokr: hi
<jelmer> gokr: What error exactly?
<gokr> bzr: ERROR: Path "SerialExtendedMacOS9.Â¹.xml.sit" is not unicode normalized
<gokr> Haven't googled yet.
<gokr> Ouch, I don't have the newer subversion - perhaps should fix that first.
<ita> where is the program "baz" ?
<ubotu> New bug: #162466 in bzr "Branch6 bound to SvnBranch left in inconsistent state" [Medium,Triaged] https://launchpad.net/bugs/162466
<fbond> ita: why don't you do 'python setup.py install --prefix=tmp' and see what gets installed there?
<jelmer> ita: http://bazaar-vcs.org/Baz1x
<ita> fbond: nice
<ita> i love this
<gokr> Btw, bzr seems to have come a long way lately. I have used Mercurial for a while - but hey, bzr is looking quite tempting now.
<jelmer> good to hear :-)
<gokr> This file is obviously committed from a Mac, but I am unsure about the character right before ".xml.sit"
<gokr> In the SVN checkout there is no character there.
<gokr> Aha! It *had* a bad name, but not anymore.
<gokr> jelmer: Ok, so the problematic character is "SUPERSCRIPT ONE" utf8: c2b9
<jelmer> gokr: that's odd, bzr-svn works with various other utf8 characters ok
<gokr> jelmer: Sounds like this might be interesting to test: https://bugs.launchpad.net/bzr/+bug/172383
<ubotu> Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Medium,Triaged]
<gokr> ubotu: Right. :)
<ubotu> Sorry, I don't know anything about right. :) - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<gokr> Oh, a robot.
<jml> gokr: we prefer to call them the personality-deprived.
<gokr> Anyway, I will try again with trunks instead of what is in Etch.
<jelmer> gokr: you were running bzr-svn on Mac earlier?
<gokr> No, I am on Etch. But some of the files in the svn repo I am trying to checkout has been committed from a Mac.
<gokr> Or rather - an old file had such a name, it is not there anymore but since we fetch all history... :)
<gokr> This is the Squeak VM btw.
<gokr> Trying again.
<gokr> Btw, if this works it is darn neat.
<gokr> (bzr-svn I mean)
<theuiguy> What's the difference between "bzr pull --overwrite" and "bzr merge --pull (and --force)"?
<poolie2> hello
<poolie2> theuiguy, if the branches have diverged, then
<theuiguy> If I just want a branch to match its parent, what's the best way to do that?
<poolie2> pull --overwrite will discard your changes and put you on their version
<poolie2> whereas merge will do a merge
<poolie2> in that case you want pull --overwrite
<poolie2> possibly followed by revert, if you want to discard your uncommitted changes
<theuiguy> poolie2: Thanks, I think I followed that...
<theuiguy> just for better understanding, what would the merge --pull version do?
<theuiguy> I know merge would try to combine my changes with the parent
<theuiguy> poolie: Is a revert only necessary for unadded changes? Does pull --overwrite not remove files?
<poolie> theuiguy, merge --pull differs from regular merge in that
<theuiguy> only necessary for removing unadded changes (mainly new files)?
<poolie> it basically tries to do a pull --no-overwrite first
<gokr> jelmer: Trying the patch now. Just using the trunk didn't help.
<poolie> theuiguy, revert is only needed for uncommitted changes
<theuiguy> Is it generally good practice to do a pull before the merge anyway?
<theuiguy> or does that more depend on what you're doing
<jelmer> gokr: using which trunk?
<gokr> Emmm, I am using the latest bzr and bzr-svn I could find.
<gokr> This: http://bazaar-vcs.org/bzr/bzr.dev  and this: http://people.samba.org/bzr/jelmer/bzr-svn/trunk
<gokr> jelmer: It looks promising, I think it has passed the problematic spot.
<mwhudson> jam: we increase the branch puller timeout, but it seems your branches have failed often enough to be disabled
<mwhudson> jam: do you have a try again button on https://code.edge.launchpad.net/~jameinel/bzr/extra-range-collapse-165061 ?
<schierbeck> jelmer: ping
<jam-laptop> mwhudson: pushed
<mwhudson> jam-laptop: let's see what happens
<jam-laptop> mwhudson: will hitting Try Again break the lock?
<mwhudson> jam-laptop: ddaa broke the lock earlier
<mwhudson> jam-laptop: i upped the timeout earlier
<jam-laptop> well, I've also hit Try Again on at least 1 branch....
<jam-laptop> anyway
<jam-laptop> we'll see
 * jam-laptop => family time
<mwhudson> it's pulling
<igc> morning all
<gokr> jelmer: It ran through!
<gokr> jelmer: Yep, looks like a success. After I applied that small patch mentioned in that bug report.
<gokr> gnite
#bzr 2007-12-07
<mwhudson> jam: dammit
<mwhudson> can you press the button again?
<igc> ping poolie
<igc> poolie: the --pack-0.92 options are screwing up the User Reference generation :-(
<igc> Can I rename the format to pack-0-92? That fixes it.
<fullermd> igc: Funnily enough, it was the -, not the ., in the format name that always glared out at me   ;)
<poolie> igc, hm, except that may be confusing
<igc> poolie: any thoughts?
<igc> I've sent a patch to the list btw
<Jammer> why does "bzr ignore" add the .bzrignore file into the repository? (I even have .bzrignore itself listed as ignored file)
<igc> jammer: that doesn't sound right
<Jammer> using version that is in Ubuntu repository
<Odd_Bloke> Jammer: So that ignores get propagated to all copies of the branch.  If you want ignores specifically for you, there is a way to set it.
<Odd_Bloke> I'm afraid I can't rememeber what this is as I've never had call for it. :(
<poolie> igc, does the pdf actually need review? or is it just a version of that svg?
<poolie> if it looks poor on evince, maybe file a bug to that effect
<igc> poolie: just a version of the svg
<igc> bug in evince me thinks
<poolie> +1 then
<igc> poolie: thanks - I'll submit it to pqm
<jam-laptop> mwh: pushed
<jam-laptop> I'm reviewing igc's work on switch
<igc> thanks jam-laptop
<spiv> I'm reviewing jam's status after merge.
<jam-laptop> igc: review is finished, bb:tweak
<igc> thanks
<jam-laptop> A couple of small fixes, overall, I think it is worth 1.0
<igc> cool
<jam-laptop> is anyone else finding Bundle buggy to be slow?
<jam-laptop> I think igc mentioned that it doesn't seem to be noticing merged patches
<jam-laptop> which I have brought up with Aaron earlier in the week
<jam-laptop> and he thought he saw that fixed
<jam-laptop> (or at least forcing a rescan cleaned it up)
<jam-laptop> igc: Any chance you can figure out why the PDF looks weird on Ubuntu?
<jam-laptop> It would seem important to have it looking good there
<igc> evince bug I think
<jam-laptop> any chance we could not provoke the bug?
<igc> :-)
<jelmer> hmm, would be interesting to have bb support for irc (-:
<jam-laptop> reviewing spiv's hpss translate root patches
<igc> jam-laptop: if I use inkscape to generate the PDF instead of the script in the Makefile, the result is much better
<jam-laptop> igc: You know you can script inkscape, right?
<igc> I did but I haven't done it
<jam-laptop> I don't see a command in my Makefile
<jam-laptop> am I just missing it?
<igc> doc/en/quick-reference/Makefile
<jam-laptop> ah, wrong makefile
<jam-laptop> yeah, I just found it
<jam-laptop> I haven't done much with inkscape, other than to regenerate the .png files for the website
<jam-laptop> :)
<jam-laptop> anyway, I would probably recommend using inkscape if possible
<igc> yeah - seems so
<jam-laptop> hmm... the directory is quick-reference
<jam-laptop> the target is 'bzr-quickref.png'
<jam-laptop> but yet we call it the Quick Start Guide
<igc> well, Quick Start Card right now
<jam-laptop> igc: shouldn't the targets be renamed as well in the Makefile?
<jam-laptop> bzr-quickref.png: $(OBJECTS)
<igc> yes
<spiv> jam-laptop: is abentley's concern about find_difference a showstopper for your "make 'bzr status' after merge faster" patch?
<jam-laptop> spiv: maybe...
<spiv> jam-laptop: trading slow-but-correct for fast-but-not-necessarily-correct seems worrying :)
<jam-laptop> I didn't feel like it was a strict show-stopper, but
<jam-laptop> the only time it is incorrect is when the shortcut is longer that the distance to origin
<jam-laptop> and igc did point out that we could probably detect it
<jam-laptop> spiv: the other trade off is that when it is "incorrect" it just means that a few more entries show up in
<jam-laptop> pending-merges
<jam-laptop> (it isn't a data loss/corruption/etc)
<spiv> Ok, so it would only affect "status" output.
<jam-laptop> correct
<spiv> Although there's the risk that someone might look at this code and think "that looks like a good way to do it" and use the same approach somewhere more critical...
<spiv> So I guess a big scary comment is called for :)
<jam-laptop> spiv: it is currently on my todo plate
<jam-laptop> it is what I was working on that lead me to the Graph.heads() fix
<spiv> Yeah, I thought they might be related.
<jam-laptop> which is mostly "get find_differences()" to be correct
<spiv> It seemed a bit more than coincidence that you were reworking graph guts :)
<Peng> Hey, there's a "bzr find-merge-base" command. No need to do "bzr revision-info ancestor:..." or anything.
<igc> ping poolie: pack-092 or pack-0-92? I can adjust it before I submit to PQM
<lifeless> its really ugly both ways
<lifeless> how sure are you that its unavoidable ?
<Peng> Okay, so you're going to stop introducting new formats in each version, you're just going to rename the current ones! :P
<fullermd> Eh?  Microsoft bought bzr?
<Odd_Bloke> Will there ever be a circumstance in which a revision won't have the 'branch-nick' property?
<lifeless> yes
<igc> lifeless: I tried to escape it and it didn't
<fullermd> Odd_Bloke: Frex, I've got a number of revisions from before bzr started putting nicks in.
<igc> I'm yet to look at the ReST code itself
<fullermd> (0.7 it came in, I think?)
<Odd_Bloke> OK, rephrase the question: s/revision/new revision/
<lifeless> I think its worth looking at it; 0.92 is the version number, anything else will surprise people.
<lifeless> Odd_Bloke: yes
<Odd_Bloke> lifeless: Cool, thanks. :)
<Peng> I'm always irritated by abbreviated version numbers. I was very happy that "pack-0.92" didn't do that.
<lifeless> Odd_Bloke: primarily importers and such things
<spiv> igc: I reckon we could monkey-patch the regexes in docutils.parsers.rst.Body fairly easily...
<poolie> i'm really not keen on having docs that are almost but not quite rest
<poolie> otoh it's ugly to change our program because of doc tool quasi-bugs
<fullermd> We could just pretend 0.92 didn't happen, and call it 'pack-1'  ;)
<igc> fullermd: :-)
<lifeless> that would be pack-1.0
<poolie> igc, lifeless: i think we should just pick one and do it, so we can get an rc out today
<poolie> igc, spiv, can i recap what we're trying to review or merge today
<lifeless> poolie: I would what spiv suggets - work around the bug by fixing rest on the fly
<lifeless> s/would what/would do what/
<spiv> It does seem backwards to have a documentation tool force us to lessen the beauty of our tool. :)
<igc> can spiv give that a try? we ought to confirm that will work
<poolie> spiv, do you think that kind of change could be accepted by upstream docutils?
<spiv> Another hack would be to format the option list without using ReST's special option list format (seeing as it's apparently not appropriate for us!).  Maybe just a list of ":`--pack-0.92`: this option blah blah blah"?
<poolie> or a table maybe
<spiv> Yeah, or a table.
<spiv> It's not as beautiful, but we avoid the rather strange restrictions on what ReST automagically considers to be valid option names.
<spiv> ":`--pack-0.92`:" works, and looks pretty similar to the existing output.
<spiv> (The online renderer at http://www.hosting4u.cz/jbar/rest/render.py is convenient)
<poolie> or we could put the formats into a separate table from the options...
<spiv> Or a *really* nasty hack is to s/\./DOT/ before feeding the file to docutils, then s/DOT/./ on the output ;)
<poolie> heh
<poolie> spiv, what did you mean by  ":`--pack-0.92`:"
<spiv> Markup like:
<spiv> The list of options is:
<spiv>  
<spiv>   :`--pack-0.92`:  use pack-0.92 format, which blah blah blah...
<spiv>   :`--other-arg`:  do other thing
<spiv> The :foo: is a description list, and the backticks formats the text like a literal.
<poolie> don't we want two backticks then?
<spiv> (Oops, that URL should have been http://www.hosting4u.cz/jbar/rest/rest.html)
<spiv> poolie: oops, yeah.
<spiv> My ReST is apparently rusty :)
<poolie> yeah i worked that out
<poolie> that's ok
<poolie> single backticks have a kinda odd meaning
<poolie> igc, how about changing it to render like that?
<poolie> also, i wonder why this didn't cause the tests to fail
<igc> sounds ok - better than hacking ReST code I think
<spiv> 15:47 < igc> sounds ok - better than hacking ReST code I think
<spiv> (for the benefit of poolie)
<poolie> or changing our format thing now
<igc> yes
<spiv> Btw, there's near comment in the regexes for the option list parsing saying: "# @@@ Loosen up the pattern?  Allow Unicode?"
<poolie> heh
<spiv> So perhaps the docutils guys are amenable to changing this :)
<poolie> so, maybe we should send them a patch after all, but use a non-option list syntax for today?
<poolie> settled?
<spiv> I agree.
<igc> me too
<igc> I'm bust tweaking switch so I'd like spiv to do the work :-)
<igc> s/bust/busy/
<poolie> spiv, what are you up to now?
<spiv> poolie: just finished a review of jam's status after merge.
<spiv> poolie: so now's a reasonable time to look at tweaking the doc generation, but I'd also was planning to review jam's "Graph.heads() optimization... 1500 times faster".
<poolie> spiv, i'll look at the docs
<Odd_Bloke> Are bzr planning on participating in Google's Summer of Code this year?  And, if so, how many people have been accepted for bzr in years past?
<ubotu> New bug: #148087 in bzr ""bzr break-lock bzr+ssh://bazaar.launchpad.net/..." fails to break a lock" [High,Confirmed] https://launchpad.net/bugs/148087
<spiv> poolie: ok
<poolie> Odd_Bloke, we may, we had 3 people last year
<poolie> are you interested in participating?
<Odd_Bloke> poolie: Yeah, definitely.
<Peng> Using find_differences to show pending merges in "status", how many could incorrectly show up?
<Peng> Any is a serious problem, and I don't like that you'd sacrifice that for performance..
<abentley> jam: it can also be incorrect if it hits a ghost.
<poolie_> igc, just where does the problem with the --packs-0.92 name show up?
<igc> make doc/en/user-reference/bzr_man.html
<poolie_> i thought so
<poolie_> oh, they're just warnings
<igc> yes, but check the output
<igc> in your browser
<poolie_> yes i see
<poolie> hm, so the rst generation is quite punned with the regular command line help...
<poolie> and since we already use our own tool to generate the help, maybe it is reasonable to monkeypatch from there
<spiv> A twisted user just brought bug 147836 to my attention.  The fix is trivial, so I just posted it to the list.  I hope we can get it into 1.0rc2.
<ubotu> Launchpad bug 147836 in bzr "'RemoteRepository' object has no attribute '_make_parents_provider' - bundle command fails with bzr remote repositories" [High,Fix committed] https://launchpad.net/bugs/147836
<spiv> It should be a quick review.
<poolie> ok
<poolie> this is a pain to monkeypatch :/
<poolie> too much stuff is evaluated at load time
<poolie_> igc, hey well done with bryce!
<poolie_> have a good weekend, all!
<igc> cheers poolie_!
<igc> have a great weekend everyone
<ubotu> New bug: #174607 in bzr ".bzrignore is not honoured. [Bazaar (bzr) 1.0.0.candidate.1 - win32]" [Undecided,New] https://launchpad.net/bugs/174607
<wam> Hi
<wam> When I bzr add a directory and commit, bzr status tells me, that several files were removed. All further commits say that these files were removed although they're there. Where could I start to debug/correct this?
<wam> I tried to add the files several times without success.
<spiv> wam: what platform?
<spiv> wam: and what bzr version?
<spiv> wam: that sounds a bit like a bug we've had on case-insensitive filesystems, but I'm not sure of the details.
<wam> spiv: sorry, was afk. It's linux ext3 fs.
<wam> bzr 0.15.0
<fullermd> wam: Can you pastebin a 'bzr stat' output and an ls (from the root of the branch) of those files?
<wam> fullermd: http://pastebin.org/10770
<fullermd> Oh, I meant a regular unix 'ls', not the 'bzr ls'.  What does ls of the src/archetypes.schemaextender/archetypes.schemaextender.egg-info/ dir yield, say?
<fullermd> (ls -l, probably)
<wam> fullermd: http://pastebin.org/10771
<wam> fullermd: added ls -ls
<fullermd> Hm.  No symlinks in that path?
<wam> fullermd: none
<fullermd> That's the full 'bzr stat' output?
<wam> fullermd: no, just for those 2 dirs. Do you need the full one?
<wam> fullermd: second
<wam> fullermd: there's only a unknow-section. This is all for "removed".
<fullermd> Hm.  Does it have all those files in the unknown section?
<wam> fullermd: this is the full output: http://pastebin.org/10773
<wam> fullermd: both dirs are from a svn checkout.
<fullermd> Hm.  Wacky...
<wam> fullermd: maybe this means something? Because all other dirs work.
<fullermd> Those names are all just plain 7-bit ascii like they look, right?  No weird chars that look normal?
<wam> fullermd: not that I'm aware of.
<wam> fullermd: navigation works w/o tabs. so I can at least type them ;)
<fullermd> Note that it doesn't list the directories as removed; just the files in them.  That means it's still seeing the dir.
<wam> fullermd: yeah - this is really strange.
<fullermd> I don't remember any such bugs in the 0.15-now timeframe.
<wam> fullermd: oh
<wam> fullermd: second - i got something.
<wam> http://pastebin.org/10774
<wam> argh
<wam> damn
<wam> was in .bzr.
<wam> forget it ;)
<fullermd> Heh.
<wam> fullermd: I can add one of the files and then call bzr stat again and it's shown as "removed".
<wam> fullermd: when I remove the dirs where the buggy files are in, they (=the dirs) show up in bzr stat as "unknown".
<wam> fullermd: as expected ;)
<fullermd> Well, if you haven't changed those files (or anything else, but stat doesn't show any), a quick 'bzr revert' is probably the quickest way to get them all back.
<wam> fullermd: well, I'm doing a svn up in those dirs sometimes.
<wam> fullermd: but as the product also belongs to my project, I want the files in bzr also
<fullermd> Oh, well, that'll probably resurrect them too   :)
<wam> fullermd: so do you recommend to remove them from filesystem and get them back from somewherE?
<fullermd> Well, when they show back up in the filesystem, bzr should notice them and move them back into unchanged (or changed, of course).
<Peng> Worth trying a modern version of bzr anyway?
<fullermd> Well, upgrading is always a good idea.  Though usually by the time you upgrade, the next release cycle has gone through...
<spiv> 0.15 is many release cycles ago now :)
<fullermd> If ressurecting the files doesn't do the job, I'd certainly try that; particularly if it's a dirstate tree, 0.15 was pretty squirrely.
<spiv> I'd definitely try upgrading.
<fullermd> Or even resurrecting them.  Take your pick.
 * fullermd obviously needs sleep.
<Peng> Ooh, rc2?
<fullermd> See?  Told ya!  You upgraded, so there's a new [semi-]release   :p
<Peng> Has the download page been updated yet?
<Peng> If so, the /topic should be.
<Peng> The website has been updated.
<Peng> Who's an op?
<Peng> 'Course, http://bazaar-vcs.org/releases/src/bzr-1.0rc2.tar.gz is a 404.
<fullermd> Don't need to be op to set the topic.
<Peng> The PGP sig has been uploaded, though!
<Peng> That's the important part anyway...
<fullermd> Does it match?   :]
<alwyn> Hi, everyone
<dato> poolie_: as reported by Peng above, seems that the rc2 tarball wasn't uploaded?
<Peng> poolie_: Also, the /topic needs to be updated.
<dato> 11:57 <fullermd> Don't need to be op to set the topic.
<alwyn> I have a bit of a problem with the eclipse plugin for bzr.  My project root is a shared bzr repository. I used Team->Share, but it shows all files bzr status as question marks and really slows down my eclipse.  Known bug?
<ubotu> New bug: #174625 in bzr "Performance regression with pack format in missing" [Undecided,New] https://launchpad.net/bugs/174625
<Peng> dato: You're right. WTF?
<Peng> If I was just slightly less mature...
<alwyn> hmm, maybe I should not have used the word b u g.
 * Peng gets the bug spray.
<fullermd> I don't use a bug, I use a straight key   :]
<ubotu> New bug: #174627 in bzr "Large performance regression when pulling from	dirstate-with-subtree into rich-root repo" [Undecided,New] https://launchpad.net/bugs/174627
<Peng> Wheee.
<ubotu> New bug: #174643 in bzr "help for --sort option of `tags` command needs more help" [Undecided,New] https://launchpad.net/bugs/174643
<blauwal> jelmer: ping
<jdstrand> is there any way for bzr to follow a symlink out of the bzr controlled tree?
<jdstrand> (I don't want it to, I want to make sure it doesn't :)
<Nafallo> jdstrand: hehe. almost scared me for a sec :-)
<sabdfl> hi folks
<sabdfl> is there a command to find the root of the current bzr working tree?
<Nafallo> hiya sabdfl :-). how are you?
<sabdfl> hey Nafallo, great thanks, how are you?
<Nafallo> sabdfl: home sick, thanks for asking ;-). plans to be back at work on Monday :-)
<Nafallo> sabdfl: bzr info shows that information it seems :-)
<jelmer> sabdfl: yep, "bzr root"
<sabdfl> jelmer: ah, thanks! so much better than bzr info | grep "repository branch" | cut -d":" -f2
<sabdfl> :-p
<Nafallo> hehe
<jelmer> :-)
<fullermd> jelmer: You doing bzr-gtk hacking?
<jelmer> fullermd: yup
<fullermd> Does viz on trunk work for you?
<bialix> privet
<jelmer> fullermd: yup, like a charm
<jelmer> are you running bzr-gtk trunk?
<fullermd> Crud.  Why does it hate me?
<fullermd> Yah.
<fullermd> ImportError: No module named about
<jelmer> fullermd: we changed the owner of the branch
<jelmer> ah
<jelmer> fullermd: you're using the old location of trunk
<jelmer> replace "~bzr" in the branch url with "~bzr-gtk"
<fullermd> Ah, I forgot about that...
<fullermd> Can we remove that old location so that morons like me can get error messages instead of just 'Nope, nothing new...'?
<jelmer> fullermd: it's on launchpad - afaik it's not possible to remove stuff from there
<bialix> jelmer: launchapd has button to delete branches
<bialix> at least if it hosted
<jelmer> bialix: where? I don't see anything on https://edge.launchpad.net/~bzr/bzr-gtk/trunk
<bialix> https://edge.launchpad.net/~bzr/bzr-gtk/trunk/+delete
<jelmer> it refuses to delete because there are subscribers
<bialix> well, at least you could delete it via sftp
<bialix> unsubsribe them!
<jelmer> I can't unsubscribe other people afaik
<jelmer> and deleting over sftp gives permission denied
<bialix> you can ask this people, peraps, to unsubscribe
<bialix> perhaps
<bialix> for me it's the bug in launchpad
<bialix> hey, launchpad people, are you here?
<keescook> so, I've hit bug 152746.  It's not clear to me what the work-around is...
<ubotu> Launchpad bug 152746 in bzr "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [High,Confirmed] https://launchpad.net/bugs/152746
<ddaa> where are the option:policy values documented?
<ddaa> (for locations.conf)
<ddaa> I'd need a policy which would be "the path for the inner subsection that matches this path, plus this fixed string"
<ddaa> s/inner/innermost/
<engla> hm. how to get a list of branches in a repo, and then switch to one of them?
<bialix> poolie_: are you still here?
<bialix> why no one report that 1.0rc2 tarball is actually missed on the server?
<bialix> nobody download it? heh
<dato> bialix: Peng noticed and I pinged poolie_ about it
<bialix> we need to wait some hours probably until sun rise in the Oz land...
<bialix> ok, no sources - no win32 installer
<engla> if this project I checked out a branch of; if it had more than this trunk branch, would that show in bzr info?
<bialix> engla: to get list of branches you can run bzr branches (you need to have bzrtools)
<bialix> engla: info shows only actual info about your branch
<bialix> bzr repository is optimisation technics, it's not dedicated to hold branches for only on project
<bialix> you can mix several projects in one repo
<engla> good help
<engla> but I didn't have bzrtools
<mw> hmmm, the rc2 tarball has some minor errors in various version_infos
<abentley> In case anyone's wondering about Bundle Buggy, there's some kinda routing issue.  It's disrupting my email, too.
#bzr 2007-12-08
* Peng changed the topic of #bzr to: Bazaar Version Control System | http://bazaar-vcs.org/ | please test http://bazaar-vcs.org/releases/src/bzr-1.0rc2.tar.gz
<Peng> Mode +t anyone?
<Nafallo> yes, please.
<lifeless> what does that do ?
<Peng> lifeless: Stops random people like me from being able to change the topic.
<Nafallo> lifeless: only ops change topic :-)
<lifeless> hmm, I think its fine at the moment
<lifeless> if we have trouble we can lock it down, but why do that unnecessarily
<Peng> You don't let anyone push to bazaar-vcs.org, do you?
 * Peng shrugs.
<Peng> Not that IRC topics are quite the same security-wise.
<lifeless> Peng: for starters, irc topics are not executable code
<Kamping_Kaiser> its easy to fix the /topic
<Peng> True and true.
 * Peng shrugs.
<Peng> It's insecure (by definition), and uncommon.
<fullermd> lifeless: Don't *SAY* that!  Now Microsoft is gonna go write an IRC client that auto-executes topics...
<fullermd> Remember back when you could say without a trace of irony "Look, email is just text; you can't get a computer virus from an email."
<lifeless> fullermd: you can't ... on linux :)
<phanatic> hey, is pyrex needed only on build time, or during run time as well?
<dato> phanatic: run time, certainly not
<dato> phanatic: build time, only if you modify the .pyx files, or you run from bzr.dev, since the tarballs ship a .c version
<phanatic> dato: i'm building from bzr.dev. thanks for the help!
<phanatic> currently i'm working on a bazaar package for mac. current progress: http://phanatic.hu/bzr/mac/bazaar-dmg-prototype.png
<Discpile> hi... i've been wondering about dvcs... and I'm not quite sure I understand something
<Discpile> let's say I want to get the latest copy of a repository to my computer (a checkout), how would that work?
<Discpile> if there's no centralized repo to get it from
<luks> "the latest copy of a repository" -- that means there is *a* repository
<dato> Discpile: well, normally projects will say, "this one is the main/master/central copy", and then people can make as many copies of it as they want
<Discpile> ah k that makes sense
<Discpile> so would a bzr commit push changes to that copy like with e.g. svn?
<Discpile> if so, that doesn't sound very decentralized :p
<dato> Discpile: by default, no. but bzr allows you to configure it that way (like svn) if you wish. or switch between the two.
<Discpile> so normally when I commit... nothing happens? if just the local copy is updated, why even commit? :p
<luks> normally when you commit, you commit to your local branch
<luks> and later you might either push those changes to a remote branch, send them by mail, etc.
<vila> test suite reached the 10.000 tests mark ;-)
<lera_zed> hi - how can i check what commits would be pushed into specific branch  ?
<dato> lera_zed: bzr missing --mine-only <other_branch_url>
<lera_zed> dato: thanks
<lera_zed> is it possible to have an alias for branch ?
<lera_zed> i mean the actual names are rather long
<dato> lera_zed: I don't think so. *but*, I think luks wrote a bookmarks plugin
<lera_zed> thanks
<dato> lucas, I mean; not sure if luks here is lucas :)
<luks> he is, but he also doesn't know if he still has the plugin code :)
<dato> https://code.launchpad.net/~luks/+junk/bzr-bookmarks
<luks> oh
<dato> lera_zed: ^
<Verterok> lera_zed: for the hostname part, in *nix you can use .ssh_config to set an alias for it (don't known about win32)
<toed> is there no way to checkout without leaving a message?
<abentley> toed: You can always checkout without leaving a message.
<toed> commit, sorry
<dato> toed: I use commit -m '[no message]' :)
<toed> so many excess keystrokes!
<abentley> toed: commit -m "" works fine.
<abentley> Not that I particularly recommend it.
<abentley> Oh, my bad.
<abentley> There was talk of fixing it.  I thought it had already happened.
<abentley> But If you can't tell which revision is which, why use a vcs at all?
<frsk> I get a deja vu feeling right now. Wasn't empty commit messages discussed on the mailing list recently?
<quicksilver> toed: it's not very hard to set up a shell alias for commit -m '[no message given]'
<quicksilver> toed: or a shell script, if that's more to your taste
<quicksilver> but, I can't imagine why you'd want to?
<dato> quicksilver: a normal bzr alias would do, I have one.
<quicksilver> or that!
<quicksilver> so many choices of indirection :)
<toed> well I'm the only contributor so I thought there was no point leaving a message
<toed> but on reflection you're right, it's probably helpful
<dato> toed: *very*
<quicksilver> I leave brief messages on my commits even on personal projects
<quicksilver> "implemented network support"
<quicksilver> "changed gui to use more colors"
<quicksilver> nothing details, just enough to remind me!
<quicksilver> as I rule I always quickly review the diff before committing
<quicksilver> (C-x V = before C-x V c!)
<dato> quicksilver: I always catch *something* in the last minute review ;)
<quicksilver> yes, I often do
<quicksilver> It's a useful catch
<dato> jelmer: rebase uploaded
<artooro> hey folks, haven't been able to find this information so thought I'd ask here, is there a limitation to the size of file I can commit?
<jelmer> dato: thanks!
<dato> np; leaving now.
<artooro> I'm trying to commit a 4.1GB file and it's failng
<beuno> artooro, the limitation is the amount of RAM you have
<artooro> ok
<Discpile> sounds like you should FTP stuff of that size :p
<artooro> so I guess you guys and git are in the same boat there then :)
<artooro> no actually I want to backup revisions
<artooro> no network involved here
<beuno> artooro, it's a tricky one, yes
<Discpile> why not split the file into more handy bits? :o
<beuno> might be solved in the future
<artooro> yeah, alright.
<jelmer> artooro: nothing should prevent us from doing that, except the focus of development has been on other things
<artooro> that's totally understandable
#bzr 2007-12-09
<quik_> hey folks
<Peng> What folks?
<thumper> Peng: not us
 * Peng goes to watch Walker, Texas Ranger.
<Zindar> morning
<Peng> Good morning.
<Peng> Netsplitty morning.
<Zindar> oh...
<Zindar> szilveszter here?
<dato> Zindar: doesn't seem so. (he's Phanatic on irc.)
<Zindar> ok.. well... he's awake at least :)
<Peng> Hey, cool. Ubuntu ShipIt thinks I've contributed to the Ubuntu community, so it gives me "expanded options".
<Peng> s/community/project/
<phanatic> hello, why is pycurl needed (or at least recommended) by bazaar? does it provide better performance?
<dato> phanatic: I asked the same the other day, to see if I could lower the dependency level on the debian packages, and vila told me the only reason a user would want pycurl (that is, the only thing pycurl can do that the default implementation can't) is verification of SSL certificates
<Peng> What the hell? That stuck 'bzr push' has been running at 100% of a CPU core for hours.
<Peng> What's the key combo to drop into a debugger or do something useful?
<phanatic> dato: that means it could be ignored by a packager? (i have a small issue on osx, since pycurl needs libcurl 7.16.4, but leopard ships only 7.16.3)
<dato> Ctrl+\, I think
<dato> phanatic: I'd say so, yes.
<phanatic> dato: that's good news, thanks :)
<Peng> (and verification of SSL certs will be added in Python 2.6)
<Peng> Traceback after Ctrl+Cing it, FWIW: http://paste.pocoo.org/show/14721/
<Peng> .bzr.log: http://paste.pocoo.org/show/14722/
<sistpoty> hi folks
<sistpoty> stupid question: is there s.th. like cvs's $Id$ for bzr?
<zerok> hi :)
<thumper> sistpoty: not that I know of
<thumper> sistpoty: why do you want it?
<thumper> sistpoty: the general concensus of developers I've talked with is that you shouldn't use expansion like that
<thumper> hi zerok
<Peng> However, there is a blueprint on it.
<sistpoty> thumper: basically to know that vim is in sync with a file... and maybe because I'm used to it *g*
<thumper> sistpoty: hmm... emacs will tell me if it is out of sync and ask if I want to reload
<thumper> sistpoty: does vim not have that?
<Peng> Oh no.
<sistpoty> it does... but I'm rather thinking of not having saved the last bit of experimental code when reviewing/committing with bzr diff... I usually want only what's in the diff (and tested) and not what's in the editor then ;)
<sistpoty> but I can live w.o. that... I guess the main argument is really that I'm used to it, which is a pretty poor argument *g*
<thumper> sistpoty: I'm trying to work out your workflow
<thumper> sistpoty: I guess I just save lots
<sistpoty> thumper: so do I, but stuff happens sometimes... but it's really a corner case (and didn't bite me yet :)
<thumper> sistpoty: yes, stuff definitly happens
<sistpoty> ok, gotta go, cya and thanks for the info
<thumper> sistpoty: ok, by
<thumper> e
<zerok> uhmm.... version_info = (0, 1, 0, 'candidate', 2) O_o
<zerok> shouldn't it be more something like (1,0,0, ...)?
<thumper> zerok: :)
<thumper> zerok: I'll make sure the right person gets notified
<zerok> thumper, just skimming through the bug reports :) tnx :)
<weasel> how do I tell bzr to use a different ca-certificates file (for https), or tell it to accept cert with fingerprint $fpr for a host?
<zerok> thumper, should i file a bug report for the 1.0rc2 package?
<thumper> zerok: I'm just confirming
<zerok> thumper, the version number in the bzr script is set to 0,93,0 whilte the bzrlib is set to 0,10,0,rc2
<thumper> zerok: yes you could
<thumper> I've just checked the tar ball
<zerok> thumper, posted some more readable stuff than my version of the english language here: https://bugs.launchpad.net/bzr/+bug/175171
<ubotu> Launchpad bug 175171 in bzr "Version difference in 1.0rc2 test package" [Undecided,New]
<thumper> zerok: ta
<ubotu> New bug: #175171 in bzr "Version difference in 1.0rc2 test package" [Undecided,New] https://launchpad.net/bugs/175171
<Peng> Send a patch to the mailing list. And use 'bzr send' so you get credit! :)
<zerok> creditttt!!! <3
<zerok> omg
<zerok> first i have to find out how i just managed to fubar my python install ...
<zerok> pyrex :-(
<zerok> Peng, never worked with bzr send before :-) let's see how simple it is to make new enemies ;)
<zerok> since i'm probably too stupid to use bzr send with a release-package, i think i will just have to survive without the credit for 2 patched lines ;)
<igc> morning all
<thumper> morning igc
<igc> morning thumper
<Peng> Hmm.
<Peng> Actually, I'm not sure if the release is in any branch.
<zerok> Peng, haven't found a related branch yet. trunk uses 0.93
<zerok> anyway, time for some sleep. good night everyone :)
<Peng> Yeah, bzr.1.0 hasn't been updated.
<poolie> Peng, i just made it offline
<poolie> i'll merge to bzr.1.0 now
<Peng> poolie: Is fixing the version worth an instant 1.0rc3 or 1.0rc2.1 or something?
#bzr 2008-12-01
<mathrick> https://bugs.launchpad.net/bzr/+bug/303820
<ubottu> Ubuntu bug 303820 in bzr "bzr serve fails (IPv6 socket is created)" [Undecided,New]
<mathrick> lifeless: ah
<mathrick> now, lessee if it still eats all my RAM
<lifeless> Peng_: ok if I put that in the branch?
<mathrick> yup, still does
 * mathrick frees up some RAM to see if it succeeds eventually
<lifeless> back after doctor visit
<Peng_> lifeless: Sure.
<mathrick> okay, so it still fails to serve anything, except this time it doesn't even throw backtraces :(
<Peng_> lifeless: Although, I've made two completely unnecessary style changes that don't matter at all since the last version I pasted. http://paste.pocoo.org/show/C5sF67TUM5P1Mw9phfTQ/
<mathrick> okay, so it reports "no repository", that's all I can gather from the packets
<poolie> mathrick: maybe you started it, or limited it to a path, that didn't include the repository directory?
<mathrick> poolie: nope, it's a straightforward "bzr serve" with no parameters
<poolie> iirc it runs in the directory where you invoke it
<mathrick> it happens reproducibly for that repo
<poolie> so you need to make sure you're not standing in one of the branches
<mathrick> "branches"?
<poolie> let's back up
<mathrick> oh
<mathrick> it is in a shared repo, yeah
<mathrick> lemme try with that
<poolie> you must cd to the shared repo directory before running bzr serve
<mathrick> right, it didn't tell me anything when I started it in the wrong dir
<mathrick> it also continues to insist on eating all my RAM, which I don't appreciate
<poolie> it should print something to give you a clue
<poolie> is this with 1.10rc1?
<mathrick> no, 1.9
<poolie> at what point does it use too much memory?
<mathrick> 1) when I start it in the wrong dir (ie. in the branch dir instead of the shared repo dir)
<mathrick> 2) when I start it in the shared repo dir
<mathrick> 2) seems to be more severe
<poolie> as soon as you start it?
<mathrick> yes
<mathrick> it climbs steadily
<mathrick> I've started it about 30s ago, and it's at 700M
<poolie> wow
<poolie> are you on unix or windows?
<mathrick> 1300M virt, 700M res
<mathrick> linux, ubuntu
<poolie> please press Control-Backslash in the window where you ran bzr serve
<poolie> you should get a debugger
<poolie> by which i mean, it should say "(pdb) "
<mathrick> lemme run it with BZR_PDB
<poolie> that shouldn't be necessary
<mathrick> ^\ alone doesn't cut it
<poolie> nothing happens?
<mathrick> nope
<mathrick> it's rather slow to react to ^C as well
<mathrick> nope, kill -INT doesn't help either
<mathrick> it just sits there, allocating like crazy
<poolie> mathrick: does strace show anything?
<mathrick> dunno, I can check
<visik7> anyone using bzr-upload + eclipse integration ?
<visik7> I got eclipse exception if auto upload on commit is on
<mathrick> poolie: nope, the last thing it shows is a futex
<poolie> and it's still growing in size?
<mathrick> yes, completely silent
<mathrick> oh, wait, it clones
<poolie> that is bizarre, i don't understand how it could grow without using
<poolie> ah
<mathrick> so it's stat()ing every dir under my ~/Dev, which is a lot of files, but shouldn't really result in such memory usage
<poolie> and this is just when you started it, there's no client doing anything?
<mathrick> yep
<poolie> and there are only stat calls?
<mathrick> I had the same thing when I started it in the wrong dir, btw
<poolie> and C-\ doesn't work
<poolie> if you ^C do you get a backtrace in ~/.bzr.log?
<mathrick> [pid 28773] open("/home/mathrick/Dev/Lisp/cl-rdbms/_darcs/patches/20071026164922-6b9e8-dc57c67fcc6c56c8cb8cf9968ae7598378e3a6c2.gz/.bzr/branch-format", O_RDONLY|O_LARGEFILE) = -1 ENOTDIR (Not a directory)
<mathrick> there are also those
<mathrick> I'll check
<mathrick> I can see lstat64, access, occasional open, and brk
<mathrick> brk being obviously the one responsible for allocations
<awmcclain> jelmer: ping?
<mathrick> but I dunno where it comes from
<jelmer> awmcclain, pong
<awmcclain> jelmer: Quick question about how autoppa and bzr-builddeb work together... I noticed you had an autoppa branch dealing with builddeb, but didn't see the attachment in Bug #252774.
<ubottu> Launchpad bug 252774 in autoppa "bzr-builddeb magic" [Undecided,New] https://launchpad.net/bugs/252774
<jelmer> awmcclain, That was just to be able to build the autoppa package itself using bzr-buildde
<jelmer> it wasn't about integration between the two or anything
<awmcclain> jelmer: Ahhhh. Understood.
<awmcclain> Am I going to screw up my package branch if I run autoppa on the same branch?
<jelmer> awmcclain, I wouldn't recommend it, autoppa's use of tags is a bit strange
<jelmer> awmcclain, also, be warned that it throws away pending changes in your working tree
<mrooney> Hrm, I am trying to add my project to http://bazaar-vcs.org/WhoUsesBzr as it says I can, however it says I am not allowed to edit that page
<mrooney> Do I need to do something special other than create an account?
<awmcclain> jelmer: All right. I'll branch and use autoppa from that.
<mrooney> Oh, now it works after logging in for a third time, never mind :)
<poolie> mrooney: i don't know why that happened, it normally works first time
<poolie> maybe some kind of caching bug
<mathrick> poolie: just for the record, no backtraces in ~/.bzr.log
<mrooney> poolie: I have a rather locked down browser with noscript and no cookies by default so I suspect it was something on my end
<poolie> even from ^c?
<mathrick> not even
<mathrick> and now I need to sleep, I'll followup to the list tomorrow or something
<poolie> mathrick: tomorrow, file a bug with strace running from the beginning of the invocation please
<poolie> in a directory with no confidential file names
<mathrick> will do
<mathrick> I'll try to make a non-confidential repo showing that, if possible
<mathrick> sadly, the biggest dir in there is closed source
<mathrick> so I'll have to make something up of similar structure
<jelmer> I guess that also answers the question of whether bzr.debian.org can start running the smart server :-(
<jelmer> does launchpad utilise the bzr smart server somehow or is it all custom?
<jelmer> or does it just have infinite amounts of memory at its disposal ? ;-)
<Peng_> LP also runs Loggerhead, so my guess is they have infinite amounts of memory. ;P
<Peng_> What are we talking about?
<thumper> jelmer: launchpad does use the smart server
<thumper> jelmer: but not entirely directly
<thumper> jelmer: jml should be able to answer questions on that
<jml> jelmer: we have infinite amounts of memory and a crack team of sysadmins.
<jml> jelmer: actually, memory is a problem for us.
<jml> I've half-mentioned it to #bzr folk before.
<jelmer> thumper, jml: Thanks
<jelmer> I was half-hoping launchpad was using some magic flag in bzr to get the memory usage down
<jml> I would love such a flag.
<jml> jelmer: another issue we have is bzr subprocesses hanging around.
<jml> jelmer: that *might* be an issue with our SSH server though.
<jelmer> I've seen it on samba.org as well
<jelmer> There it's mainly related to connections being terminated abruptly
<jelmer> and some interaction with the fact that the client time and server time are slightly out of sync
<jelmer> which prevents me from actually breaking locks without ssh-ing in
<jml> interesting.
 * jml needs to write a manifesto or something on hosting Bazaar.
<jelmer> I think there would be an audience for that
<jml> jelmer: me too.
<jml> jelmer: it probably wouldn't add much to what I said at the London sprint this year, but who knows, it might help someone solve some of my problems for me :)
<mwhudson> jelmer: what problem does bzr.debian,org have with the smart server?
 * mwhudson feels he is missing context
<jelmer> jml, :-)
<jelmer> bzr+ssh: works fine
<jelmer> but that's mainly because processes are short-lived
<jelmer> and most branches are small
<jelmer> there's been talk about running bzr:// as well
<Peng_> You can do bzr:// with inetd so those processes will be short-lived too.
<Peng_> Or something.
<jelmer> but you lose the advantage that it doesn't have any startup overhead
<Peng_> Right.
<Peng_> I run bzr+http over CGI, meaning there's startup overhead for every request. Whee. :)
<mwhudson> oh right
<mwhudson> yes, we'd like to run bzr:// at some point, and i've had similar thoughts
<mwhudson> i guess you could just fork for each connection...
<Peng_> Why doesn't bazaar.launchpad.net use HTTPS? The rest of the website does.
<jml> Peng_: because it runs in a different webserver and there's no compelling reason to use HTTPS
<jml> Peng_: and at least one good reason not to.
<Peng_> jml: What's the reason not to?
<jml> Peng_: https is slower for end users.
<Peng_> There's a significant difference for bzr over https?
<poolie> sending an https request is several times slower than sending over http
<poolie> and i would expect substantially slower than sending over ssh
<Peng_> Huh.
<jml> poolie: I would be mildly interested in actually experimental data on that last point.
<poolie> mm
<poolie> it should be reasonably easy with -Dhpss
<poolie> ..
<jml> poolie: I expect that establishing an SSH connection takes longer.
<jml> poolie: but, my interest is so mild, I could be a central banker.
<bob2> haha
<poolie> wow nice one spivvo
<poolie> bzr -Dhpss info http://bazaar.launchpad.net/~bzr/bzr/trunk does one hpss round trip
<lifeless> mathrick: you have the bzr-avahi plugin in stalled ?
<lifeless> robertc@tungsten:~$ ./test-mem  bzr 50 500 5000
<lifeless> 50,273516,2173.65908694
<lifeless> 500,319888,498.259073973
<lifeless> 5000,931452,304.59688592
<lifeless> Peng_: whats vmpeak in, MB?
<poolie> hm, actually not quite so nice, there's no smart server there
<spiv> poolie: heh :)
<poolie> the interaction between auto-bzr+http, -Dhpss and log+ is a bit confusing
<Peng_> lifeless: I glanced in /proc a couple times, and it said KB, but I don't know if it's ever something different.
<poolie> jml, sending requests across ssh vs http is approximately the same speed, modulo network variability and measurement error
<poolie> or, eyeballing the numbers error
<lifeless> Peng_: ok, so 270MB, 330MB, 930MB, for bzr
<poolie> i'd expect https will be awful if you don't keep the connection alive
<lifeless> its sublinear, which is good, but a GB is awful large :P
<Peng_> lifeless: You were indexing a copy of bzr.dev?
<lifeless> yes
<Peng_> I got very different numbers when I did it.
<Peng_> When I ran it for 50 and 500, VmPeak was about half of what you got.
<lifeless> Peng_: 32-bit machine?
<Peng_> lifeless: Yeah
<lifeless> 64-bit
<Peng_> Note to self: Don't upgrade to 64-bit without doubling your RAM...
<mwhudson> man
<lifeless> I'm doing another more granular run
<mwhudson> this branch of mine is cursed
<lifeless> get the slope
<mwhudson> push said this to me:
<mwhudson> ShortReadvError: readv() read 0 bytes rather than 185 bytes at 25704 for "00/00/71/72/.bzr/repository/upload/xkxs5h4uy9mq79wr2t1h.pack"
<lifeless> 500 is 50% longer than 5000, and only 10% more mem than 50
<lifeless> so 500 is looking apealing
<poolie> mwhudson: i wonder if that's related to spiv's change for caching when writing out packs?
<poolie> can you file a bug with the traceback please
<mwhudson> poolie: ok
<spiv> mwhudson: and the formats; if poolie's right at least one side will be a stacked branch.
<mwhudson> spiv: the remote side is stacked
<mwhudson> it's all branch7/knitpack5
<mwhudson> spiv, poolie: https://bugs.edge.launchpad.net/bzr/+bug/303856
<ubottu> Ubuntu bug 303856 in bzr "ShortReadvError on pushing stacked branch" [Undecided,New]
<lifeless> probably a plugin if core works doing this
<lifeless> try pushing it with --no-plugins
<lifeless> (plugins can cause a read, its why the cache-change has to be done at transport not the pack writer to work reliably)
<mwhudson> lifeless: same thing with --no-plugins
<lifeless> mwhudson: ok, one theory down
<jml> what does 'f' do in the new shelve?
<spiv> mwhudson: if you edit bzrlib/repository.py, so that InterPackRepo.fetch has "set_cache_size = None" rather than what it currently is, does that fix it?
<mwhudson> spiv: ok
<spiv> If it does, it appears that the issue is that for a target repository to take a delta record and turn it into a fulltext it needs to read from a pack file that's still in progress...
<lifeless> spiv: yes, it will
<spiv> Ideally I think that case would be reading that data out of the local repo, rather than the remote one.
<lifeless> spiv: I don't think thats ideal
<lifeless> spiv: because that requires a) fullduplex and b) the server asking the client for data it already has - when you consider streaming
<spiv> Ok, well that explains why the non-stacked pack-to-pack case can get away with buffering writes and this case can't.
<spiv> lifeless: by "that case", I meant the case where the client is doing the file ops on the local and remote repos.
<lifeless> spiv: mmm, I really hope we can get just one code path to optimise, and having very clear read-from, write-to patterns will help that immensely
<spiv> lifeless: right, one code path would also be ideal
<spiv> lifeless: there can be conflicting ideals :)
<spiv> I'm not going to try decide which is more important, at least not on my week off ;)
<lifeless> fair 'nuff
<spiv> And on that topic...
 * spiv wanders off :)
<spiv> (the cricket is going well, btw)
<spiv> Oh, before I go... mwhudson, if that does fix it (as I now expect it will), make sure poolie knows so he can revert that change for the 1.10 final release.
<jml> spiv: I didn't know you were on a week off.
<jml> lucky devil.
<spiv> jml: accumulating annual leave is good like that ;)
<mwhudson> ah well, at least the wallabies lost
 * spiv really goes
<jml> mwhudson: rugby is a tier 2 sport.
 * poolie looks
<mwhudson> bah
<poolie> lifeless: mark was asking something about getting a dodgy nearly-full-duplex connection over http by using 100 continue responses
<mwhudson> i got BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x1a71780> has delta references to items not in its repository:
<mwhudson>  on pushing again
<poolie> i'm pretty skeptical
<poolie> also i think this has already been discussed
<mwhudson> lifeless, poolie: how can i fix by broken local branch?
<mwhudson> my
<mwhudson> oh
<poolie> actually this is not urgent, and it's probably a silly idea
<mwhudson> it's the remote branch that's messed up, isn't it
<poolie> i think so
<lifeless> mwhudson: branch the parent with a good bzr, then pull your local dodgy branch into the new branch
<mwhudson> lifeless: branching within a repo will be ok?
<lifeless> mwhudson: no
<lifeless> mwhudson: the repo is the thing that is confused
<mwhudson> ah
<mwhudson> right
<Peng_> When you get that "Internal check failed" error, is creating a new repo the only way to fix it?
<mwhudson> well you can also push with an older bzr, which is definitely sneaky :)
<Peng_> I get it under entirely different circumstances (pulling, and before the "Internal check failed" error was introduced, I got a different one), but I thought I'd ask since it was getting discussed.
<Peng_> Not to distract from your issues..
<poolie> Peng_: if it's the one about a newly-created pack file then it should cause the transaction to abort and the repository will be unchanged
<lifeless> Peng_: if you have a repo with a bad delta, there isn't currently a command to fix the delta up
<lifeless> Peng_: 'bad' meaning 'points outside the repo'
<Peng_> lifeless: Okay. ...Will there be eventually?
<lifeless> Peng_: probably, FSVO probable
<lifeless> Peng_: with a repo, just init a new repo, branch --stacked from the original again for all your branches, and pull --overwrite them all in - scriptable
<Peng_> BTW, I'm not using stacking in this repo, AFAIK. :)
<lifeless> Peng_: if its not stacked, you definitely shouldn't have a bad delta. when do you get the error? and what precise error?
<Peng_> lifeless: It's a large repo (Python), and bzr-svn is involved.
<Peng_> Hmm, if I'm reading this right, all the bad deltas are for directories.
<Peng_> lifeless: Still interested?
<lifeless> Peng_: bug filing time!
<Peng_> Eep
<Peng_> Nice timing.
<Peng_> Anyway, like I said, bzr-svn is involved. It's kind of complicated.
<Peng_> There's http://svn.python.org/projects/python/ , Python's svn branches. There's also http://code.python.org/python/ , bzr-svn imports of them.
<Peng_> I created a repo, made my own imports of svn.python.org, and later branched copies of the ones from code.python.org (which, being bzr-svn, are identical to my imports).
<Peng_> With one code.python.org branch, pulling it dies with one of the "Internal check failed" messages. Before that message was introduced, it died with something less useful.
<Peng_> If I pull the equivalent svn.python.org branch with bzr-svn, it works fine and generates the revisions.
<Peng_> So...yeah.
<Peng_> .bzr.log snippet at http://paste.pocoo.org/show/FZSj4YB6aiyVinJfSWfw/ :)
<lifeless> Peng_: definitely file a bug
<lifeless> Peng_: I smell bzr-svn off the cuff
<lifeless> Peng_: a new repo suffers this?
<Peng_> lifeless: I haven't tried.
<lifeless> robertc@tungsten:~$ ./test-mem  bzr 50 500 1000 2000 2500 3000
<lifeless> 50,273520,2107.63493299
<lifeless> 500,319884,498.597379923
<lifeless> 1000,398488,373.639508009
<lifeless> 2000,552916,305.507139206
<lifeless> 2500,622240,302.449185133
<lifeless> 3000,721288,304.617379904
<lifeless> Peng_: ^
<lifeless> flat at 2000+, for bzr.dev
<Peng_> That's interesting.
<lifeless> zooming in on 1K to 2K now
<lifeless> I think we probably need to look at the file group_size too
<lifeless> Peng_: if I can twist your arm a little more :)
<Peng_> lifeless: Unless you want to test combinations of both at once, you could open up index.py, change the first group_size line a little so it won't match the regexp (e.g. add another space before the = sign), and it'll start changing the other group_size.
<Peng_> (or add a space or comment to the end of the line, I guess)
<lifeless> Peng_: well, I can run combinations outside it
<lifeless> Peng_: ideally we'd run both and look for a correation, chi-squared regression or whatever
<lifeless> robertc@tungsten:~$ ./test-mem  bzr 1000 1250 1500 1750 2000
<lifeless> 1000,398492,372.275660992
<lifeless> 1250,424632,334.12329483
<lifeless> 1500,484364,306.166346073
<lifeless> still running
<lifeless> but it looks like 1500 hits a bottleneck of some kind
<lifeless> where it stops getting faster
<lifeless> poolie: https://wiki.ubuntu.com/EtcUsingEtckeeperSpec
<lifeless> Peng_: so -
<lifeless> robertc@tungsten:~$ ./test-mem  bzr 1000 1250 1500 1750 2000
<lifeless> 1000,398492,372.275660992
<lifeless> 1250,424632,334.12329483
<lifeless> 1500,484364,306.166346073
<lifeless> 1750,526364,304.78441
<lifeless> 2000,552908,304.097445011
<lifeless> for bzr.dev at least, 1250/1500 is good, at about 240MB for you
<RAOF> Hm.  Is there any reason for the bzr-search package to be in Experimental but not Jaunty?
<lifeless> none
<lifeless> its perfect as is, release kthx
<lifeless> oh, thats me.. hmm
<RAOF> :P
<RAOF> Builds, installs, works.  Those seem sufficient conditions for asking for a sync at this point.
<lifeless> sync it baby
<lifeless> Peng_: trying the current test-mem on python
<lifeless> Peng_: I'd love to have an option though to control which thing is altered :)
<poolie> lifeless: i don't understand your comment about "not related to the Transport abstraction"
<poolie> i understood John's
<lifeless> poolie: uhm
<poolie> nm, now i do
<lifeless> :)
<poolie> i think you're just reiterating what he said
<lifeless> probably
<poolie> that it's not on transport because it's local scratch space
<lifeless> yes, and also that there isn't any motivation (for me at least) to put it on transport
<poolie> 'it'?
<lifeless> management of scratch files
<poolie> mm
<lifeless> poolie: are we talking past each other, or so violently agreeing we're confusing?
<poolie> the latter
<poolie> it's fine
<Peng_> lifeless: I'm starting to get out of my depth here.
<lifeless> Peng_: no worries, tell you what
<lifeless> Peng_: commit whatever you've got to bzr-search, as e.g. test-mem.py
<lifeless> Peng_: and throw me a bundle/merge-request on lp/whatever
<Peng_> lifeless: I actually have been versioning it (though so far the only commits have been comments and stuff), in my hg repo where I throw random stuff.
<lifeless> Peng_: lol.
<lifeless> Peng_: we so gotta make bzr more attractive for you, for that
<Peng_> lifeless: I'm mostly using hg for historical reasons. Although it's nice that "hg convert" can easily spin something out into its own, independent repo.
<Peng_> (by filtering the history and creating a new repo)
<jml> thread rename pls.
<Peng_> lifeless: What do you /call/ the two group_size variables? "inventory group_size" and "text group_size" or "revision group_size" or something?
<mathrick> <lifeless> mathrick: you have the bzr-avahi plugin in stalled ? <-- yes
<mathrick> should I uninstall it?
<lifeless> mathrick: its trying to share all your branches
<lifeless> mathrick: do you have 'bzr-svn' installed too ?
<mathrick> yes
<lifeless> Peng_: yes, that makes sense
<lifeless> mathrick: ok, so here is whats happening
<Peng_> lifeless: Which ones make sense? :P
<lifeless> mathrick: there is a bzr-svn bug where 'bzr branches' takes a lot of memory up
<lifeless> Peng_: 'revision group_size' and 'text group_size'
<lifeless> mathrick: and bzr-avahi uses 'bzr branches' to find the branches to share
<mathrick> oh
<mathrick> I see
<Peng_> lifeless: The former for _index_revisions and the latter for the other method?
<mathrick> I'll remove bzr-avahi for now, I don't use it anyway
<lifeless> mathrick: uninstalling *either* will fix your problem :P. Probably subscribing to the bzr-svn bug would be a good idea.
<lifeless> Peng_: yes
<mathrick> lifeless: https://bugs.launchpad.net/bzr-svn/+bug/54253 ?
<ubottu> Ubuntu bug 54253 in subversion "Excessive memory usage in python-subversion" [High,Fix released]
<mathrick> btw, is there a way to serve only some branches in a repo?
<poolie> mathrick:  bzr_access, i think
<poolie> lifeless: nice to see you invalidating your own bug 181367 :)
<ubottu> Launchpad bug 181367 in bzr "bzr update should work in a treeless bound branch" [Low,Invalid] https://launchpad.net/bugs/181367
<poolie> i'm glad i didn't work on it any further
<mathrick> poolie: is that a command or a plugin?
<lifeless> poolie: ah yes, well I claim temporary insanity
<lifeless> poolie: perhaps having it work-when-it-can would be good, but I suspect too-much-effort for now
<poolie> missing smiley here: :-)
<poolie> that's what i concluded when i looked into it
<lifeless> mathrick: its a addon in the contrib directory
<poolie> mathrick: it's a script in contrib in the bzr distribution
<lifeless> mathrick: no, I don't think thats the byg
<lifeless> *bug*
<lifeless> jelmer: ping; is there a bug for 'bzr branches w/bzr-svn chews ram'?
<mathrick> poolie: re: invalidating bug, reminds me of an anecdote from one of PL unis, one of the professors was appointed dean *and* rector simultanously. Reportedly at one point he applied for funds to himself and then rejected the application
<jelmer> lifeless, yes
<jelmer> lifeless, I think it has "multi-pull" in the description
<poolie> PL=poland?
<mathrick> lifeless, poolie: thanks
<mathrick> yes
<poolie> anyhow, nice to see he can be objective :)
<poolie> we should all do so well :)
<lifeless> amen
<mathrick> are contrib scripts packaged?
<mathrick> jelmer: ah, I've seen one like that
<poolie> maybe into doc/
<mathrick> https://bugs.staging.launchpad.net/bzr/+bug/262513
<ubottu> Ubuntu bug 262513 in bzr-svn ""bzr multi-pull" consumes excessive memory" [Low,Fix committed]
<poolie> no!
<poolie> but they should be
<mathrick> should I file a bug?
<jelmer> ubottu, yeah, that's the one
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<poolie> i will
<jelmer> mathrick, that's the same bug as for "bzr branches"
<mathrick> jelmer: I see, thanks
<mathrick> jelmer: do you have any idea what causes that? The bug is a bit short on that
<jelmer> mathrick, No, I haven't spent time debugging it yet
<mathrick> hmm, it's marked fixcommitted for bzr-svn
<jelmer> hmm, perhaps I fixed it already
<mathrick> it's a pity it doesn't link to a specific revision
<mathrick> jelmer: is trunk supposed to work with 1.9?
<jelmer> mathrick, no, only 1.10
<poolie> bug 303888
<ubottu> Launchpad bug 303888 in bzr "contrib scripts should be packaged" [Medium,Confirmed] https://launchpad.net/bugs/303888
<jelmer> mathrick, it's indeed fixed in the 0.5 branch
<mathrick> I see, and 0.5 is the 1.10-only?
<jelmer> yes
<mathrick> okay, that confuses me
<jelmer> why?
<jelmer> 0.4.15 should work with 1.9
<mathrick> not the branches, something else, sorry for being confusing myself
<mathrick> jelmer: does it have the fix committed?
<jelmer> mathrick, 0.5 does, yes
<mathrick> 0.4.15 I mean
<jelmer> no, the fix is only in trunk/0.6
<jelmer> *0.5
<mathrick> ok
<mathrick> http://pastebin.ca/1272124 <-- could someone explain?
<Peng_> lifeless: I'll turn my index thingy into a regular bzr command later, so I can take advantage of the option infrastructure and make it possible to alter either group_size, but anyway, I'd rather watch TV right now. :P
<Peng_> (I don't have experience with bzrlib's command stuff, but anyway, I'm sure I'll manage to half figure it out. :P )
<jelmer> mathrick, you can't list the contents of something that's not a branch/workingtree
<mathrick> oh
<mathrick> right
<poolie> lifeless: quick ping re the reconfigure rfc
<poolie> if you still exist
<lifeless> Peng_: thats cool; just shove it in the tree and I'm happy.
<lifeless> poolie: yes, walking up the street - can you ring my mobile ?
<poolie> np
<mathrick> has anyone used TortoiseBzr?
<mathrick> http://bazaar-vcs.org/TortoiseBzr/Screenshots shows a dialogue for creating a new checkout, but I can't find it hooked into explorer anywhere
<jelmer> poolie, bzr reconfigure --stacked-on seems like a good idea, indeed
<mathrick> which is kind of important to have my boss have something clickety for all steps
<CXI> Hi! I'm getting some strange behaviour from the 1.9 windows installer. I already had python installed, which was recognised by the installer and it installed everything in my python library path. That's all fine, but it doesn't seem to have installed the bzr-svn plugin.
<CXI> I keep getting "unable to load bzr-svn" messages, coupled with some stuff about being unable to load "svn" from my python library path and a "cannot import name client" for good measure
<awmcclain> Is there a version of bzr-email that works with 1.9?
<vila> hi all
<poolie> markh^^
<poolie> awmcclain: the current one does not?
<poolie> hi vila!
<vila> hey ! :)
<awmcclain> poolie: Ungh. Sorry. It's been a long day of staring at debian packages. Let me go check the branch.
<CXI> oh, wait... that's a lie, it does seem to have installed the plugin - I just found it in bzrlib\plugins, but it doesn't seem to have any compiled libraries (which client is)
<mathrick> CXI: FWIW, it doesn't seem to work on a (non-programmy) Win32 I installed it on either, presumably subversion isn't installed
<markh> poolie: I'm afraid I've never looked at the Python based installer
<markh> it appears the svn binaries aren't installed though
<markh> poolie: Where are these binaries made?  It would appear its not our shared host due to the lack of the compiler I mailed about today...
 * markh can never remember how to spell that host name without looking it up :)
<CXI> hm
<CXI> I wonder if there's a way I can get into the installer
<CXI> could be it tried to put them somewhere I'm not looking
<markh> CXI: I think I can find the binaries
<markh> they "should" be in the bzr-svn directory I think
<markh> CXI: if you grab svn-win32-1.5.4.zip from http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91, it should have the binaries you need.  You will probably want to copy the 'bin' directory to the bzr-svn plugin dir
<markh> (it will probably have more than you need, but it will get you going :)
<CXI> hm, are you sure? that bin directory looks awfully similar to the python-svn bindings I already have installed, and not very similar to the [editor,client,ra,repos,util,wc] compiled python library files I don't have
<markh> CXI: I'm misunderstanding the problem then :)
<CXI> yeah, I think I'm only just starting to figure it out :/
<markh> bzr-svn doesn't depend on the python-svn bindings
<markh> so they may not be being found
<markh> ir binds directly to the svn api
<markh> it
<CXI> ah, well I'll give it a shot
<CXI> "cannot import name client" says to me something about missing python libraries, though
<CXI> they're in, no difference :/
<CXI> the bzr-svn package is part python and part c libraries, right?
<markh> CXI: yeah - right - it appears you are missing all the extension modules :(
<markh> client.pyd is part of the c implemented stuff.
<markh> I could put one up on the web for you to see if it helps :)
<CXI> sure, that'd be great :)
<CXI> I just realised I can open the installer as a zipfile
<CXI> there aren't any files that look like c extensions in there
<markh> CXI: right :(
<markh> as I said above, sadly I've never tried it
<CXI> ah
<markh> http://starship.python.net/crew/mhammond/client.pyd might help
<markh> but you probably don't have any of the performance related core extensions either, which is likely to suck :(
<CXI> I wonder if that means the installer is broken
<markh> CXI: right, putting 2+2 together, it appears the machine used to build these recent installers doesn't have the c compiler installed.  I'm actually installing that as we speak!
<CXI> ah
<CXI> bleh
<markh> yeah :(
<CXI> ordinal 284 could not be located in ssleay... time for me to run around in dll hell for a bit
<markh> yeah - check %PATH% for other binaries of the same name
<CXI> rockin', okay, that's fixed
<CXI> but it looks like are a bunch of other extensions it wants
<CXI> asking for ra now
<CXI> if you're fixing the installer, I can wait - no hurry
<lifeless> wow, python bzr-search index @ 50 is taking for-ever
<kingfishr> I'm kind of new to version control. I made a big mistake in the last one or two commits. How do I browse my commit messages and compare the files?
<markh> CXI: still here?
<CXI> sure am
<kingfishr> (i'm not sure where I want to revert to)
<markh> ok - I should have looked - there are 4 .pyd files in bzr-svn - I'll zip 'em
<markh> CXI: bzr-svn-pyds.zip in the same palce
<markh> kingfishr: try, "bzr log", then "bzr diff -rrevno:xxx" where xxx can be seen from the log output
<markh> if you have a gui extension installed (eg, pygtk or pyqt), using its equivalent might be better
<markh> s/py/bzr/ :)
<kingfishr> markh, ok thanks...figured it out
<CXI> hey, rockin', that appears to have done the trick
<kingfishr> yay having version control...I would have been so screwed without it :P This is the first time I've been really glad i had it.
<CXI> markh: out of curiosity, what does dir /s /a /b "c:\path\to\bzrlib\*.pyd" give you?
<CXI> I'm wondering specifically about those performance-enhancing dlls
<CXI> but just in case there's anything else that will trip me up
<CXI> I've got five other than the ones you sent me: _btree_serializer_c, _dirstate_helpers_c, _knit_load_data_c, _patiencediff_c, _walkdirs_win32
<markh> I don't actually have a "python" install of bzr around.  Only source trees and binaries.  There are certainly some perf related ones missing, but nothing else leaps out.
<markh> (there are 50 .pyd files in my binary distro, but many of them come with python, or should come with packages you've already optionally installed, such as pycrypto, pyqt, etc)
<markh> actually > 50
<CXI> interesting
<CXI> so how's your binary distro related to the windows standalone installer?
<markh> binary distro is completely stand-alone
<markh> uses py2exe to create .exe files etc
<CXI> oh, jesus, wouldn't you believe it
<CXI> I thought I'd gotten the standalone installer
<markh> but I fear the 1.9 binary install will have the same problem :(
<markh> it appears to have come from a machine with the compilers.  I've not tested the installers I didn't make, and 1.8 was the last one I personally did.
<CXI> somewhere along the line I convinced myself it was *so* clever that it recongised my existing python install and just put itself there
<markh> I think you grabbed the wrong installer - it should be completely independent of any Python's installed
<CXI> yeah, I did
<CXI> damn click-the-top-thing-it'll-be-fine mentality
<CXI> that said, I suppose the problem ended up being independent of that
<markh> but I do think a 1.9 binary will have the same problem - or else I'm quite confused about how it was built
<markh> 1.8 binaries are known to be good.
<CXI> anyhow, I'm pulling down a copy of the standalone so I can take a look and see if I'm missing anything particularly egregious
<markh> (for some definitions of "good" ;)
<CXI> so I'll let you know if the binaries are in there
<CXI> by which I mean I'm heading home now so look forward to that news later on :D
<CXI> thanks for all your help - I appreciate it
<mathrick> who knows something about bzr win32 installer?
<mathrick> it doesn't seem to register the TortoiseBzr shell extensions
<mathrick> which makes including it rather pointless
<CXI> markh: looks like the standalone does have all the compiled extensions
<markh> CXI: interesting...  good to know - thanks.
<CXI> no problem... incidentally, any idea where I'd want to look for a list of the performance-related ones?
<markh> not really - but look for _btree_serializer_c.pyd, _helpers_c.pyd, _load_data_c.pyd, _c.pyd and _win32.pyd
<markh> hrm - that 2nd-to-last one looks suspect...
<CXI> interesting
<CXI> looks like most of those, or at least similar ones, were in the python installer
<CXI> oh, right, you lopped off the first part of each
<awilkins> Hmm, who builds the Python-flavoured windows installer now?
<awilkins> I have a working build process for it here, apart from the "extras"
<awilkins> I never got TBZR to work properly after I built it.
<mathrick> awilkins: it has issues in the windows installer as well
<mathrick> I'm trying to make it work, so far with little luck
<awilkins> The bzr-svn SVN client extensions are not packaged in the python-flavoured one, I just delete the folder.
<awilkins> Or it moans about not having built it forever.
<mathrick> yeah, that is a good idea probably
<mathrick> I need to try with the standalone installer
<awilkins> I think Windows needs a bit of package'n'distribution loving
<AfC> a bit?
<awilkins> Heh
<awilkins> I was under the impression that Canonical wanted to move the building of the win32 packages in house, onto a VM or something?
<mathrick> whatever works, I just want tbzr working off the shelf, it's really rather useless having it without registered extensions
<markh> there is a canonical "owned" machine we are using for builds now to less rely on any individual.  It seems that process does indeed need some lovin' tho...
<markh> awilkins: can you recall what issues you had?
<awilkins> markh: It would crash ; sorry not to be specific. I got it building and wrapped into the exe installer, but it didn't work after installation
<markh> awilkins: can you recall what crashed?
<awilkins> I didn't have time to probe further as I don't use it ; I was interested from the POV of my users who could do with some GUI lovin' :-)
<markh> or when?
<markh> what were the symptoms?
<awilkins> It was right at the shell integration level I think
<awilkins> But I can't recall well, this was a while ago
<awilkins> about 1.6 time I think
<awilkins> On Vista Business 32
<awilkins> I built it with the MSVC 7.1 compiler ; do you use mingw?
<markh> nope - I use the same MS compiler version used by Python itself.  The "good" news is that the next version will have a c++ extension that will have no hope of building under mingw ;)
<awilkins> What, of TBZR or Python?
<awilkins> I presume TBZR since Python 2.6 is out already :-)
<markh> the truly good news with that though is that there are zero external deps other than windows itself - not even the crt - so it will be much less reliant on a "friendly" environment.
<markh> the "shell extension" (ie, dll loaded into almost *any* arbitrary process) part of the jigsaw...
<awilkins> I found it a right PITA to get Jelmers SVN client wrappers built for a while.
<awilkins> Mostly because of the primitive nature of the MS compiler, I fear
<markh> bzr-svn has built from sources for a while now - but roughly since 1.6-ish time, which is about when you said you checked.  setup.py should now have recent and current instructions that work.
<awilkins> Yes, although the tip of 0.5 needs a few minor kicks to get started and I've not got it working yet
<markh> about 3 env-vars and 4 .zip packages from tirgirs.org later... ;)
<awilkins> Built, yes, working, not
<markh> I just tried today and had no such problems...
<awilkins> 1.5 or 1.46 SVN?
<markh> heh - quite possibly :(
<markh> lack of svn:externals support means I can't personally use bzr-svn day-to-day yet...
 * markh tries not to mention lack or windows-line-ending support means he can't use bzr itself for "real world" projects yet either :(
<awilkins> Meh, to be honest, I'm not especially fussed about that, but I've never really been on any cross-platform projects
<awilkins> But I would think you can work around it by using tools that are not stupid and rude about line endings.
<awilkins> (whether they are available is another point)
<CXI> hm
<markh> I can't see a way - case in point, I have launchpad mirroring a cvs repo that is primarily used on windows.  My windows checkouts of the bzr mirror differ in each and every line from the real cvs trunk.
<markh> any project that already has \r\n line-ending is SOL from bzr's pov :(
<awilkins> Is that because CVS forces *nix line endings at the back though
<markh> it is because the same checkout on linux has different line endings than the same checkout on windows, yeah
<CXI> surprised there's not a line-endings plugin
<awilkins> (I have some rusty familiarity with the internals of CVS from having to covert a commercialised subspecies of repository)
<markh> I'm not sure where the magic happens - but a cvs co on linux has \n line-ending, but the same checkout on windows has \r\n.  But, if the bzr mirror is created on linux, a windows checkout of that bzr branch has \n line-endings
<awilkins> So your bzr working tree has *nix endings and your windows CVS tree has CRLF?
<markh> yep
<awilkins> Can your tools work with the *nix endings?
<markh> well - the bzr mirror created by launchpad has \n line-endings, and the bzr co/branch has \n regardless of os.
<markh> most can - except the unix tools, like diff.exe, which need special magic, if you are lucky, to ignore those differences.
<awilkins> Do you need both trees?
<awilkins> I suppose you can't commit to the bzr tree
<awilkins> Being a mirror
<awilkins> Or rather, push from it to the CVS repo
<markh> correct - cvs is the "canonical" <wink> source.  The mirror is supposed to help me merge tricky stuff, but sadly it doesn't
<markh> the mirror, and my copy of the bzr branch, always differ on every single text file :(
<awilkins> Hmm ; you ever used Beyond COmpare?
<markh> oops - "the mirror and the real trunk"
<markh> "real trunk" as it is a windows-based project - regardless of what the server stores...
<markh> I've no interest in fancy tools to help with this problem ;)
<awilkins> Fair enough @:-)
<markh> cvs remains the trunk and what I care about
<uws> hmm
<uws> bzr refuses to let me add files named '..\index.html'
<awilkins> I mention it solely because it does a very nice job of comparing files with differing line endings
<markh> but I'm fairly confident that the eol-support, as planned and described, should solve the problem.
<markh> yeah - good tools would help if I had to work around this problem - but I don't - I just can't use a launchpad-based bzr mirror of a windows-base cvs project in any practical way atm.  I've figured I'll just be patient for bzr to grow that support...
<markh> and when it *does* work, migrate that cvs repo to bzr once and for all :)
<awilkins> Just another thing that's CVSs fault really :-)
<awilkins> I suppose you could take a cvs-fast-export and munge it
<awilkins> If such a thing exists
<markh> actually, I'm not sure about that - all files without "-kb" get "native" line-endings.  What is wrong about that?
<awilkins> Because it's destroying the original line endings?
<markh> somewhat ironically given its age, cvs does exactly what I expect
<awilkins> I prefer the SVN way of doing it ; don't mess with the file content AT ALL unless told to explicitly.
<markh> destroying how?   I guess you could argue the CVS checkout on linux is broken as it "only" has \n line endings on text files, but I can't see how ;)
<awilkins> Well, suppose you grab a checkout on Linux and open the files in a Windows VM sharing that folder - VB6 would choke, for example/
<awilkins> Because it hates having it's line endings messed with
<markh> well, that seems somewhat theoretical given "diff.exe" chokes today
<awilkins> The underlying problem is that CVS saves diffs as "ed" commands and that isn't ending-agnostic, so it wants to make everything comply with *nix line endings.
<markh> "-kb" with vcs sucks, as does "svn:eol-style" - but at least they both exist :)
<markh> oops - s/vcs/cvs/
<markh> hrm - recall the windows cvs co has \r\n - so as mentioned, I'm not sure where that happens, but I'm glad it does.,
<awilkins> I think it happens in the client
<awilkins> The actual RCS storage seems to have LF endings
<awilkins> And I think it's basically a #define in the source (but I haven't personally looked)
<awilkins> I shall add it to my list of reasons I'm happy I've never used CVS extensively :-)
<markh> :)
<markh> I believe that if the launchpad cvs->bzr mirror process happened on a windows box, both the repo, and working trees on all OS's would have different line-endings.  The fact it doesn't means I'm, practically, SOL on Windows best I can tell.  Shops that can't guarantee their tools also handle \n line endings are too in the short term.  I'm not trying to complain, but also trying to counter any arguments it doesn't matter in the real world for
<awilkins> I think if it happened on a Win box, all the line endings of non-binary files would be CRLF
<awilkins> And all bzr checkouts on all OS would also have them
<markh> correct - but it happens on a linux box, so my windows branch also has \n
<markh> hence the problem
<awilkins> Which is nasty if your tools hate that, and nasty because your CVS is still live
<markh> and means in the general sense, diffs between the 2 working trees must use smart tools, or else they fail.
<markh> and trying to apply the same patch between the 2 trees will also fail
<awilkins> cvs2svn has a fast-import compatible out-filter ; you could munge the line-endings back and migrate the whole history to bzr :-) (but not necessarily pracical)
<awilkins> Yeah, you really need a line-ending-agnostic diff/patch
<awilkins> Or EOL munging in bzr :-)
<markh> yep :)
<thrope> is jelmer about? or any bzr-svn people... got this traceback trying to commit http://pastebin.com/m13240b95
<jelmer> thrope, known bug with checkouts in bzr 1.9
<jelmer> it'll be fixed in 1.10
<thrope> ok thanks
<thrope> just found the bug actually - so I can unbind, commit and push
<lamalex> Hi, are any of the loggerhead people around?
<lamalex> I submitted a bug report a few weeks ago on LP with a patch and it has had 0 activity
<jelmer> lamalex, what bug ?
<lamalex> https://bugs.launchpad.net/loggerhead/+bug/297930
<ubottu> Ubuntu bug 297930 in loggerhead "When browsing revisions, next should go up, previous should go down, numerically" [Undecided,New]
<lamalex> jelmer: ^
<jelmer> lamalex, I think the problem may be that there is no agreement that this patch is desired, since next and prev are correct atm from the pov of the tip of the branch (which loggerhead displays first, by default)
<jelmer> lamalex, You may want to ping beuno or mwhudson_ when they're around
<lamalex> jelmer: I don't think that next or prev are correct, even with that pov
<lamalex> if you're at the top, the head, there should be no next
<lamalex> picture yourself at the top of a flight of stairs, you can step down the the previous stair, but there is no next stair available
<jelmer> lamalex, the steps down then are the "next" steps, as you are on your way down
<jelmer> and the previous steps are the steps up as you have already passed them
<lamalex> but if your steps were numbered, going "down" from 9 to 10 would be confusing
<lamalex> and is
<jelmer> I disagree, I don't think "next" implies an increasing number
<lamalex> next implies forward motion
<lamalex> at least when paried with previous
<jelmer> and that's exactly how it is at the moment
<lamalex> s/paried/paired
<lamalex> no, it's reverse motion
<jelmer> If you are on the first page from loggerhead, it's confusing to have to press "previous" to go to the next page of revisions
<jelmer> it's forward motion since the direction you are going into is from the tip to the beginning of the branch
<lamalex> no it's backward motion, you're just starting from the other end
<jelmer> we are also showing the revision with the highest number on the top of the page and the one with the lowest number on the bottom
<lamalex> well if you're looking at it in terms of pages it's forward but that's a silly perspective, you need to think in terms of revisions
<jelmer> that would conflict with your reasoning as well
<jelmer> anyway, I'm not a loggerhead developer so I can't make this decision but that's what my view on it is at least :-)
<lamalex> :) like I said, even if they dont accept the patch I'd at least like acknowledgment by them
<lamalex> it's not very encouraging to submit a patch and just be ignored
<jelmer> lamalex, ping beuno or mwhudson_ here later today (they're most likely not around atm)
<lamalex> Will do, thanks
<Jc2k> jelmer: have you fixed any bzr-svn HTTP redirect related issues recently?
<jelmer> Jc2k, fairly recently, yes
<Jc2k> i have one where it is doing an OPTIONS on /$module/branches and then stopping looking after it hit a 302.
<Jc2k> (bzr-playground_
<jelmer> it should convert any svn redirect exceptions to bzr redirect exceptions
<Jc2k> https://bugs.edge.launchpad.net/bzr/+bug/303959
<ubottu> Ubuntu bug 303959 in bzr "missing redirect handler: no repository found when pulling a branch from bzr-playground" [Undecided,New]
<jelmer> Jc2k, it was something similar to that that I fixed earlier
<jelmer> Jc2k, have you tried 0.4.15?
<Jc2k> i have 0.4.15dev0
<CaMason> could somebody just explain the branching concept to me in this situation? I have a branch that I've bound to a central location. It's at /srv/bazaar/myproject/trunk. Let's say I now want to make a (svn branch) to build some features outside of the trunk..
<CaMason> how would I go about that, and how does that relate to my original 'branch' (trunk)
<Jc2k> jelmer: trying a 0.4.15 final tarball now..
<jelmer> Jc2k, when cloning that branch, I get two messages saying http://bzr-playground.gnome.org/gtk%2B/branches/ is permanently redirected to
<jelmer> but other than that it seems to work ok
<Jc2k> jelmer: branch works, then a subsequent pull fails
<CaMason> I believe I set up my central folder with --no-trees
<Jc2k> CaMason: where to svn come in to this exactly?
<CaMason> Jc2k: In my head, that's all. I'm used to SVN and I'm comparing to bazaar concepts to see how they differ
<Jc2k> CaMason: publishing a branch to a server with a --no-trees repository is covered here: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<jelmer> Jc2k, I think I found it
<jelmer> Jc2k, bzr's RedirectRequested requires a full new URL whereas svn is only giving a relative one sometimes
<CaMason> so, with reference to this section, how should I go about creating a /branches/mybranch1 'branch'? http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#choosing-a-shared-repository-layout
<Jc2k> jelmer: ah.
<CaMason> so I need to bzr-init branches bzr-init branches/mybranch1 ?
<CaMason> do*
<Jc2k> no need for bzr-init branches
<CaMason> ok just make folder?
<Jc2k> yep
<CaMason> or not even that?
<CaMason> ok nice. So, when I merge that particular branch with the 'trunk' branch, will the history move across also?
<Jc2k> yes
<Jc2k> make sure you did a bzr init-repo in the root folder
<CaMason> great, so then I could delete the 'branched' branch
<Jc2k> bzr init-repo myproject
<Jc2k> bzr init-repo myproject/trunk
<Jc2k> etc
<CaMason> how can I check that?
<Jc2k> whoops
<Jc2k> 2nd command was meant to be just init *blush*
<LarstiQ> CaMason: `bzr info`
<CaMason> Shared repository with trees (format: pack-0.92)
<Jc2k> jelmer: shall i reassign my bug to bzr-svn :)
<CaMason> I thought I made my repository with --no-trees. Would that suggest otherwise?
<LarstiQ> CaMason: yes, that suggests otherwise.
<jelmer> Jc2k, already happened :-)
<CaMason> ok I suppose I should fix this
<Jc2k> =p
<Jc2k> jelmer: and you fixed it already too :p
<CaMason> sorry I'm slightly confused as to whether I need the no-trees options
<LarstiQ> CaMason: if you don't care, either is fine.
<CaMason> I'll pastie my layout
<LarstiQ> CaMason: with trees disk size will be bigger.
<jelmer> Jc2k, looks like it's not just bzr-svn though
<Jc2k> jelmer: i thought i caught pycurl returning relative urls..
<CaMason> Here's how I envisage my layout: http://pastie.org/327827
<CaMason> would anybody be able to give me an idea of which commands I *should* be using?
<LarstiQ> CaMason: bzr init-repo /srv/bzr/myProject;
<zooko> Greetings, folks!  I'm trying to push a change to lp, and it says it can't because I'm using HTTP. How do I tell it to go ahead and use ssh, or whatever it is that it needed to push changes?
<luks> zooko: how are you pushing it to lp?
<LarstiQ> CaMason: trunk, branch1, branch2, and both releases would then just be branches
<LarstiQ> CaMason: so either init, branch or push them to their location.
<CaMason> LarstiQ: OK that makes sense. What about the 'containing' folders?
<CaMason> so the 'branches' and 'tags' folders
<LarstiQ> CaMason: the containing folders need no special treatment
<LarstiQ> CaMason: either mkdir them on the server, or supply --create-prefix when pushing a branch
<CaMason> LarstiQ: aha, thanks that's making sense now
<LarstiQ> CaMason: they are just regular directories after all.
<CaMason> yeah, that's what's causing me the confusion I think.. vs SVN :) I think directories are tidier. Seperates the history and 'branches' from the project structure
<Jc2k> of course, you dont need the tags folder.
<CaMason> no?
<Jc2k> read bzr help tags
<CaMason> will do
<Jc2k> and bzr help tag
<LarstiQ> the tags folder would be for svn style 'tagging', which is fine in itself, but not necessary.
 * LarstiQ goes afk
<CaMason> Ah i see
<CaMason> I assume that would take up less disk space also?
<Jc2k> i dont know about that kind of stuff :)
<CaMason> ok thanks LarstiQ and Jc2k that's helped me a lot
<zooko> luks: I think I should push over ssh.  Is that how things are done?
<luks> zooko: I meant what command do you run?
<luks> zooko: e.g. if you are using `bzr push lp:something`, you need `bzr launchpad-login USERNAME`
<luks> zooko: but if you are using a full URL, just change the protocol
<luks> (to bzr+ssh or sftp)
<zooko> luks: Ah, thanks.
<CaMason> I founf SFTP to be a very easy way to share projects :D
<CaMason> found*
<zooko> Hm.
<zooko> HACL yukyuk:~/playground/pyOpenSSL/buildbinaries$ bzr launchpad-login zooko
<zooko> HACL yukyuk:~/playground/pyOpenSSL/buildbinaries$ bzr push zooko@lp:~zooko/pyopenssl/buildbinaries
<zooko> bzr: ERROR: Parent directory of zooko@lp:~zooko/pyopenssl/buildbinaries does not exist.
<zooko> You may supply --create-prefix to create all leading parent directories.
<zooko> I don't understand that error message.
<jelmer> Jc2k, It's working here now; I've commented in the bug
<jelmer> Jc2k, thanks for tracking this down
<Jc2k> jelmer: no no, thank you :)
<zooko> So, bzr apparently knows that I got the current working directory over HTTP.  How do I tell it that I am going to push it over ssh, so that I can do things like "bzr commit" without getting this error message: $ bzr commit
<zooko> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ezooko/pyopenssl/buildbinaries/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
<james_w> zooko: "bzr bind lp:~zooko/pyopenssl/buildbinaries"
<zooko> Thanks!
<james_w> the "lp:" is writeable now because you did the launchpad-login, but it saved the http:// url to disk, "bind" just tells it to save the new (bzr+ssh://) url
<zooko> Thanks.
<zooko> Howdy abadger1999.
<abadger1999> zooko: Howdy
<marcoil> bzr-gtk asserts with brz-svn branches, is this known?
<jelmer> marcoil, What command exactly?
<marcoil> jelmer: I've tried visualize and gcommit
<jelmer> marcoil, both work fine here - how does it assert?
<marcoil> jelmer: bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
<marcoil> do you want a traceback?
<jelmer> are you using bzr 1.9 by any chance?
<marcoil> jelmer: yes...
<marcoil> I updated to get the latest bzr-svn
<marcoil> jelmer: http://pastebin.be/15139
<jelmer> There is a regression in bzr 1.9 wrt branch nicks, this appears to be causing what you're seeing
<marcoil> also, I have a branch bound to the trunk of a svn repo and another one to a branch of it, but I can't merge between them. It can't find the common ancestor, is there some way of telling it?
<jelmer> marcoil, in bzr-svn 0.4 it's only possible if the two branches are using the same "branching scheme"
<marcoil> jelmer: I can't find much info on that...
<jelmer> marcoil, To put it a bit simpler, if the branches are following the standard svn naming convention (trunk, branches/*) you should be fine
<marcoil> jelmer: if I set both branches svn-branching-scheme, should that work?
<marcoil> the repo is using the /project/trunk|branches/subproject scheme, btw
<jelmer> marcoil: it will work in 0.4, but not without a lot of trouble (you'll need to set the branching scheme the same for both branches and probably re-fetch them)
<marcoil> jelmer: is there any info on the format of svn-branching-scheme? I've changed it but now I get "is not a valid Subversion branch path"
<jelmer> marcoil: see bzr help svn-branching-scheme
<jelmer> that's pretty much all there is
<marcoil> jelmer: that doesn't say a lot, just that there's one named "none" :(
<marcoil> jelmer: thanks for the pointers, anyway
<jelmer> well, branching schemes are gone in 0.5, so I haven't put a lot more work into documenting them
<marcoil> jelmer: oh, that's great. Will that work with old svn servers, though? Also, should I update to 0.5?
<jelmer> yeah, it should work with old svn servers as well (>= svn 1.2)
<jelmer> 0.5 is still in development, although it should be fairly stable
<jelmer> I hope to make a stable release around christmas
<marcoil> jelmer: I'll try with 0.5, then
<marcoil> jelmer: is there a package of it somewhere?
<jelmer> marcoil: no, it's all bleeding edge (lp:bzr-svn/0.5, and required bzr >= 1.10rc1)
<jelmer> marcoil, also, there's an open bug dealing with older roundtripped revisions ("bzr push" into svn using bzr-svn 0.4.x)
<marcoil> jelmer: then not for production use, I guess :) Well, I'll look a little at the branching schemes and if not I'll just merge manually for now. Thanks again!
<jelmer> marcoil, n/p
<visik7> anyone using bzr on a mac ?
<visik7> is it good is it bad ?
<marcoil> jelmer: I finally solved it using a branch list :)
<marcoil> jelmer: the only problem has been losing the connections with previous local branches I had
<jelmer> marcoil, yeah, that's the main problem with branching schemes
<marcoil> jelmer: does that mean that every time I add a branch to the list I'll lose the connections?
<jelmer> marcoil, yes
<marcoil> argh...
<awmcclain> Is there a way to un-bzr remove a file?
<awmcclain> I keep getting the error that it's not a versioned path...
<Tak> revert or merge to a revision where it existed?
<nevans_> I especially like the "Any Workflow": http://whygitisbetterthanx.com/  ;-)
<cr3> hi folks, how can I increase verbosity for bzr? I'm getting a connection refused error message behind a proxy but I can't even see where/how it's attempting to connect to lp
<nevans_> cr3: not sure, but you might get lucky by looking into ~/.bzr.log
<cr3> nevans_: it just shows the output I got from the command line
<cr3> no matter whether I set the https_proxy or http_proxy environment variables, I still get: connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("91.189.90.218")}, 16) = -1 ECONNREFUSED (Connection refused)
<cr3> nevans_: strace seems to be the debug flag
<nevans_> sorry, I've never had to use it behind a proxy...
<nevans_> cr3, "bzr help global-options" says something about -Dhttp
<nevans_> dunno if that would help
<james_w> cr3: are you using "lp:something" when you get the error?
<cr3> james_w: yes
<james_w> cr3: that's a bug in python that it doesn't use the http_proxy for xmlrpc
<james_w> cr3: you can work around it by using the expanded URL
<james_w> bzr+ssh://bazaar.launchpad.net/whatever
<cr3> james_w: cheers, http://code.launchpad.net also works just for branching, which might be sufficient for the person I'm helping
<cr3> james_w: I was just telling that person that I've encountered problems with some python libraries when dealing with https proxies
<jam> mm-mysql__: ping
<mm-mysql__> mm-mysql__: pong
<mm-mysql__> Wow...two underscores
<mm-mysql> That's better
<jam> Good to see you around.
<jam> Just thought I'd see how things are going, and if you would be interested in getting together some time soon
<mm-mysql> Things are good, other than some thugs knocked down our post light Friday night, and broke all four legs on one of our reindeer decorations :P
<mm-mysql> But sure, getting together would be great...what are you thinking? Lunch, or?
<jam> you don't live on reindeer alley, right?
<jam> Sorry to hear about the vandalism.
<jam> Lunch would be fun.
<mm-mysql> jam: Okay, let me look at the calendar, and then talk to the social coordinator (the wife), so I don't schedule something when she thought I'd be home...Give me a day or so to pick some possibilities?
<jam> sounds good
<jam> My noon-time is generally open
<jam> though I'll probably be away the week of the 15th or so.
<mm-mysql> Okay, noted.
<mm-mysql> Working at home sometimes actually *complicates* the schedule :)
<mm-mysql> (people get used to you being around)
<jam> :)
<lifeless> hi jam
<jam> hi lifeless, are you in Mountain View?
<lifeless> not yet
<lifeless> fly tomorrow
<zdobersek> I have a question about moving from SVN to Bazaar. The svn repository is quite big, almost 400 megabytes, and there are also about 40k revisions. As far as I tried to complete the move, I saw Bazaar gets data about every single revision and then applies that data one by one. This get _very_ slow on a repository that big, at least in the way I try to do it - so far I've tried with "bzr checkout" (which gets even slower when downloading data f
<lifeless> vila, bug 255687, I'm not sure its a log issue?
<ubottu> Launchpad bug 255687 in bzr "Please allow annotating removed files" [Medium,Confirmed] https://launchpad.net/bugs/255687
<lifeless> zdobersek: your text cut off at "when downloading data f"
<zdobersek> I'll reposte it in parts.
<zdobersek> Or at least the last part.
<zdobersek> This get _very_ slow on a repository that big, at least in the way I try to do it - so far I've tried with "bzr checkout" (which gets even slower when downloading data from a web server) and "bzr svn-import", but both take an enormous amount of time. Is there any faster way or should I leave my computer on and processing for the night?
<lifeless> if you want to migrate, I suggest using 'bzr svn-import'
<lifeless> this will convert all your branches at once. And yes, leave it running overnight, if that what it needs
<Peng_> zdobersek: What version of bzr-svn?
<Peng_> zdobersek: FWIW, older versions of bzr-svn might leak a lot of RAM on a repo that large.
<zdobersek> Peng_: 1.6.1
<Peng_> zdobersek: That's bzr, not bzr-svn. Check "bzr plugins".
<zdobersek> Peng_: 0.4.13
<Peng_> OK. Carry on then.
<lifeless> robertc@tungsten:~$ ./test-mem python 50 500 1000 2000 2500 3000
<lifeless> 50,746876,33720.086226
<lifeless> 500,727064,6420.87136602
<lifeless> 1000,819836,4832.82598305
<lifeless> 2000,806848,3699.43931794
<lifeless> 2500,708820,3237.27468991
<lifeless> 3000,736232,3597.21533608
<lifeless> Peng_: ^
<lifeless> flattens out around 2500
<lifeless> Peng_: I *think* its noise on the last three
<lifeless> Peng_: I think I'll bump it to 1500 which seems to be well past the 'too small' size, and doesn't use *more* silly-scale-more memory on python than '50' does.
<jam> lifeless: what is that test?
<lifeless> jam: group_size,peak_memory_kb,time for bzr index
<Peng_> Erk, 700-800 MB to index Python? Fun.
<jam> lifeless: that is the "bzr search" index time, right?
<Peng_> jam: Right.
<jam> It is, indeed, interesting that the memory consumption goes down a little bit with increased group size
<jam> probably depends on exactly how the keys fit together
<lifeless> jam: it uses repo.make_mpdiffs
<lifeless> jam: so that peak is likely actually revno 1
<jam> lifeless: it doesn't help that make_mpdiffs combines and re-splits all the lines
<jam> it uses _get_lf_split_line_list
<jam> which does
<jam> [StringIO(t).readlines() for t in self.get_texts(version_ids)]
<jam> so it reads everything into lists of lines (because that it how knits work)
<jam> then combines them together to create a single string per text
<jam> then breaks them back up again into lines
<jam> It *might* only hold the reference to one at a time
<jam> so you get 2x the mem of a single text, but not 2x the mem of all texts
<lifeless> indeed
<lifeless> I think its size(tree) + size gzip-records-for-group-size
<lifeless> jam: standup?
<lifeless> poolie: ^
<jam> I was wondering if poolie and/or spiv were around today, but I believe spiv is away
<lifeless> poolie is
<spiv> jam: yeah, I'm away this week (despite my habit of hanging around on IRC...)
<bpierre> hi
<jam> lifeless: poolie doesn't seem to be answering, how about if I start it and just call you
<lifeless> sure
<jam> oh, I should actually mention the other big problem with _get_lf_split_line_list is that get_lines is capable of allowing similar texts to re-use the same actual strings
<jam> but that code will force them to be unique strings
<flacoste> i'm trying to write a script that uses bzrlib to extract some information from the current branch
<flacoste> is there some high-level document to explain the major operations
<flacoste> for example, how do I get the branch associated with the current working directory
<lifeless> flacoste: there is stuff on the wiki about the api
<lifeless> flacoste: and the programmers guide too
<flacoste> lifeless: i've looked around, but nothing at that level
<flacoste> the HACKING file seems more about process than anything eles
<lifeless> flacoste: can you describe the level you are looking for?
<flacoste> task-oriented
<flacoste> or the major API
<flacoste> i read the plugin documentation
<flacoste> but it only describes the metadata or plugin structure
<lifeless> there is http://bazaar-vcs.org/Classes which is a conceptual overview of the most important object
<flacoste> that might be interesting
<flacoste> i looked at the api doc
<flacoste> but it's hard to grasp where are the handles into the framework
<lifeless> and http://bazaar-vcs.org/WritingPlugins
<lifeless> and http://bazaar-vcs.org/Integrating_with_Bazaar
<flacoste> bingo
<flacoste> that last one is what i was looking for
<flacoste> exactly what I was looking for
<flacoste> thanks a lot!
<beuno> and, it's in the bzr tree as well
 * beuno hasn't updated that in a while...
<lifeless> flacoste: anything you need added or spend time figuring out is a bug in some form
<lifeless> flacoste: 'pydoc bzrlib.foo' should always be reasonably useful as well
<flacoste> ok
<lifeless> (need added - I am referring to docs about stuff)
<flacoste> yep
<flacoste> any quick way to determine if a working tree doesn't contain any change?
<flacoste> or do I have to check all of treedelta attributes?
<flacoste> has_changed()
<flacoste> ?
<lifeless> yes
<lifeless> actually changes_from is an old api
<lifeless> most things use iter_changes now
<lifeless> tree.iter_changes(tree.basis_tree())
<flacoste> which is undocumented
<lifeless> its very much documented :)
<flacoste> well, not according the apidoc
<lifeless> pydoc bzrlib.tree.Tree.iter_changes
<flacoste> on startship mwh at least
<lifeless> oh ugh, that isn't showing up
<lifeless> let me see
<lifeless> its a doc bug
<lifeless> pydoc bzrlib.tree.InterTree.iter_changes
<flacoste> ok
<flacoste> and btw, "Integrating with Bazaar" says: There are two methods for comparing trees: changes_from and iter_changes. iter_changes is more regular and precise, but it is somewhat harder to use
<flacoste> the last part doesn't especially makes we want to look :-)
<lifeless> it lies :)
<lifeless> anyhow
<lifeless> if you want to know what commit considers a no-change, you have to do a commit; if you want to know if there are no changes that diff would show, len(list(iter_changes)) == 0 will do it
<lifeless> if you want what status does, you need to check len(tree.get_parent_ids()) == 1 and len(list(iter_changes)) == 0
<lifeless> flacoste: (what are you trying to do?)
<flacoste> find the files i need to lint
<flacoste> either the ones modified in the working tree
<flacoste> or if the working tree is clean
<flacoste> all modified files from the submit: target
<lifeless> ok
<lifeless> filter iter_changes for objects with the file_kind[1] element == 'file'
<lifeless> e.g.
<lifeless> for change in iter_changes:
<lifeless>     if change[2] and change[6][1] == 'file':
<lifeless>         lint(tree, change[0])
<flacoste> change[0] is?
<lifeless> [2] is the content_changed flag, [6] is the kind tuple, and [0] is the file_id
<flacoste> lint needs a file path
<lifeless> lint() is a python function
<lifeless> :)
<flacoste> right :-)
<lifeless> tree.id2path(file_id) will give you a relpath
<flacoste> cool
<lifeless> tree.abspath(tree.id2path(file_id)) will give you an abspath
<lifeless> change[1][1] is also the relpath
<lifeless> so you could do lint(tree, change[1][1])
<lifeless> asssuming you did
<lifeless> iter_changes = tree.iter_changes(other_tree)
<flacoste> for the record, i agree that this api is harder to use :-)
<poolie> hello
<lifeless> change[1][0] is the path in other_tree, change[1][1] is the path in tree
<flacoste> a lot of magic numbers in here
<lifeless> flacoste: we'd like to use named tuples, but they are soooo slooooow
<flacoste> i understand why you are using it
<lifeless> hi poolie
<flacoste> but in the integration story, that concerns isn't that important
<lifeless> flacoste: true enough; changes_from will remain supported for a long time I think, there is little motivation to remove it, and as you say its easy for simple things to use it
<flacoste> great, and thanks for getting going!
<poolie> jam, ilfeless, today i was planning to at least make info and reconfigure deal with stacked branches
<poolie> i'm more sure i can get that done today than i am for michael's bug
<jam> poolie: can't you just revert spiv's change?
<jam> I'm pretty sure you diagnosed it correctly.
<jam> Also, you should note that abentley also hit the bug and reported a dupe
<poolie> ok
<poolie> yes, i'm also going to revert the caching bug
<poolie> i was referring to some of the stacking related ones
<jam> ah, ok
<poolie> what are you up to for the rest of this week?
<jam> I'm open to suggestions, but I was going to try to work more on the CHK code
<lifeless> jml: ping if you're around
<jam> starting with making sure things always preserve canonical form
<spiv> +1 for reverting my caching hack, FWIW.
<jam> (atm, I don't believe unmap() does, and I think map() can also fail if the node's size changes dramatically.)
<spiv> (I really should teach irssi not to highlight my name in work-related channels when I'm on leave...)
<jam> spiv: I'm amazed at how responsive you are to a tiny pink number :)
<jam> I at least get an audible notification
<jam> anyway, I'm done for tonight. Catch you guys later
<poolie> markh, i'll ping our admin people again
<markh> poolie: thanks
<poolie> markh, thanks for fixing up the compiler on kerguelen
<poolie> did you build 1.10rc1, or should i?
<markh> np - the full vs2008 is still installing actually
<markh> I haven't actually built anything on that box yet - it sounds like John would prefer to wtick with mingw - although I also suspect bug 303941 is related
<ubottu> Launchpad bug 303941 in bzr "BZR Installer on Windows XP 64 'MSVCR71.dll was not found.'" [Undecided,New] https://launchpad.net/bugs/303941
<markh> poolie: did you or john make the existing ones?
<poolie> john
<Peng_> lifeless: How large were the search indexes for Python?
<lifeless> Peng_: dunno the script delete's them :)
<Peng_> Oh, right.
<lifeless> indexing it manually, tell you in 6420 seconds
<Peng_> Hmm, if it takes 6420 seconds, and uses 700 MB of RAM, it could actually be cheaper to download prebuilt indexes.
<lifeless> 08:06 < lifeless> 50,746876,33720.086226
<lifeless> 08:06 < lifeless> 500,727064,6420.87136602
<lifeless> 08:06 < lifeless> 1000,819836,4832.82598305
<lifeless> 08:06 < lifeless> 2000,806848,3699.43931794
<lifeless> 08:06 < lifeless> 2500,708820,3237.27468991
<lifeless> 08:06 < lifeless> 3000,736232,3597.21533608
<lifeless> so we have tradeoffs
#bzr 2008-12-02
<Peng_> Woah, 50 took 10 times as long as 2500? ...And used more RAM?
<mae^> how do I convert a lightweight checkout into a full branch?
<poolie> bzr help reconfigure
<mae^> ah, thanks
<Toksyuryel> it's almost hard to believe bzr is almost up to 1.10 already
<Toksyuryel> it was barely 1.1 when I first discovered it like 5-6 months ago
<lifeless> Toksyuryel: 1 release a month
<lifeless> Toksyuryel: you must have found a a distro with an older version :)
<Toksyuryel> it was 1.1 when I joined this channel
<Toksyuryel> unless this channel was a distro with an older version :O
<lifeless> then you joined 9-10 months ago  :)
<Toksyuryel> I do have a poor grasp of time
<Toksyuryel> I should inspect my logs to find the real date
<lifeless> Peng_: v
<lifeless> robertc@tungsten:~/python$ du -sh .bzr/bzr-search/
<lifeless> 296M    .bzr/bzr-search/
<lifeless> robertc@tungsten:~/python$ du -sh .bzr/repository/
<lifeless> 213M    .bzr/repository/
<lifeless> Peng_: 2 and mumble hours to index; group_size 500
<Peng_> Yeah, I could download those indexes faster than you could generate them. :P
<Peng_> lifeless: Thanks for crunching the numbers. :)
<lifeless> Peng_: thats at group size 500
<lifeless> Peng_: so, 1 hour to do with group 1500
<lifeless> bbs, fooding
<markh> poolie: do you think it is too late to get the new shell extension (which also gives us 64bit support) into 1.10?  The changes are only to setup.py, the inno installer, and tortoise itself.
<markh> i've a patch ready to send if so
<markh> err - if not :)
<poolie> if it's just adding a new capability i'd say it should wait for 1.11 just on risk-avoidance
<poolie> if it's fixing a bug or regression, maybe 1.10
<poolie> what do you think?
<markh> yeah, it certainly falls more into "new capability" - I don't mind waiting...
<poolie> ok
<poolie> you can still send it now of course
<poolie> since 1.10 has branched off
<markh> yeah - will do
<markh> for the same reason, we should probably let john build using mingw for this release, and once its out I can have less fear of breaking something
<Rolly> Hi guys/girls, I'm having a problem with performing operations on a remote linux 1.9-rich-root branch from my Windows computer. I get this:
<Rolly> ERROR: bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', "Unknown repository format: 'Bazaar RepositoryFormatKnitPack6R
<Rolly> ichRoot (bzr 1.9)\\n'")
<Rolly> On my Windows box, I can use 1.9-rich-root branches locally with no problem.
<lifeless> Rolly: your remote machine is using some version of bzr < 1.9
<Rolly> bzr version on my remote machine reports "Bazaar (bzr) 1.9"
<Rolly> oh sorry, you're right. The bzr in my chroot is 1.8
<lifeless> what does
<Rolly> thanks for the clue
<lifeless> 'ssh machine bzr --version'
<lifeless> heh :)
<Rolly> :D
 * Rolly bangs head
<markh> poolie: I think I've broken kerguelen :(  You familiar with their web interface?
<poolie> yes
<lifeless> yes its broken, or yes you're familiar ;)
<poolie> yes i'm familiar
<poolie> i'm going to check if i can log in
<poolie> markh, it says "The system is not available as the server is currently stopped. You can select another system.0"
<poolie> do you think you specifically broke it, or did it just stop working?
<poolie> maybe the vm host server crashed?
<poolie> i've filed a support ticket
<poolie> markh^^
<markh> poolie: I installed windows updates, and it said it needed to reboot, so I let it, and it didn't come back up.  It had successfully rebooted after the VS install though...
<poolie> ah
<markh> but it does look like a very early error
<markh> the status never changes to "booting"
<poolie> i think they said something about not installing windows updates, but rather letting them do it :)
<poolie> sorry, i should have mentioned this earlier
<markh> oh :)
<poolie> otoh i don't see why that would make it permanently stop
<markh> I can't see that referenced in their support section though
<markh> (I looked for it after the fact ;)
<markh> the server had many security related updates outstanding, which probably isn't a good thing
<poolie> i'm not sure if it was them, or someone else
<poolie> i looked at a few providers
<poolie> i'm looking too
<lifeless> markh: it may have had the 'server will run under VM' 'fixes' outstanding :)
<poolie> and i agree that if their policy is to not just apply them that would suck
<markh> lifeless: :)
<poolie> i can't find anything about it either
<poolie> or in my mail from them
<poolie> markh: "
<poolie> I am looking into this for you now, can you advise if you have installed updates or patches, or any other software prior to the issue presenting ?"
<markh> but I can't find much there at all - eg, the work "troubleshooting" has zero hits
<markh> heh
<markh> yeah - "installed all critical windows updates" :)
<Rolly> Is there a global .bazaar config file location? bzr help files only references ~/.bazaar/bazaar.conf
<poolie> i'll forward the mail to you
<lifeless> Rolly: not currently
<Rolly> darn. OK
<poolie> i'm open to moving to some other provider if they would be better
<markh> it seemed quite fine so far.
<CXI> is there an explanation of the various repository formats somewhere?
<markh> CXI: "bzr help formats" is the best I'm aware of
<CXI> hm, okay... I think I might be missing some conceptual understanding
<lifeless> CXI: you can just ignore the formats unless you are using bzr-svn, or very big projects
<CXI> well, maybe
<CXI> I like to keep a documents directory under version control - it has code for various projects, documents and other junk that I want to keep versioned and backed up
<lifeless> is it 10000 files or more?
<CXI> nope
<lifeless> have you made 10000 changes or more?
<CXI> double-nope
<lifeless> are you using bzr-svn?
<CXI> not yet, but I'd like to
<lifeless> you can ignore formats for now
<lifeless> when you start using bzr-svn you will need to learn a little
<CXI> I should clarify that I installed bzr yesterday, so the "not yet" time period is pretty small :)
<CXI> also, do I need to do anything special to checkout/work on code for an individual project rather than getting the whole repo?
<lifeless> I don't know quite what you mean
<lifeless> branches are individual projects...
<CXI> well, let's say I have documents/code/proj1 and documents/code/proj2
<CXI> if documents is a repo, can I check out proj1?
<Peng_> CXI: You should have made separate branches for proj1 and proj2.
<lifeless> CXI: what do you mean by repo? if you mean something made by 'bzr init-repo' - no, because code/proj1 is probably just a file on disk :)
<lifeless> CXI: or rather, 'repository' is *totally* unrelated to 'I have a branch X'
<lifeless> CXI: you can checkout anything that is a branch.
<lifeless> CXI: you cannot checkout things that are not branches.
<Rolly> if there's a network problem or glitch, will bzr branch detect it and abort?
<lifeless> Rolly: if bzr gets an error from the OS yes
<Rolly> Cool
<lifeless> Rolly: if its transient and the OS recovers the tcp link, bzr will not be aware of the issue
<Rolly> I was just a bit concerned because the spinner wasn't moving
<Rolly> all is well
<CXI> oh!
<CXI> I was calling branches repositories because I didn't understand them properly
<Rolly> a "tree" is a branch + a repository, right?
<Rolly> "standalone tree" I mean
<lifeless> Rolly: its a checkout + branch + repository colocated
<lifeless> Rolly: (ls .bzr/)
<Rolly> My branching operation just finished and I only see the .bzr directory, but bzr info says standalone tree
<Rolly> when I cd into the directory containing .bzr/ and run bzr co, I get "ERROR: File exists: u'G:/temp/www/.bzr'"
<lifeless> Rolly: uhm
<lifeless> Rolly: don't do that :P
<Rolly> why not? :)
<lifeless> Rolly: I was saying 'ls .bzr' because that shows the objects present in the directory
<lifeless> 'bzr co' inside .bzr isn't something normal to do
<Rolly> i'm not inside of .bzr/
<Rolly> I'm in the directory that contains .bzr/
<lifeless> Rolly: oh, misread
<Rolly> the place I branched to
<lifeless> Rolly: whats listed if you do 'ls .bzr' there?
<Rolly> > ls .bzr/
<Rolly> branch  branch-format  branch-lock  checkout  README  repository
<lifeless> Rolly: it has a checkout already
<Rolly> > ls -lah .
<Rolly> total 0
<Rolly> drw-rw-rw-  3 user 0 0 2008-12-01 23:42 .
<Rolly> drw-rw-rw-  3 user 0 0 2008-12-01 23:42 ..
<Rolly> drw-rw-rw-  6 user 0 0 2008-12-01 23:52 .bzr
<lifeless> Rolly: what does 'bzr st' report?
<Rolly> where is the checkout? :O
<Rolly> 'bzr st' show all of the files as "removed"
<lifeless> Rolly: 'bzr revert'
<lifeless> I would guess something interrupted bzr
<lifeless> as it was building the checkout
<Rolly> > bzr revert
<Rolly> bzr: ERROR: No final name for trans_id 'new-2222'
<Rolly> file-id: None
<Rolly> root trans-id: 'new-0'
<Rolly> 'bzr st' still shows all as removed
<Rolly> shall I try to branch again?
<lifeless> Rolly: no, that phase worked
<Rolly> OK
<lifeless> Rolly: are you on windows?
<Rolly> Yep
<Peng_> Rolly: What version of bzr?
<lifeless> so, start by filing a bug; there will be a backtrace in your .bzr.log (bzr --version lists where that can be found)
<Rolly> Bazaar (bzr) 1.9
<lifeless> Rolly: try 'bzr remove-tree' then 'bzr checkout .' (the '.' is important)
<markh> it looks like BB missed that second mail attempt too :(
<Rolly> ok lifeless
<Rolly> > bzr remove-tree
<Rolly> bzr: ERROR: Working tree "G:/webdev/bibliotik/temp/www/" has uncommitted changes.
<lifeless> Rolly: rm -rf .bzr/checkout
<lifeless> Rolly: :)
<lifeless> then try 'bzr checkout .'
<Rolly> > bzr remove-tree
<Rolly> bzr: ERROR: No working tree to remove
<Rolly> ah,
<Rolly> ok I ran the checkout
<lifeless> did it work?
<Rolly> ERROR: Unable to create symlink 'blahblahblah' on this platform
<lifeless> ok
<Rolly> now I remember I saw that when I branched
<lifeless> there is the problem :)
<Rolly> phew
<lifeless> there is a plugin you can use I think
<lifeless> on the plugins wiki page
<Rolly> yeah I'll check it out
<Rolly> thanks for the assistance
<Rolly> here goes nothin'
<Rolly> argh!
<Rolly> > bzr checkout .
<Rolly> bzr: ERROR: [Error 123] The filename, directory name, or volume label syntax is incorrect
<Rolly> .bzr.log says "WindowsError: [Error 123] blahblah"
<CXI> okay, I think I'm getting this - I should create a *repository* for my documents directory, then a *branch* for each project
<CXI> but what when I just want to check out all my code or all my documents? are there tools that will check out an entire repository?
<markh> poolie: I'm happy for those updates to be rolled back, but am interested in why so many security updates would then be listed as outstanding, and why this isn't a concern for us...
<poolie> did you reply to them, or they to you?
<poolie> i didn't see anything
<markh> they to both of us it seems
<markh> I never got anything from you yet either, which is strange - only their reply
<lifeless> CXI: no, checking out an entire repository doesn't make sense - the repository is *just* a database
<lifeless> CXI: there are tools to mirror *all the branches in a repository*
<Rolly> lp:bzr-win32symlinks Last Modified: 78 weeks ago
<Rolly> heh... no wonder
<CXI> hm
<Rolly> I probably need to check my cygwin installation
<spiv> poolie: thanks for undoing my caching patch
<poolie> np
<poolie> can you try it a different way?
<poolie> maybe with a cache in a write stream from the transport that can be flushed?
<metajack_> Is there a short guide to getting a server side hook set up for commit emails somewhere?  i see there was an appropriate hook added in 1.6, but can't find anything else about it.
<markh> poolie: will you reply or shall I?
 * markh assumes the mail has finally arrived for you...
<poolie> markh, i replied
<markh> cool, thx
<poolie> no reply from them yet
<awmcclain> Is there a way to un-remove a file?
<awmcclain> (I keep getting "not a versioned path" if I try to bzr add or bzr revert)
<spiv> poolie: the three obvious fixes are 1) transport level cache, 2) have a smart verb [but that doesn't help sftp push], 3) teach the client to read from the local repo rather than reading back from the remote when reconstructing fulltexts
<lifeless> awmcclain: what bzr version?
<spiv> poolie: probably 1) is the most straightforward.
<lifeless> awmcclain: also, yes, 'bzr revert FOO' will look for FOO in the last commit, but no further back than that
<awmcclain> lifeless: 1.6.1
<awmcclain> hrm
<lifeless> awmcclain: use 'bzr log -v' to find when it was deleted, then 'bzr revert -r XX FOO' to reinstate it
<spiv> poolie: (by "have a smart verb", I mean an "insert_record_stream" sort of verb)
<lifeless> spiv: sftp already has a network cache
<lifeless> spiv: or rather,it has a network pipeline, which is why its faster than bzr:// in this case, I expect
<vila>  lifeless: regarding bug  255687, I tagged it log as I want to make 'log -v <FILE>' display only the inventory entries related to FILE, i.e. making log a usable tool to find when a file was removed (I'm not sure I will succeed though :)
<ubottu> Launchpad bug 255687 in bzr "Please allow annotating removed files" [Medium,Confirmed] https://launchpad.net/bugs/255687
<lifeless> vila: sure, but that bug is about annotate
<lifeless> vila: and log -v FILE shouldn't (really really shouldn't) be digging more than one revision back anyhow, to find 'FILE'
<vila> lifeless: why shouldn't it ?
<vila> scratch that
<vila> Say I have two branches conflicting about a file which get added/removed, how can I find the history of the files (which may be be different file-ids) ?
<vila> As a user
<vila> log sounds the most obvious answer hence the desire to make it usable to dig the history with the file path
<lifeless> vila: well, I'm not disputing the use case; I'm disputing that the bug you tagged is about log
<vila> I could delete the tag if you prefer, I put it because it was so close to the use case I was trying to address
<vila> and I didn't want to forget it
<lifeless> as long as the bug doesn't get closed if log starts doing that
<vila> Fine, np for me
<lifeless> cause there are clear issues for annotate, cat, ls, etc for this
<lifeless> as for why not searching deep history
<lifeless> 'bzr log file-that-never-existed'
<vila> should display nothing, even if it takes a long time ?
<lifeless> should not take a long time
<vila> Is that the final reason for not providing the feature ?
<lifeless> I'm not saying don't provide an answer for the use case
<awmcclain> Anyone if trunk for bzr-email works with gmail now?
<lifeless> awmcclain: I don't know sorry
<lifeless> vila: I'm saying that making log FILE, as well as all the other commands, take a long time on bogus input is not user friendly
<vila> lifeless: Right :-/
<vila> Hmm
<lifeless> vila: log isn't any more relevant than annotate or even 'ls' for 'find when a FILE was deleted'
<vila> well, the use case is about: show me the history of that file, including when it was added, modified and removed
<lifeless> not really
<lifeless> "
<lifeless> When a file has been removed from the repository, it is very difficult to find out what revision it was removed."
<vila> Sorry, I was talking about *my* use case, not the bug 255867 one !
<ubottu> Launchpad bug 255867 in drizzle "DDL commands generate a wrong number of warnings" [Undecided,Fix released] https://launchpad.net/bugs/255867
<vila> grr 255687. please ubottu, deal with my typos !
<lifeless> so I think  your use case is good; but I don't htink it maps to the users use case *that* closely
<lifeless> they want to be told clearly when a file is requested that used to exist; they don't care about other stuff
<vila> Right, I'll clear that tag right now ! :-) I wanted it to apply only to the "Use 'bzr log FILE' if FILE is removed" line :)
<vila> done
<lifeless> I don't have an issue really, with it being tagged log
<vila> Ok, let's forget about that
<lifeless> have you had time to hack on split-inventory stuff?
<vila> no :-/
<lifeless> thats a shame
<vila> yes
<awmcclain> FWIW, it doesn't. :(
<awmcclain> (bzr-email trunk doesn't work with gmail)
<awmcclain> Hrm... bzr dies when I try to set my launchpad ID. http://dpaste.com/95285/
<lifeless> its pycurl
<lifeless> there is a bug about this
<awmcclain> K. I'll check.
<lifeless> vila: could I ask a favout?
<lifeless> favour
<lifeless> bug 303959 - turn it into a patch?
<ubottu> Launchpad bug 303959 in bzr-svn "missing redirect handler: no repository found when pulling a branch from bzr-playground" [Medium,Fix committed] https://launchpad.net/bugs/303959
<vila> lifeless: there are other issues regarding redirection handling. I'd like to address some more before issuing a patch (with tests)
<vila> But thanks for bringing it on my radar again :-/
<awmcclain> lifeless: You're not talking about bug 271573?
<ubottu> Launchpad bug 271573 in launchpad-bazaar "bzr cannot access launchpad branch behind https proxy" [Medium,Triaged] https://launchpad.net/bugs/271573
<awmcclain> Ah, found it. bug 82086
<ubottu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed] https://launchpad.net/bugs/82086
<lifeless> vila: that one in particular is kinda important
<lifeless> vila: because it breaks the gnome playground
<vila> lifeless: Let's say I send a patch today whether or not it's complete enough ok ?
<lifeless> that would be awesome
<awmcclain> Is there a way to workaround this so bzr push lp:..... doesn't spawn a bad CA error?
<lifeless> awmcclain: remove pycurl
<lifeless> awmcclain: or setup the certificate
<awmcclain> Does bzr set the cainfo when using pycurl? Where does it look for the .pem?
<lifeless> bzr doesn't ask pycurl to do anything special
<awmcclain> Hrm. Well, I can't uninstall pycurl, and I can't for the life of me figure out how to get it to recognize the pem file I've downloaded for the certificate.
<awmcclain> Using bzr push https+urllib://code.launchpad.net/~awmcclain/bzr-email/gmail-fix tells me I "have a valid .bzr control directory, but not a branch or repository"... is that because I'm trying to push a checkout to a branch?
<lifeless> awmcclain: it sounds like it got interrupted creating the dir
<lifeless> awmcclain: you can just use bzr send and mail me a bundle if you like
<awmcclain> Yeah, I temporarily disabled pycurl and now I'm getting a transport error: http://dpaste.com/95289/
<awmcclain> What if I delete the branch on launchpad and start again? I'm just trying to publish the updated bzr-email that works with gmail.
<lifeless> yah delete the branch and start again
<gioele> hi
<gioele> is there a command I can use to see the status of a file? On one file bzr status says nothing. I don't understand whether it is ignored, unknown or versioned
<poolie> gioele, 'bzr ls' in the directory will tell you if it's versioned or not
<gioele> poolie: thanks
<gioele> anyway, isn't there a single command that integrates status and ls?
<gioele> I wonder why status --verbose is silent for versioned files
<poolie> that seems like a bug to me too
<poolie> in fact, a regression
<markh> does bundlebuggy only see mails that *start* with "[MERGE"?  HACKING says only "put [PATCH] or [MERGE] in the subject"
<mwhudson> markh: i think it's startswith, yeah
<markh> oh well, 3rd time lucky I guess...
<poolie> it shouldn't be
<markh> BB didn't pickup my retried message, and AlexB sent me a private email telling me he thought it was a regex with "^[MERGE"...
<markh> 3rd try sent now :)
<markh> yep - and BB immediately got it
<lifeless> o
<stephank> Hi! I have a bit of a problem. I have a bzr working directory I imported from a project source tarball. Now I've worked on this extensively, branched this several times, etc. The original project has since made some interesting changes available in a subversion repository, and I want to merge this into one of my branches. But of course, bazaar complains about no common ancestor. How would I go about this?
<lifeless> stephank: the easiest way would be to branch off your original import, then run 'svn diff -r ORIG -r -1' | bzr patch
<lifeless> or something like that
<stephank> lifeless: I see, I'll try that. Thanks :)
<sven_> hi! my friend got this crash when running gcommit : http://pastebin.com/dd9a619f
<sven_> is that a known bug?
<sven_> shall i report it?
<jelmer> yeah, it's a known bug - there's a bug open about it in lp I think
<sven_> jelmer, ok, thanks
<vila> sven_: It is a known bug and I'm pretty it's already fixed, my best guess is that your don't have the latest bzr-gtk version available
<sven_> vila, ok, good to hear
<vila> sven_: it should be bug #286834, if that's not the case, let us know
<ubottu> Launchpad bug 286834 in bzr-gtk ""bzr gcommit" issues an exception" [Undecided,Fix released] https://launchpad.net/bugs/286834
<sven_> vila, thanks a lot. i'll let you know if the problem persists after he upgrades
<vila> sven_: strictly speaking this may be bug #279831, but the fix for #286834 was merged later and cover other related cases, so you need at least revno 617 of bzr-gtk
<ubottu> Launchpad bug 279831 in bzr-gtk "C-extensions in bzr.dev cause "bzr gcommit" to issue exception" [High,Fix committed] https://launchpad.net/bugs/279831
<vila> jelmer: ping, I just marked bug 279831 as Fixed Released and realized that may not be the bzr-gtk policy, can you confirm ? I.e. the fix is merged on trunk even if 0.96.0 has not been formally released
<ubottu> Launchpad bug 279831 in bzr-gtk "C-extensions in bzr.dev cause "bzr gcommit" to issue exception" [High,Fix released] https://launchpad.net/bugs/279831
<vila> jam: ping
<jelmer> vila, we usually mark as released after a release
<vila> damn, ok, I'll fix the two I know about then
<jam> vila: pong
<luks> hehe, git-generated patch against bzr in the ML
<LarstiQ> Jari seems to have that as his mo.
<CardinalFang> Hi all.  Why would a "bzr pull", not "merge", ever generate conflicts?
<Ursinha> CardinalFang, because you have a modified file on your local version that was changed on the remote one?
<CardinalFang> Ursinha, Then "pull" would abort and say "use 'merge' instead", yes?
<james_w> yeah, if you have uncommitted changes then you can get conflicts on pull
<CardinalFang> Uncommitted changes.  Ah.
 * CardinalFang checks.
<luks> another possible conflict is if the remote side removes a directory,but you still have some unversioned file in the directory
<CardinalFang> I see "Contents conflicts" on files, fwiw.
<james_w> yeah, "Contents conflicts" is probably something like luks says
<james_w> unversioned files conflicting with tree state changes
<awilkins> Waa
<awilkins> I'm having to convert a version control system to a newer one
<awilkins> Problem is, the "version control system" is a guy who periodically just backs up the folder and adds the date to the name
 * awilkins wants to revert to HIS revision 0 and delete some vital code
<luks> replacing humans by software is always fun
<luks> or are you converting the old guy into a newer guy? :)
<awilkins> I'd settle for some upgrades
<Tak> awilkins: you and I must have the same coworkers
<vila> jelmer: ping
<vila> jelmer: can you give me more info about bug #303959 ?
<ubottu> Launchpad bug 303959 in bzr-svn "missing redirect handler: no repository found when pulling a branch from bzr-playground" [Medium,Fix committed] https://launchpad.net/bugs/303959
<awmcclain> Can't catch a break while trying to push to a new branch on lp: http://dpaste.com/95441/
<jam> awmcclain: use a newer bzr :)
<jam> Actually the "in_buffer" bug is only because you used -Dhpss (it was a bug in the debug code)
<jam> what happens if you *don't* use -Dhpss
<awmcclain> See the top of the of the paste... same faliar.
<awmcclain> faliure.
<awmcclain> failure.
 * awmcclain fails.
<jam>  awmcclain: "Permission denied (publickey)" means that launchpad doesn't like your ssh key
<awmcclain> A ha!
<awmcclain> Makes sense.
<jam> You can try "sftp -v bazaar.launchpad.net/~awmcclain/bzr-email/gmail-fix" if you want more debugging on that
<LaserJock> is there a way to tell what bzr release a particular version of bzr-svn works with?
<sri> s'happenin
<sri> hey, anybody got vim scripts to do commits within vim?
<sri> otherwise I suppose I'll write one..
<lifeless> there is something
<lifeless> search the list archives for vim :)
<sri> oaky, I did a google and turned up nada.. which is why I asked here :)
<awmcclain> sri: One of the VCS plugins has bzr support.
<sri> I'll check the list archives.
<lifeless> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=bzr+vim ?
<sri> awmcclain: okay.
<lifeless> sri: ^ my first google fu is strong
<sri> damn.. I did vim scripts bzr
<sri> your fu is strong :)
<sri> I knew there had to be one.. I couldn't imagine nobody not writing one.
<Rolly> hi all. someone committed a few revisions with the wrong name/email. Is there anyway to change them?
<lifeless> Rolly: you can uncommit and recommit, but you can't just edit previous commits
<Rolly> Okay thanks
<Rolly> by the way, what is a typical use-case for bzr link-tree ?
<Rolly> I didn't see it in the docs or the user guide
<lifeless> it just hardlinks files in two trees that are the same, together
<lifeless> its a space saver if you have very large trees
<Rolly> Gotcha
<lamalex> mwhudson: beuno: ping?
<lifeless> bug 304547
<ubottu> Error: Launchpad bug 304547 could not be found
<LaserJock> does anybody know if the lesslog plugin is going to be maintained? it seems to have disappeared
<lifeless> LaserJock: no idea sorry
<rockstar> jelmer, ping
<jelmer> rockstar, pong
<rockstar> jelmer, I don't see a subvertpy release.
<jelmer> rockstar, there is none, just a bzr branch :-)
<rockstar> jelmer, but it's stable, right?  You're not going to change the API?
<bpierre> hi
<bpierre> when is the final release for 1.10 due?
<jelmer> rockstar, yes, the API is stable
<jelmer> rockstar, the basie project is already using it in their vcs browser
<NfNitLoop> Pushing 4 small revisions via bzr-svn is slow.  It always makes me worry that it's doing something it shouldn't be. :p
<jelmer> NfNitLoop, 0.5 will be much quicker I think :-)
<NfNitLoop> cool. :)
<NfNitLoop> and I noticed some comments about 0.5 doing away with branching schemes.
<NfNitLoop> which will be nice.  Because it seems nobody around here can follow a standard. :p
<NfNitLoop> (here - my workplace, in case that was vague.  Not y'all.)  :)
<lifeless> jelmer: what has enabled the speed increase?
<jelmer> lifeless: A bunch of things
<lifeless> .next()
<jelmer> lifeless, Eliminating various loops over all revisions in the repository to fetch and replacing with a single loop
<jelmer> lifeless, Never fetching file properties for a directory more than once
<jelmer> lifeless, Not fetching bzr file properties when we can prove they can't be there
<lifeless> jelmer: did bzrlib changes help this? and if so can you suggest more we should do?
<jelmer> lifeless, in terms of performance, I don't think there's a lot more that can be fixed in bzrlib (other than those two issues I raised)
<flacoste> hi there, how can find the 'submit:' revision using bzrlib?
<flacoste> how put another way
<flacoste> i have a WorkingTree and I want to call changes_from() to get the list of changes relative to the submit: target
<lifeless> do you mean equiv to 'bzr st -r submit:'?
<flacoste> yes
<flacoste> looking at status.py
<flacoste> i guess that I need a RevisionSpec
<flacoste> and call spec.as_tree(wt.branch) on it?
<lifeless> I think you have  tree, so tree.branch.get_config().<something> will give you the submit url
<lifeless> then you should open the branch - Branch.open(submit_url) and get the tip via branch.basis_tree()
<lifeless> or something like that
<flacoste> wouldn't RevisionSpec.from_string('subtmi:').as_tree(wt.branch) takes care of looking at the config?
<flacoste> seems to work here
<lifeless> flacoste: revision specs are really a UI feature
<lifeless> flacoste: I wouldn't encourage using them in direct scripts
<flacoste> really
<lifeless> Peng_: present for you
<flacoste> lifeless: they offer a nice abstraction api
<markh> poolie: did you CC me on that last message to web24 support?  If so I haven't got it yet and I notice kerguelen is still down...
<lifeless> flacoste: they do, but as a UI layer we change things as we find what works for users and does not work
<lifeless> flacoste: compared to the underlying api where we tolerate awkward naming, for instance, more.
<flacoste> lifeless: what about configuration names? is that the UI layer also?
<poolie> markh: i last posted through their web support portal
<poolie> john also found it was still down
<flacoste> lifeless: because if I don't use RevisionSpec.from_string('submit:') i have to copy the 'submit:' configuration logic encapsulated into RevisionSpec_submit
<lifeless> flacoste: flacoste its 'branch.get_submit_branch()'
<lifeless> flacoste: no, you don't :)
<flacoste> lifeless: a! that's even better!
<flacoste> that's a very nice API
<poolie> jam, markh: While we have removed all the Windows updates by our usual method, there still appears to be an issue with the server (stemming from the Windows updates carried out).
<poolie> I have escalated this to Parallels' developers, seeking their assistance (highest support priority) in getting your server back online.
<lifeless> flacoste: I just checked, we have some code duplication surrounding this
<markh> bleh :(
<markh> the web portal now shows the status as "booting" - obviously not very successfully though :)
<lifeless> flacoste: as you say, there is logic there that would be duplicated to be 100% correct; I suggest filing a bug as its also duplciated in cmd_bundle
<flacoste> lifeless: you mean between RevisionSpec_submit and cmd_bundle?
<lifeless> yes
<lifeless> Peng_: btree bzr-search, now 10% faster
<lifeless> flacoste: generally we try to have a really nice api
<lifeless> flacoste: it makes scripts clearer
<flacoste> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/304585
<ubottu> Ubuntu bug 304585 in bzr "There should be an API to get the branch referred to by submit:" [Undecided,New]
<CaMason> hi guys. I've renamed a file on my system without using bzr rename. Is there a way I can link these files before I commit?
<bob2> bzr help mv -> --after
<CaMason> aha thanks bob2
<CaMason> ace. worked like a treat
<jelmer> lifeless, Is there any chance split inventories will help with bzr-svn?
<lifeless> jelmer: likely
<lifeless> jelmer: what things slow bzr-svn up
<jelmer> lifeless: lsprof reports:
<jelmer>  * Inventory.copy() (33%)
<jelmer>  * Repository.add_revision() (49%) (most of which is spent serialising
<jelmer> the inventory)
<lifeless> jelmer: grab the brisbane-core branch
<lifeless> jelmer: use --development4
<jelmer> lifeless, would any of these functions in particular become faster or do I have to make different calls as well?
<lifeless> (--development4-subtrees I guess, or make the obvious changes to get a -rich-root variant)
<lifeless> Inventory.copy() isn't relevant to split-inventories
<lifeless> jelmer: describe the context you are using these things in
<jelmer> lifeless: This is during svn-import
<jelmer> add_revision() is called each time a new revision is imported from svn and added to the bzr repository
<jelmer> Inventory.copy() is called before each revision delta that is fetched from svn
<lifeless> ok, and where are you using I.copy?
<jelmer> We make the changes against the copy of the inventory because we have to keep the parent inventory around as well
<jelmer> (to see what file ids certain paths had in the parent revision, etc)
<lifeless> ok
<lifeless> change your code to do this:
<lifeless> * create an inventory delta
<lifeless> call Repository.add_inventory_delta(...)
<lifeless> Repository.add_revision()
<lifeless> and just hold onto inventories you want
<jelmer> lifeless, thanks, I'll have a look at that
<lifeless> it should work fine on bzr.dev too
<lifeless> but on development4 it will apply the delta without examining the entire inventory
<thumper> lifeless: when are you off?
<thumper> lifeless: 'cause I have a big pqm patch
<thumper> lifeless: to fix multipart message handling
<lifeless> thumper: 1 hour
<thumper> lifeless: ah
<thumper> lifeless: the verify-email-hackage branch just refactors the email processing and verification
<thumper> lifeless: I'm going to write another that does the multipart handling of merge directives
<thumper> lifeless: but probably not today
<lifeless> thumper: very cool - thank you
<lifeless> thumper: today I fly, tomorrow I'm on leave, friday fosscamp starts
<lifeless> I'll do what I can
<thumper> lifeless: ok
<thumper> lifeless: I have mthaddon waiting on a version that handles merge-directives to test
 * thumper needs coffee badly
<lifeless> thumper: bug 304545 is in the lp-bazaar baliwick
<ubottu> Launchpad bug 304545 in bzr "ProtocolError for xmlrpc while pushing branch" [Undecided,New] https://launchpad.net/bugs/304545
 * thumper looks
<lifeless> looks like an internal service went transiently awol
<lifeless> likely not a code bug per-se, but still...
<thumper> lifeless: retargetted
<thumper> lifeless: I think it is a known bug, where the fix is in progress
#bzr 2008-12-03
 * thumper out for lunch
<thumper> damn
<thumper> wrong channel
<lifeless> jelmer: is there still a gtk applet for bzr?
<lifeless> nvm
<jam> lifeless: With the new remap code (for map and unmap) I'm now able to get farther in converting revisions from bzr.dev to chk inventory
<jam> Last time it failed around 12.1k revs, I'm now at 14.8k
<jam> at ~1200s
<jam> so it will take maybe an hour to finish
<jam> This is the info for a quick conversion of bzrtools:
<jam> http://paste.ubuntu.com/79555/
<lifeless> jam: cool
<jml> lifeless: hello
<jml> lifeless: you pinged me yesterday
<lifeless> yes, about testresources foo I think
<jml> lifeless: want to talk about it now?
<lifeless> nope
<lifeless> got to leave real sooon
<jml> lifeless: np
<jam> lifeless: so it took a total of 39m51s to convert all of bzr.dev into development4
<jam> I'm doing the repo-details analysis now
<lifeless> jam: thats pretty good
<jam> Also, my first attempt at a quick hack to get knit delta compression failed. I'm not 100% sure why, but I was setting a parent, and it *wasn't* doing a delta.
<jam> I'll also note that I get a *lot* of collisions with different details
<jam> I don't quite understand that
<LaserJock> do people here regularly use multi-pull?
<LaserJock> I tried using -v (for verbose) and the output seems just as terse
<jelmer> lifeless, jam: I am allowed to change the inventory returned by Repository.get_inventory(), right?
<jam> Legal? probably, recommended?
<lifeless> jelmer: no, and split-inventory will not let you
<jam> I believe in the chk code we are adding an Inventory.create_by_apply_delta() function, which would be the recommended way to do it
<lifeless> jelmer: why do you want to?
<jelmer> just curious, it would be a cheap optimization right now
<lifeless> jelmer: things could behave badly with aliasing
<jelmer> lifeless, bzr.dev doesnt' have a Repository.add_inventory_delta() yet, btw
<lifeless> ah
<lifeless> its been reviewed, mayhave a name change and so on
<lifeless> gotta go, ciao
<jml> ciao
<awmcclain> Will installing Pyrex make 1.10 run much faster?
<jam> awmcclain: are you running from an installed bzr, or from source?
<awmcclain> jam: easy_install -U bzr
<jam> hmm... I don't know for sure what that gets as a package.
<jam> I think it gets the released tarball
<jam> which means you should only need gcc
<jam> and not Pyrex
<awmcclain> "The python package 'Pyrex' is not available. If the .c files are available,
<awmcclain> they will be built, but modifying the .pyx files will not rebuild them."
<jam> that warning seems fine
<lifeless> doesn't bzr --version list the optimisers?
 * lifeless goes
<jam> you are watching out for the "could not build XXX using the slower python versions instead"
<awmcclain> Right, since I'm not modifying the source.
<jam> lifeless: you may be interested in: http://paste.ubuntu.com/79569/
<jam> if you haven't gone yet
<jam> it is the repo details for chk w/ bzr.dev
<Peng_> lifeless: Cool. Is it possible to upgrade the indexes or do you have to "rm -rf"/"bzr index"?
<rockstar> jelmer, still around?
<jelmer> rockstar, yep
<rockstar> jelmer, getting a test failure in a fresh subvertpy branch
<jelmer> if there's a single test failure, that's a known issue
<rockstar> jelmer, http://pastebin.ubuntu.com/79582/
<jelmer> the failure is known, the error isn't
<rockstar> That's running nosetest on the build
<rockstar> I did `python setup.py build && cd build/build-* && nosetests`
<rockstar> make check fails in the same way.
<jelmer> I moved some things around but forgot to run the tests
<jelmer> I'm pushing a fix
<jelmer> thanks for letting me know :-)
<rockstar> jelmer, sure.
<jelmer> the other issue is known, and is caused by the fact that subvertpy can't rely on bzrlib.urlutils
<rockstar> jelmer, why's that?
<jelmer> it's otherwise independent of bzr, and it would make adoption by e.g. the basie folks harder
<rockstar> jelmer, basically, I'm back evaluating using subvertpy in cscvs, and, in effect, the launchpad import system
<jelmer> ah, cool
<rockstar> jelmer, do you think it could be used in production?
<jelmer> subvertpy? Yeah, I think so. The bzr-svn tests exercise it pretty well and I haven't seen any other problems either
<jelmer> the server stuff is still incomplete and unstable, but you won't be using that anyway I presume
<rockstar> jelmer, nope.
<rockstar> We want to be able to roundtrip commits as well.
<jelmer> if you want to roundtrip commits, it's probably more worthwile to look into bzr-svn
<rockstar> jelmer, did you push the fix to trunk
<jelmer> rockstar, yep
<rockstar> I'm on rev 1971, and it's telling me there are no revisions to pull
<rockstar> :/
<jelmer> it's a mirrorred branch, in case you're pulling from lp
<rockstar> jelmer, ah, that makes sense.
<jelmer> lifeless: looks like by using inventory deltas I can actually avoid that Inventory copy
<jelmer> lifeless, that would save another 33 % \o/
<jelmer> lifeless, still there?
<jelmer> abentley1, ?
<jelmer> or somebody else familiar with inventory deltas?
<abentley1> jelmer: hi.
<jelmer> abentley1, hi!
<jelmer> abentley1, Is it possible to recursively delete entries using a single inventory delta entry, or do I need to delete all ancestors separately?
<abentley1> jelmer: You're supposed to list all the deletions.
<jelmer> abentley1: Thanks.
<abentley1> jelmer: I think deleting the parent works with current implementations, but it's not guaranteed.
<jelmer> abentley1: Also, is it valid to have two changes for a single ie?
<jelmer> file_id I mean
<abentley1> jelmer: No, the ie describes the target state.
<abentley1> So if you had two, and they differed, one would be wrong.
<jelmer> right, that makes sense. Thanks again.
<abentley> jelmer: np
 * jelmer regrets not trying out inventory deltas earlier. I thought they would be complex to deal with in bzr-svn for some reason, but it's actually improving the code in various places
<AfC> It's always a treat when you discover {that,} someone else's code {,that} can make your life better.
<jelmer> abentley, is it valid to remove a file_id first and then re-add it again at a different path?
<abentley> jelmer: No, a file id should occur at most once in a given delta.
<abentley> jelmer: Removing the file_id is not needed if you're moving the file.
<abentley> jelmer: There is no "before" or "after" in a delta.  It's ambiguous to perform two operations (deletion or moving) in the same delta.
<jelmer> abentley: Ah, ok.
<jelmer> I don't know beforehand which files are only removed but not added again (a rename), but I can obviously keep a set of files that are deleted and remove the ones that are also copied from that and just process the renames at the end
<metajack> Any idea what "bzr: ERROR: The branch lp:poetry has no revision None." means?  I've used this launchpad branch plenty in the past.  All of a sudden it is being weird.
<Chaosmagi>  Do u feel like your life is stuck in a rut, just going around in circles. Do u feel Spirituality left out then all u have to do is !!!!TAKE BACK REALITY!!!! www.ellis69.webs.com
<Peng_> Take back reality from who?
<Peng_> Is there something up with the mailing list? I've seen replies to several messages I haven't received.
<Peng_> In the svn-import performance thread, I see four messages. Gmane only has two.
<Peng_> The mailing list archive says there are five messages. So I guess I am missing something for some reason.
<abentley> Peng_: I see 5 also.
<Peng_> So it's just me? Damn.
<Peng_> :P
<abentley> Peng_: #5 is ~ 16 minutes old.
<Peng_> abentley: I'm missing the first reply from jam, not the most recent message.
<AfC> Sorry for a stupid question: if using bzr-svn, does the Bazaar revno == the Subversion revision number?
<AfC> (fresh branch, etc)
<abentley> AfC: Not in the general case.
<Peng_> AfC: No, because svn revnos are repo-wide while bzr revnos are branch-wide. "bzr log" will show the svn revnos on revisions created with svn.
<AfC> ah
<AfC> Peng_: didn't know about that. Nice feature. Thanks.
<Peng_> There's also an svn revspec, so you can do e.g. "bzr cat -r svn:123 foo".
<fullermd> Peng_: Taking reality back is easy.  The question is, does reality want YOU back?
<Peng_> Gmane seems to have all of hte messages.
<Peng_> Hm.
<AfC> Peng_: you have a blog or homepage?
<Peng_> AfC: I own a domain name, but whether you can call an almost-blank index.html a "homepage"...
<AfC> Peng_: It could hardly be worse than http://audacious-media-player.org/
<Peng_> AfC: By "almost-blank", I seriously meant "almost-blank". It's only one page, with no CSS or images or anything. :)
<AfC> Fine. I won't link to you.
<AfC> {shrug} just trying to be polite and attribute when due.
<Peng_> AfC: Thank you. :) I'd really rather not be linked. I just imagine the disappointment someone feels when they click a link, expecting to find something interesting, and...don't. :P
<AfC> Maybe you should endeavour to be interesting, then? :)
<AfC> [Tricky]
<AfC> [/me notices in passing that is virtually impossible to make this conversation not make it appear condescending. Oh well]
<Peng_> Heh. I didn't take it that way.
<fullermd> I tried being interesting once, but it was way too much work.  I went with irreverant and misanthropic instead; it's surprisingly close to the same thing, but SO much easier.
<vila> hi all
 * vila had to reset its switch (first time in years, took him a while to even think about it as an explanation for  losing internet connectivity :-)
<mtaylor> hey all... I was going to upgrade my launchpad branches to 1.6 but now 1.9 exists... should I just go all the way to 1.9 now? or should I hold off and just do 1.6?
<fullermd> I thought I heard that LP doesn't support 1.9 yet.
<mtaylor> fullermd: well then - that would be a great reason to not use it yet!
<fullermd> It makes it harder anyway   ;p
<thekorn> hi, I've got a question about bzr rebase: did I get it right, this plugin can be used to create a new branch containing only the last ten revisions of another branch
<thekorn> is there some workflow related documentation to rebase somewhere?
<thekorn> ok, maybe I'm wrong with bzr rebase
<thekorn> so more general question: is it possible to create a new branch of the last ten revisions of an existing branch?
<luks> thekorn: you can probably branch the original branch with -r0, then merge everything from revision 0 to -9, `bzr revert --forget-merges`, `bzr commit`, `bzr replay` the rest
<thekorn> luks, hmm, thanks, this looks like magic, let me try
<luks> thekorn: basically the problematic part to squash everything from the start of the branch to some point into a single revision
<thekorn> luks, does not seem to work, maybe I'm doing something wrong, thanks for your help anyway
<yacc> jelmer, yt?
<Peng_> fwiw, he last talked 7 hours ago, so likely not
<knighthawk> can someone explain the difference between merge, and pull to me? I'm not getting something.
<luks> perhaps it would be better if you ask specifically what you don't understand
<enobrev> has anyone here ever seen pack files get corrupted after a push
<enobrev> ?
<jelmer> yacc, hi
<Tak> did anyone file a feature request to make `bzr status -S` not show conflicts in an inconsistent way?
<enobrev> After a push, when I try to do anything, I get "Unrecognised container format: 'B363'".  A couple of the pack files don't have their header ("Bazaar pack format 1 (introduced in 0.18)").
<enobrev> "anything" such as bzr update
<knighthawk> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<knighthawk> but when I use the merge command I get 'Nothing to do'
<LarstiQ> knighthawk: could you provide a bit more context on when this happens, what bzr status/missing say?
<LarstiQ> enobrev: I've seen something like that before, don't recall off the top of my head what the situation was.
<jelmer> Peng, the mailing list is not sending me everything right away either
<enobrev> LarstiQ: you were the one to help me with it last time.  I ended up killing the repo and re-pulling because adding the header manually didn't work
<tigger^> hey peeps
<LarstiQ> enobrev: ah
<tigger^> bzr branch bzr+ssh://myrepo
<tigger^> bzr: ERROR: Generic bzr smart protocol error:
<tigger^> doesn't give me much to go on..
<tigger^> Bazaar (bzr) 1.7.1
<tigger^> -Dhpss doesn't change the output at all, which strikes me as odd
<enobrev> LarstiQ, at least that's what I did last time.  But just ran into the problem again this morning.  I'm waiting for the developer who made the last push to log on so I can debug with him, but just wondering if anyone's seen that happen around here
<LarstiQ> enobrev: this time, go the launchpad answers/bugs route
<enobrev> LarstiQ, good call
 * LarstiQ nods
<LarstiQ> enobrev: succes with that
 * LarstiQ heads downtown
<enobrev> LarstiQ: thx
<tigger^> branching localy I got bzr: ERROR: exceptions.MemoryError:
<Tak> wow - `bzr branches localrepodir` => 750MB memory usage
<tigger^> swap was disabled on the machine, fixed that, it works now
<yacc> jelmer, hi ;)
<jelmer> yacc, hi
<yacc> jelmer, OT, technically, today #samba-technical is more appropiate ;)
<knighthawk> LarstiQ, bzr status says nothing. bzr missing says I'm missing 2 revisions.
<jam> abentley: ping about bug #304841
<ubottu> Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Triaged] https://launchpad.net/bugs/304841
<jam> When you say "as of revno 3873" is that because that is the bzr.dev you used to test it with
<jam> or that is the actual revision that shows the bug versus not showing it?
<abentley> jam: No, that's the version of 1.10 I tested it with.
<jam> And are you talking the 1.10 branch or the bzr.dev branch
<jam> ug
<jam> the new "loom" command hijacked "bzr up" to mean something other than "bzr update"
<abentley> jam: 1.10 rc does not exhibit the bug, because it gives the ShortReadv
<jam> k, did you try bzr.dev ?
<abentley> jam: bzr.dev also gives the ShortReadv
<jam> I don't expect anything different but just something to compare against
<jam> hm... k
<jam> I guess Martin didn't get the revert into bzr.dev yet
<abentley> jam: Right.
<abentley> jam: It's possible that the waste you're seeing in packs was introduced by Martin's stacking fix in 1.10.  That creates a fulltext if the basis text isn't available.
<abentley> jam: (but the basis text may arrive later in the stream).
<jam> abentley: I don't think it would "go away" during autopack
<jam> Also, this is only in the brisbane-core branch which doesn't have bzr.dev merged in yet
<jam> I'm pretty sure it is Robert's chk work, which adds things to the repository, then determines the sha1, and if it collides, just omits one of them from the index.
<jam> abentley: do you get the same failure if you don't use "--use-existing" ?
<abentley> jam: No, then I get the standard error you get if you push to an existing directory.
<jam> sure, I'm just wondering if there is something already wrong with the target, that is causing confusion.
<jam> Do you get the failure if you push do a different branch?
<jam> Certainly this is the "convert back to fulltext" code, since it is going through "get_bytes()".
<jam> I can't actually see the branches, though, so I'm a bit limited in what I can poke at.
<abentley> jam: I would expect so, but I'll verify.
<abentley> jam: Unfortunately, these are LP branches, so providing a mirror would take significant time.  You may be able to reproduce with lp:~abentley/launchpad/web-diffs
<jam> abentley: I'm not on the private team that has access to lp branches
<jam> so I can't reproduce at *all*
<abentley> jam: That seems dumb.  I've gotta run.  Be back in ~ 2 hours
<jam> I won't disagree...
<jam> see you later
<jam> It would also seem that the CombinedGraphIndex it is using doesn't have any actual indices, so there isn't any way for it to have *any* content.
<jam> Seems like something is confused as to where the real content is.
<jam> abentley: I can reproduce it here trying to push a stacked branch of bzr with bzr-1.10 onto launchpad.
<jam> I get the same: KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()) failure
<jam> oddly it takes almost 7m before it gets there...
<eferraiuolo> Can someone explain what type of smart server would be the best for the following uses...
<eferraiuolo> I want controlled user access to my repos, and maybe certain users have access to certain repos. This is on a server which I manage (VPS)
<eferraiuolo> I would need the connection to the server to be encrypted
<eferraiuolo> and possibly not want to create SSH or machine-level user accounts for people accessing the repos
<eferraiuolo> ...I've been reading up on the different smart server configs and not sure which matches with what I want to do the best, any suggestions?
<jam> eferraiuolo: my recommendation would be to use bzr+ssh with a single account
<jam> and use different ssh keys for each user
<jam> you can see some sample info in contrib/bzr_access
<jam> abentley: it also seems that I can reproduce it locally, without having to connect to LP at all
<eferraiuolo> okay, so you're suggesting a single user account on my machine that each user would login thru?
<LaserJock> can running bzr upgrade after installing bzr 1.9 have some bad consequences?
<LaserJock> I tried it and now bzr says there's no repository present when I try to pull/info/status, etc.
<beuno> LaserJock, the default format is the same as 0.92
<beuno> so there should be no consecuences
<beuno> what exactly is the error?
<LaserJock> bzr: ERROR: No repository present: <path to repo>
<beuno> that's very odd
<beuno> are you using a shared repo?
<LaserJock> no
<beuno> can you check that there's a .bzr dir in there?
<LaserJock> yeah, it's there :-)
<james_w> LaserJock: check .bzr/repository
<LaserJock> I checked that first
<james_w> there's a bug where it renames .bzr/repository to repository.moved or something
<LaserJock> james_w: there's a repository.backup
<james_w> *then* checks
<james_w> then doesn't move it back if it fails
<beuno> james_w, really???
<james_w> LaserJock: yeah, move that to .bzr/repository
<beuno> also, why is it upgrading?
<beuno> it only should upgrade if LaserJock was on knits
<LaserJock> heah, there we co
<LaserJock> *go
<LaserJock> ok, it works now
<james_w> it happens when rich-root support is not the same
<beuno> aaah
<beuno> rich root is evil
<LaserJock> I've had a bunch of "you should upgrade" messages
<LaserJock> but I never do it
<beuno> ok, so you where on knits
<LaserJock> but I decided to try it on a throw-away branch as it didn't matter if it screwed it up
<Peng_> Tak: That's something with bzr-svn.
<beuno> and you should probably do:  bzr upgrade --rich-root-pack
<Peng_> Tak: Augh, I was scrolled really far up. Sorry.
<Tak> that's ok - good to know
<james_w> bug 145812
<ubottu> Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged] https://launchpad.net/bugs/145812
<LaserJock> I think almost all my branches are rich-root-pack
<LaserJock> that's one of my "issues" with bzr is it seems like I'm always worrying about formats, and I don't understand them and can't keep them straight
<LaserJock> is pack-0.92 the default?
<beuno> yes
<LaserJock> ok, I've got a couple of those
<LaserJock> now if I upgrade my local branch does that slow down pulls if the branch I'm pulling from has an old format?
<beuno> it does
<beuno> you should upgrade the remote one as well
<LaserJock> well, I never have access to the remote one
<LaserJock> so i'll just leave them alone
<LaserJock> I just wondered what would happen
<jelmer> jam: hi!
<jelmer> jam: You mentioned a patch to a bug I was seeing in brisbane-core
<jelmer> jam: Which patch is that?
<abentley> jam: glad to hear it.
<kjcole> Hi.  Any cure for old (0.8.2) error: Error -3 while decompressing: invalid distance too far back?
<Peng_> 0.8.2? That release is older than I am. Does anyone even remember the error codes from back then?
<kjcole> The error continues, mentioning specifically the same line referred to in a launchpad bug report about memory issues:
<kjcole> usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103
<kjcole> (It's a very short message resulting from "bzr check" only two or three lines of error, before returning to the prompt.  No long stack.
<ToyKeeper> After using bzr, svn makes me :( :(
<ToyKeeper> ... especially with this 11 GiB checkout full of dead branches.
<pygi> jelmer, how are the duck branches going?
<crisb> has anyone any suggestions for end of line translation?
<jelmer> crisb, I think there's a plugin somewhere, not sure what the status of it is
<jelmer> pygi, Well, they're there
<jelmer> pygi, I guess it may be a good idea to put up a wiki page about them..
<crisb> jelmer: i've seen that one, but is there any plans for anything more in bzr itself?  the plugin doesnt really do anything automated (but is still useful in some regards)
<pygi> jelmer, I mean have you done any work to support them in core? :)
<crisb> it would be nice to get some info about how other projects manage it.  my current idea is to use just LF's in the repository except on files which need CRLFs (ini's etc) - is that how other people do it?
<jelmer> crisb, yeah, I think most just pick one line ending mechanism
<crisb> but I can see that without at least the EOL plugin, repositories could become a mishmash of different line endings
<jelmer> crisb, afaik the plugin did most things automated, but perhaps it's a good topic to bring up on the mailing list again
<jelmer> crisb, I know we're at least planning on supporting line ending conversions like svn does
<crisb> jelmer, ah thats good to know. we're converting from PVCS which (supposedly!) has some sort of conversion between line endings and although I dont see it as a real problem, some people are quite precious about it!
<jam> jelmer: the patch is in the email "CHKMap._check_remap()"
<jam> abentley: I'm pretty sure I understand the cause and have an idea of a reasonable solution
<jam> it was one Martin considered originally, but didn't go with
<jam> namely, requesting topological ordering
<jam> if we have a fallback vfs
<abentley> jam: What was the cause?
<jelmer> jam, Thanks, I'll give it a try
<jam> If you go back to the bug I mentioned it theree. But basically, Assume you have a delta chani A-B-C-D
<jam> and only A is present in the fallback
<jam> if we get the delta "C"
<jam> we can't extract it to a fulltext
<jam> because we haven't seen B yet
<jam> abentley: sound reasonable to you?
<jam> The actual case I looked at was a bit more confusing than that, because it seemed like I was inserting D, and C was present, but not B.
<jam> And I didn't understand how *that* could happen.
<jam> But I'm going to start from there.
<jam> I should have a patch shortly that you can try.
<abentley> jam: I thought we were checking for the case where B wasn't present.
<jam> I'm not sure what you mean by "checking for"
<jam> The idea is that  the stream is "unordered"
<jam> so it can send "C, B, D"
<abentley> jam: Only trying to get a fulltext when B was present.
<jam> abentley: that might actually be why I saw the confusion
<jam> Imagine we are fetching and we see C, D, B
<jam> at the point we get to D, C is present
<jam> but if we want to insert a fulltext, B is not
<jam> (we only look at the direct parent, and not the whole chain)
<jam> anyway, I'm not 100% sure
<jam> But that is the best I could put together
<abentley> jam: I'm pretty sure we're checking whether C is present in the fallback.
<jam> (so far)
<jelmer> hmm, next issue
<jelmer> CHKInventory doesn't have a apply_delta() function anymore
<jam> jelmer: you aren't allowed to mutate a CHKInventory
<jam> you need to use "create_by_apply_delta()"
<jam> which we should be adding to regular Inventory if we haven't
<abentley> jelmer: But more likely, you want to use Tree.apply_delta.
<jelmer> jam: Thanks, I'll look at that
<jelmer> abentley, A tree would be overkill in this situation I think. I'm only constructing the inventory for internal use by bzr-svn
<jam> abentley: also, Tree doesn't have apply_delta, right? You have to at least have a MutableTree (I would assume)
<abentley> jelmer: Oh, I thought you were using it for commit.
<abentley> jam: Interesting question.  Not sure.
<jam> You can't really do RevisionTree.apply_delta, IMO
<abentley> jam: Well, it would probably be a bad idea, anyhow.
<abentley> jam: So I'm looking at the test in knit.py near 1336.
<jam> This one, right:
<jam> elif ((record.storage_kind in knit_types)
<jam>       and (not parents
<jam>            or not self._fallback_vfs
<jam>            or not self._index.missing_keys(parents)
<jam>            or self.missing_keys(parents))):
<jam> And the "self.missing_keys(parents)" is supposed to determine that the fallback doesn't have the parent either
<abentley> jam: "or self.missing_keys(parents)" should mean that we don't attempt to construct fulltexts unless the parent is present.
<jam> Right, so imagine a long change A-B-C-D-E
<jam> We first get C
<jam> and we see that only A is in the fallback
<jam> so we go ahead and insert it as a delta.
<jam> then we get D
<jam> I guess that should be telling us it is okay to insert as a delta as well, because C is present...
<abentley> jam: No, that would fail the missing_keys(parents) and the not _index.missing_keys(parents)
<abentley> jam: Okay, I'm inclined to agree that forcing a topo sort makes sense here.
<abentley> As it's much simpler.
<jam> well, I can say that in my test case, forcing topological order made it "just work"
<jam> but I'd like to make sure I know the problem first :)
<abentley> So if we have C, we're allowed to make D a fulltext.
<jam> abentley: supposedly, but we don't have B to *actually* create D as a fulltext
<jam> but the problem is that I don't understand why we *want* to make D a fultext
<jam> anyway, here is the "just make it work" patch:
<jam> http://paste.ubuntu.com/79974/
<abentley> jam: Oh, I was trying to explain it to you because of your last comment.
<jam> A whole 1 line insertion
<jam> abentley: figured it out
<jam> it is a merge revision
<jam> and we check "self.missing_keys(parents)"
<jam> not "self.missing_keys([compression_parent])"
<jam> so it *does* have the direct parent
<jam> but not the merged parent
<jam> (I'm double checking that)
<jam> ok, a bit weird, but "self._index.missing_keys(parents)" returns 1 entry and "self.missing_keys(parents)" returns None...
<jam> so that means that the stacked branch has *merged* the base branch
<abentley> jam: I'm testing out your patch.
<jam> I'll also try a different one that isn't so heavy handed.
<abentley> jam: I can confirm your patch works for me.
<jam> abentley: I'm almost done with a patch that just fixes parents => compression_parent
<jam> give me a sec
<jelmer> jam, Yeah, "plain" Inventory doesn't have create_by_apply_delta() yet
<jelmer> jam, Other than that, things at least work now - thanks
<jam> abentley: try this: http://paste.ubuntu.com/79983/
<jam> jelmer: It is trivial to add create_by_apply_delta to plain inventory
<jam> basically, it is just "new = self.copy(); new.apply_delta(); return new"
<jelmer> right, that's what I was already doing myself, so I've just added a check for that method :-)
<jam> I think we would want that actual function in the brisbane branch
<jam> if you want to write it up quickly
<jam> abentley: so in testing it here, either patch I proposed to you fixes the bug
<abentley> jam: testing...
<abentley> jam: 2nd patch works for me.
<jam> ok. I feel like I have a good grasp of the problem at least.
<jam> I'll probably propose both fixes
<jam> as I think the topological sorting just means things go smoother in general
<jam> and the other is a "correctness" fix
<abentley> jam: cool.  Thanks for taking point on this.
<jam> np
<jam> martin asked me to step up for any stacking problems while he was afk
<kjcole> Any way to recover damaged "knit" files?  I have an old tree that appears to be working fine... Until I try to move to a newer system (or create a branch from it).
<kjcole> "bzr check" reveals a zlib.error "invalid distance too far back" related -- I think -- to an old memory bug listed on launchpad.
<kjcole> (the error appears to be at /usr/lib/python2.4/site-packages/bzrlib/tuned_gzip.py line 103, which is listed in the afore-mentioned bug report.)
<jelmer> jam: I'll look into providing a patch
<jelmer> jam, while I'm at it it would be nice to also fix this: http://paste.ubuntu.com/79989/
<jelmer> any idea what's going wrong there?
<jam> Probably a problem with an initialization path
<jam> I believe Robert added an _entry_cache
<jam> so that it doesn't have to read from disk and deserialize into an InventoryEntry multiple times
<jam> but I don't know when _entry_cache gets written
<jam> I would have thought in __init__ but maybe he did it elsewhere
<jelmer> lifeless, ^
<jelmer> jam: is it useful that I test and report these issues this at all atm or are you working on fixing them anyway?
<jam> ATM, I'm working on some bits lower down in the stack
<jam> Also, ATM, I'm the only one working on it... :)
<jam> however, I think it is good to be aware of where things are broken in the branch
<jam> I believe we want to get tests passing
<jam> as it makes further development easier
<jelmer> k, I'll just keep reporting issues and seeing if there's (small) things I can help with then
<jelmer> speaking of which..
<jelmer> InventoryDirectory.children appears to've become a lot slower
<jam> jelmer: CHKInventoryDirectory.children is quite slow as it has to go out and bring in more pages, etc.
<jam> Oh, and are you using "--development3" or "--development4" ?
<jam> --dev4 added a "parent_id,basename => file_id" map
<jam> the --dev3 code has to iterate the *entire* inventory for every .children request.
<jelmer> I'm using --development4-subtree
<jam> so... CHKInventory is now lazily evaluated
<jam> so when you create one it doesn't read the whole inventory
<jam> and only pages things in as you go to each IE.children
<jam> sort of thing
<jam> So building up that dict should be a lot slower than having already built it and only evaluating a dictionary
<jelmer> right, so I should try to limit inspecting the inventory to the things I actually need
<jam> yep
<jam> I wish "bzr shelve" worked on windows....
<jam> I keep wanting to use it :)
<jelmer> yeah, I use it all the time as well :-)
<jelmer> when add_inventory_delta() has to do an expensive copy of the inventory and apply the delta against that, is there some cheap way to get the resulting inventory?
<jam> not sure
<jam> I would guess Robert didn't optimize for that case
<jam> Certainly you could just have "add_inventory_delta()" return some sort of Inventory object back to you
<jelmer> but calculating that return value might be more expensive in the case of CHKInventory, no?
<jam> I would imagine you could just return the CHKInventory
<jam> it is really "add_inventory_*by*_delta"
<jam> and I think at some point it needs to work out what the basic shape of the inventory is
<jam> even if it didn't have to unpack every node.
<jam> (I believe Martin mentioned wanting a slightly different name for the function.)
<jam> abentley: the plot thickens further... the simple test case doesn't work right because it sees that the parent is missing so it 'buffers' the index entry
<jam> I have to figure out how to get one of the entries to not be buffered
<jam> ugh
<abentley> jam: Did the old shelve work with win32?  It's now provided as "shelve1".
<jam> abentley: yeah, the new one fails because of the WT locking issues
<jam> you can't actually hold a WT.basis_tree() outside the length of a lock
<jam> or you end up with 2 references to the dirstate file
<jam> which both try to lock it.
<jam> for now "cp" is good enough
<jam> but yeah, I can probably use shelve1
<awilkins> jelmer: Can bzr-svn 0.5 push a bzr branch as a new svn branch?
<jelmer> awilkins, 0.4 can already do that
<awilkins> jelmer: Is there a particular syntax?
<jelmer> bzr svn-push
<awilkins> jelmer: I'm trying to push a branch into a zero-revision svn repo
<jelmer> awilkins, you can't push to the root of the repository, as that already exists
<jelmer> awilkins, but you can push to e.g. /trunk
<awilkins> jelmer: waah, needs create-prefix :-P
<jelmer> awilkins, ?
<jelmer> awilkins, this behaviour is similar to that of bzr push
<jelmer> awilkins, note that you need "bzr svn-push", not "bzr push"
<awilkins> Yes, svn-push has no equivalent of the --create-prefix option of "push"
<jelmer> ahh
<DeviantPeer> hi all!
<DeviantPeer> I'm evaluating vcs an trully enjoying bazaar. Just a quick question: is there a way to have local branches whithout using another directory? (something like git does)
<DeviantPeer> and also mercurial does that kind of branching.
<lifeless> Peng_: rm-rf, new formats need to reindex anyhow to get more data.'2' isn't really finished yet, I haven'tdone a release..
<DeviantPeer> I know that you can use hardlinks in order to keep the storage usage low, but it's so easy to do something like (git checkout branch.name) and start using that branch...
<lifeless> DeviantPeer: yes, use a shared treeless repository to hold the branches, and then use 'bzr switch' to switch between them.
<DeviantPeer> lifeless: shared treeless? hum... how?
<jelmer> lifeless, create_by_apply_delta() forgets to set _entry_cache in the returned CHKInventory to {}, could that right?
<DeviantPeer> lifeless: or better... where do I start to read about it? any links?
<NfNitLoop> DeviantPeer: bzr init-repo . --no-trees;  bzr branch <remote-branch>; cd <workspace>; bzr co --lightweight <local-branch>  :)
<NfNitLoop> DeviantPeer: check the bzr wiki for the "workflows" page.
<DeviantPeer> NfNitLoop: ok.. gona try that. thx.
<NfNitLoop> I'm pretty sure it's one of the ones listed there.  (though I don't remember if 'switch' is mentioned specifically.)
<lifeless> jelmer: yes, looks like thats a bug to me
<DeviantPeer> NfNitLoop: already open and reading. ;) thx
<NfNitLoop> DeviantPeer: unfortunately it does use another directory, but with the --no-trees options, the directory only contains .bzr metadata about the branch, and all of the changesets(?) are stored in a shared .bzr in a parent dir.
<DeviantPeer> NfNitLoop: I understood that. I guess it works by harlinking to the other directory
<NfNitLoop> nope, no hardlinking.
<DeviantPeer> NfNitLoop: ups then.. got to read more ;)
<NfNitLoop> *nod*
<NfNitLoop> I vaguely remember about one dscm using hardlinking (mercurial?)  and wondered how that worked on windows...
<DeviantPeer> NfNitLoop: so if it doesn't use hardlinking it works even on "not so good" filesystems such as ntfs? (well yes.. at works we have to use it.. damn)
<NfNitLoop> DeviantPeer: yep!
<DeviantPeer> :) goody. :)
<NfNitLoop> I use bzr on windows, osx and linux regularly. :p
<DeviantPeer> I use wubi on the work computer... and didn't tell anyone about it.
<NfNitLoop> wubi?
<DeviantPeer> NfNitLoop: a small utility that installs ?ubuntu on top of windows without erasing anything from the hardisk
<DeviantPeer> NfNitLoop: I think it's called wubi... I might be giving you the wrong name.
<NfNitLoop> oh, cool.  Installs it on the FAT partition?
<NfNitLoop> I think I did something like that back when Slackware was cutting-edge. :p
<DeviantPeer> anyway.. my manager is realy happy 'cause I'm 5 times more productive than my coleagues
<NfNitLoop> heh.  apt-get and free tools will do that.  ;)
<DeviantPeer> NfNitLoop: it creates a biiiiig files on the ntfs (10 or more Gib)
<NfNitLoop> BTW, I found out that 'meld' works with bzr this week.
<NfNitLoop> <--happy. :)
<DeviantPeer> NfNitLoop: and then uses that file as a loopback devide for the linux root.
<jam> abentley: you may want to review the patch I just sent in, since I don't know if anyone else can get to it.
<jam> I'm done working for now.
<NfNitLoop> DeviantPeer: aah.
<jam> abentley: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E
<DeviantPeer> on bazaar: it's looking great. tomorow I'm going to try the "speed" of it when compared to others.
<abentley> jam: thanks.
<DeviantPeer> on features it rocks.
<DeviantPeer> the proper versioning of directories is great.
<DeviantPeer> now I can't even believe that I survived without it for so long ;)
<NfNitLoop> DeviantPeer: what VCS were you using previously?
<DeviantPeer> although ClearCase does version directories
<DeviantPeer> NfNitLoop: uff.. I have used CVS, svn, ClearCase (arghhhh!) and git
<DeviantPeer> NfNitLoop: now I'm trying some newer ones.
<NfNitLoop> We actually used MS VSS at one company I was at.  >.<
<DeviantPeer> argh!
<DeviantPeer> it's even worse than CCase.
<DeviantPeer> :)
<DeviantPeer> so much worse than anything actualy ;)
<metajack> Any particular reason that bzr+ssh would fail but sftp would work?  I get 'bash: bzr: command not found' and 'bzr: ERROR: Connection closed: please check connectivity'.  ssh host bzr works fine though.
<metajack> oh wait. no it doesn't. never mind me :)
<NfNitLoop> metajack: glad to be of service! :)
<DeviantPeer> metajack: :D
<DeviantPeer> well... time to go and read... the old fashion way of learning.
<DeviantPeer> NfNitLoop: thx for the tips.
<DeviantPeer> lifeless: thx
<DeviantPeer> bye all.
<lifeless> jelmer: I've pushed a fix
<jelmer> lifeless, argh, I was just working on a fix as well..
<jelmer> I have a testcase, if that helps..
<lifeless> jelmer: won't hurt to have a test
<lifeless> jelmer: I just made a __init__
<markh> jam: kerguelen is back up :)
<Lutin42> hi! I have a bzr repository broken and I'm looking for help to fix it (or at least export its content)
<Lutin42> I executed the following command: bzr rm documents
<Lutin42> and now, with most of the commands (except logs), I get the following errors: bzr: ERROR: exceptions.AssertionError: Could not find target parent in wt: documents
<Lutin42> is there any way to fix this?
<markh> an assertion eh...  You have a recent verison of bzr?
<lifeless> jelmer: feel free to push trivial stuff to brisbane-core directly
<lifeless> jelmer: [like trivially correct, doco etc]
<jelmer> lifeless, or this test ? :-)
<lifeless> jelmer: larger stuff please send a [split-inv][MERGE] to the list, and get an ack before pushing
<Lutin42> I was with an old version (1.6 I think)
<jelmer> k
<Lutin42> updated to 1.9, and still the same problem
<lifeless> Lutin42: that error will persist until you removeo the tree and check it again; it is a cache corruption, not a core data corruptio
<Lutin42> ok... now I feel like a noob
<lifeless> Lutin42: if you have no outstanding changes in the tree, or none you care about, just do 'bzr remove-tree --force; bzr checkout .'
<Lutin42> this tree was never pushed anywhere
<lifeless> Lutin42: do you have outstanding edits you haven't committed?
<Lutin42> nothing that is not backed up
<lifeless> ok
<lifeless> then do
<lifeless> 'bzr remove-tree --force; bzr checkout .'
<NfNitLoop> Lutin42: I'm also curious if you're working on a case-insensitive fs. (Windows)
<Lutin42> I'm on mac os x
<Lutin42> default install
<Lutin42> your command seemed to have worked ; produce a lot of conflict though
<lifeless> Lutin42: you can clean that up though, using bzr revert/resolve etc
<Lutin42> yes ; I'm looking into it, as the slightly different workflow is different for an svn guy
<Lutin42> Can I safely assume that all my modifs since the last commit have been moved to <file>.normal_extension.moved and that moving this file to the normal name and then do bzr resolve FILE will solve it?
<Lutin42> from what I've seen so far, yes, but just in case...
<Lutin42> back to normal
<Lutin42> lifeless, thanks a lot for your help
<uws> Server is too old for streaming pull, reconnecting.  (Upgrade the server to Bazaar 1.2 to avoid this)
<uws> Is it possible this also happens with pull over bzr+ssh:/ if the server is 1.8 and the client is 1.5?
<maxb> I'm browsing "bzr help commands" ..... what is a ghost and why would I want to fetch it?
<speakman> using bzr+ssh it says "Unable to determine your name. Use "bzr whoami" to set it.", but the whoami is already set to "Forename Lastname <email@address.com>".
<fullermd> uws: 1.6 (I think) removed the streaming pull thing for various reasons, so yes.
#bzr 2008-12-04
<speakman> it was caused by not setting whoami on the SERVER side
<lifeless> jelmer: ping
<jelmer> lifeless: pong
<lifeless> two questions re your 440K patch:
<lifeless> - I think you had a submit branch of bzr.dev, so its kinda hard to review :P (and note that [split-inventories][MERGE] is *much* ebetter, otherwise BB will pick it up
<lifeless> - why do y ou need create_by_apply_delta on regular inventories? (The Repository is the appropriate interface for making a new inventory normally
<lifeless> bbiab, car time
<jelmer> lifeless, bzr-svn's fetch uses the lhs parent inventory
<awilkins> jelmer: I'm trying bzr-svn 0.4 against svn 1.5.4 and while it builds, I'm having trouble running it. I'm getting "DLL load failed: The specified module could not be found."
<jelmer> awilkins, sorry, I'm not the right person for windows stuff
<awilkins> Hmm, appears to be DLL names
<awilkins> It's looking for libapr.dll when it's called libapr-1.dll
<jelmer> I've heard that problem being mentioned before
<awilkins> It seems to be the client.pyf
<lifeless> jelmer: I don't follow
<jelmer> lifeless, bzr-svn uses the lhs parent inventory when interpreting changes the server sends us
<lifeless> jelmer: yes... ?
<awilkins> The real libapr-1.dll is also being loaded
<jelmer> lifelss: fetch itself builds up an inventory delta
<lifeless> jelmer: this seems unrelated to my point
<jelmer> lifeless, argh, sorry, I mixed up two patches
<jelmer> lifeless, that first patch is moot if the second is accepted
<lifeless> 	Make Repository.add_inventory_delta() return the resulting inventory.
<lifeless> ?
<jelmer> yes, that's the second one
<lifeless> jelmer: +1
<lifeless> jelmer: just land it
<jelmer> lifeless, thanks
<awilkins> jelmer: The reason is that the APR distribution in the win32 dev pack I'm using is not the correct one
<awilkins> Grr, squish those SVN devs
<awilkins> jelmer: They are shipping 1.3 libs with 1.5.4 but the headers are the 0.9.6 versions
<lifeless> LOL
<awilkins> markh: You around?
<markh> awilkins: I am - hi
<awilkins> Do you build bzr-svn at all (and use it?_
<markh> I build it - I don't use it much as the svn repos I use have svn:externals and svn:eol-style :(
<markh> setup.py should be fairly accurate with build instructions
<awilkins> Heh, see above about not being able to use 1.5 version with windows (if you take the distributed library pack)
<markh> the "python based" installer?
<awilkins> They are shipping the 1.x series APR but the library pack has the 0.9 libs and headers
<awilkins> The python installer doesn't even build the pyd files
<awilkins> I'm building my own
<markh> yeah
<awilkins> If I want to access a 1.5 repo over ra_local I'm going to have to build APR in the morning.
<markh> awilkins: so where are you getting the apr binaries from?
<awilkins> The SVN guys host a "dev pack" for windows with libs and headers in
<markh> right - and you are building bzr-svn yourself?
<awilkins> The binaries in the 1.5.4 win32 distro are the 1.3x versions
<awilkins> the dev pack is 0.9
<awilkins> Yes, building bzr-svn extensions using VC++ 2003 toolkit and it's libs and headers
<awilkins> Which corresponds to the compiler used to build python 2.5
<markh> so - if you follow setup.py, one of those .zip files should have exactly matching apr binaries - or I'm still a little confused :)
<awilkins> The zip files do not have the right APR bits
<markh> don't try and use any other binaries with it
<markh> hrm
<markh> they do for me
<awilkins> They don't match the ones in the win32 distribution I downloaded
<awilkins> They match the 1.4.6 binaries
<markh> the bzr win32 distro?
<awilkins> But the 1.5.4 distro uses APR 1.3.x not 0.9.6
<awilkins> Alas, the 1.5.4 dev pack has the 0.9.6 libs and headers
<markh> OK - I last built using 1.5.2 - that package should be OK.  Note the "distro" of the version should not be relevant - you don't need anything other than the binaries bzr-svn (tries to) provide.
<awilkins> markh: I'm falling back on the path to load the DLLs from my installed SVN
<markh> right - which is the root of the problem
<awilkins> markh: And since the libs don't match the DLLs I have it's irrelevant anyway
<awilkins> Even if I copied them into the same folder
<markh> well - binaries build from the 1.5.2 dev pack appear to work fine and be internally consistent
<awilkins> Jolly good
<awilkins> I shall grab that one
<markh> so can you build with that?
<markh> cool
<awilkins> Oh hold on
 * awilkins slaps forehead
<awilkins> Maybe if I take the Apache 2.0 version
 * awilkins checks dev pack is not different on each page
<markh> awilkins: its quite possible 1.9 and later bzr binary builds have been made with the 1.4 svn devpacks
<markh> setup.py references them - even though it works with 1.5 - and that is quite possibly exactly what jam did when setting up the binary builds.
 * markh tries to look
<awilkins> If we can get 1.5 working consistently we should use it - well, the reason I am trying is so I can get rid of the per-file properties when pushing over ra_local
<awilkins> I am an idiot
<awilkins> I've been using the apache 2.2 distro with the 2.0 devpack
<awilkins> It would be helpful if they named the archives more extensively
<markh> cool :)  it turns out 1.9 should have 1.5.4 anyway
<awilkins> Right, now I know, I'm turning in, I shall have another go tomorrow.
 * awilkins mumbles curses at management types who insist on SVN even though the rest of the team in question is using Bazaar
<jam> markh, poolie: Kerguelen seems to be up, but seems to not have http access for me to download any data for packaging a 1.10rc1 installer.
<jam> Even browsing to "http://www.google.com" fails
<markh> jam: its not just IE broken?
<markh> IIRc that was one of the updates :S
<linrunix> hi
<markh> jam: any luck?
<hunmonk> hi guys.  does anybody know if the EPEL repo is going to get an updated version of bzr anytime soon?  looks to me like it still has only 1.3
<linrunix> markh: i just upload my project to launchpad
<linrunix> the Initial branch
<linrunix> if somebody wanna change something to a certain file what does he has to do?
<linrunix> let's say he took example.py and changed something... how does he commit these changes?
<linrunix> sorry i'm kind of confused
<markh> linrunix: they would create a local branch or checkout of your project, than commit those changes to that local branch or checkout.  He would then use 'bzr send' to send the changes
<markh> or if he had permissions, he could push or checkin directly to launchpad
<linrunix> yes he has
<linrunix> but what does he do?
<linrunix> he download the branch to his computer
<linrunix> change the file
<linrunix> and commit?
<linrunix> the whole file
<markh> he probably should just do a "bzr cp lp:your_branch"
<markh> oops
<markh> "bzr co ..."
<markh> then make changes, then "bzr ci" - that is the easiest (but probably not the most flexible)
<markh> linrunix: check out http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/tutorial.html
<markh> linrunix: or even better, http://bazaar-vcs.org/Workflows
<linrunix> very thanks
<linrunix> markh: sorry i was reading but it looks like I dont understand it very well
<linrunix> i'm just trying to learn how to use it so.. we can start coding from there
<markh> it could be argued there are too many options :)
<markh> options for ways to work
<linrunix> i got my friend to download the branch
<markh> how exactly?
<linrunix> let me give u how
<linrunix> bzr branch http://bazaar.launchpad.net/~linrunix/pyseleccion
<linrunix> now, does he have to upload his own branch to his user?
<markh> ok - so your friend can then make changes and commit as often as he likes.  When he is ready to submit the changes, he should do a "bzr merge" (in case others have changed the branch since he pulled it), then "bzr push"
<linrunix> bzr push that's it
<markh> then your branch will be updated to have his changes
<markh> anyone doing "bzr pull" etc after that will get them
<linrunix> he doesnt have to have the branch in his user
<markh> he could push it somewhere else if he wants
<linrunix> but to update the actual branch
<linrunix> just a bzr push
<markh> if he can't push directly, or wants you to comments first, for example, he may well push to a private place.
<linrunix> ernie@intrepid:~/Desktop/trunk$ bzr push
<linrunix> bzr: ERROR: No push location known or specified.
<markh> yeah - first time you must say where you want to push to
<markh> bzr doesn't assume you want to push back to the same place
<linrunix> so taht will be  http://bazaar.launchpad.net/~linrunix/pyseleccion right?
<markh> often you don't - you may well want to push somewhere private
<markh> the same url used to pull it would be fine
<markh> it will remember then - so "bzr push" will push back to the same spot thereafter
<markh> but you can obviously specify a new location any time too
<linrunix> like that bzr push bzr://bazaar.launchpad.net/~linrunix/pyseleccion
<markh> that should be fine - but the "lp:blah" version should work too
 * markh can't recall exactly how they all expand...
<linrunix> bzr: ERROR: Cannot lock LockDir(lp-44825360:///~linrunix/pyseleccion/trunk/.bzr/branchlock): Transport operation not possible: readonly transport
<linrunix> any help?
<linrunix> too_short: how do I set the branch so another user can upload too?
<spiv> linrunix: for the error, "bzr lp-login"
<spiv> linrunix: to let other LP users commit to your branch, change it's owner to be a team rather than your user
<linrunix> ok
<linrunix> thanks
<linrunix> spiv: after changing a file i need to commit b4 pushing right?
<linrunix> -m "bla bla bla" right?
<vila> hi all
<VSpike> http://pastebin.com/m6516f466 that looks a bit odd.  How did I get into that state? :)
<awilkins> jelmer: I resolved my bzr-svn with 1.5 svn issue ; I was using the Apache 2.2 binaries and the 2.0 devpack.
<awilkins> D'oh.
<awilkins> jelmer: Why does subvertpy have to go in bzrlib?
<awilkins> jelmer: Or somewhere other than plugins\svn .. I'm not sure I understand this so far
<sven>  sven
<awilkins> This is odd, the exception handler isn't working
<markh> every time I've seen that it's been due to multiple copies of the same module, meaning multiple exception classes that *should* be the same...
<markh> bugger - past midnight - I'm officially late for bed :)
<awilkins> markh: It doesn't even throw
<awilkins> markh: If you feed it a wildcard handler it never triggers
<awilkins> It just spews an error to the console
<awilkins> It works on a console, just not in the bzr-svn code
<awilkins> grr
<awilkins> gnight anyway
<awilkins> Having hacked my way around it, I'm running into other issues
<markh> well - now I'm officially late, a little later wont hurt ;)
<awilkins> 0.4 is working well, this is 0.5 :-)
<markh> oh - still svn woes :(
<awilkins> Heh, the one I've run into looks more like a jelmer issue
<awilkins> 0.5 is supposed to cope with disorganised repos with evil folder histories better
<awilkins> I have a very large repo to test it on.
<awilkins> If it successfully manages to map all the branches in it ( to the point where pulling each one results in a small revision and not over 100MB), I'll be impressed
<awilkins> On the flipside I have a manager demanding I use SVN for an external repository (sob), so the highly-functional 0.4 support is very welcome
<awilkins> I have to migrate this huge backup folder of archived copies and turn it into a repository
<awilkins> Consultants are bad enough, but OLD consultants with no experience of VCS systems.....
<awilkins> Plus all the files are renamed with version numbers... and they all include each other. Grr.
<awilkins> Got that out of the way, mostly, I just need to bend my brain a bit further around which order this next set are in.
<awilkins> I'd go to bed
<awilkins> I'll pester jelmer when he's awake
<jelmer> awilkins, hi
<jelmer> awilkins, subvertpy is under bzrlib.plugins.svn because it's included with the plugin
<awilkins> jelmer: I think I'm having a problem with the import code in svn\__init__.py
<awilkins> jelmer: For some reason it doesn't seem to be catching the first ImportError and trying the code in the except: block
<awilkins> jelmer: Once I hack my way around that, I run into a SubversionException for the case I'm trying.
<jelmer> what's the error exactly?
<awilkins> jelmer: THe import just reports "No module named subvertpy" at the console, the error doesn't percolate to the top of the stack (presumably the plugin loader is catching it)
<jelmer> awilkins, is subvertpy installed in the right location?
<awilkins> jelmer: It's nested in the svn plugin
<jelmer> I never actually install bzr-svn myself, just run it from ~/.bazaar/plugins
<awilkins> Ah, that may be why
<jelmer> bzrlib/plugins/svn/subvertpy/ ?
<awilkins> The "build" command of setup.py makes a different tree to the source
<awilkins> in the source, subvertpy is inside another subvertpy folder
<awilkins> I had to remove the path near line 87 to make that bit work
<awilkins> The join of the path of  __file__ to subvertpy
<awilkins> In the source tree it's svn/subvertpy/subvertpy
<jelmer> I'll fix the imports, one sec
<awilkins> What really puzzled me was that the first import (before it extends the path) fails (as expected) but the exception isn't trapped ; it never gets to the bit where the path is extended.
<awilkins> Debugged with primitive "print" statements
<awilkins> http://paste.ubuntu.com/80356/  # this doesn't work and never prints "Caught the importerror"
<awilkins> But if you remove the exception handling and just go straight for extending the path it works fine.
<jelmer> that import should work fine in your case
<jelmer> because it's a relative import
<jelmer> it doesn't work in a couple of other cases (when importing subvertpy from bzrlib.plugins.svn.mapping3.scheme, for example)
<awilkins> Well, it should work, and printing __file__ confirms that it's the right file being run, but it doesn't
<awilkins> jelmer: Maybe I should look at stack traces more often, the problem is in ra.py
<awilkins> jelmer: Adding the path in svn\__init__.py  just masks it
<awilkins> jelmer: It seems that a number of imports in subvertpy are using the subvertpy namespace to import things that are inside the subvertpy namespace - but it can't find it because it's not on the path.
<awilkins> Once you fix these up to be relative to subvertpy it works fine  ( is doing ' from __init__ import <stuff> ' acceptable ?)
<jelmer> awilkins, that's what the sys.path.insert call is supposed to fix
<awilkins> jelmer: That path call only happens if the initial import fails
<jelmer> it's not correct in your case though
<jelmer> awilkins, relative imports don't work, since it means you can't import any subvertpy stuff from python modules that are not in the top-level code of bzr-svn
<jelmer> as there is no ".." in imports
<awilkins> Ok, so it needs to always add subvertpy to the path regardless then?
<jelmer> or use bzrlib.plugins.svn.subvertpy everywhere
<jelmer> awilkins, to work around it, you should be able to move subvertpy to the top-level for now
<jam> markh: No luck on kerguelen. IE is busted with "No Module Found", but bzr with http:// urls is giving Couldn't resolve host 'bazaar-vcs.org'.
<jam> Could be a DNS issue
<awilkins> jelmer: Moving that package also seems to fix my SubversionException
<jelmer> awilkins, so everything works now?
<awilkins> jelmer: It would appear to.
<awilkins> jelmer: Hmm, that's disapointing ; something in 0.4 is a real memory hog
<awilkins> I tried pushing a branch to a fresh svn repo and on reaching the third revisions it eats 1.3GB of memory
<awilkins> Now, it is a big revision, but the entire bzr repo is less than 65MB
<jelmer> What about 0.5 ?
<awilkins> I think 0.5 was doing it to (but I didn't know whether to write that off as running against a Bazaar with no extensions built)
<awilkins> It rapidly pushes the machine into swap at which point it just crawls
<awilkins> Last I tried it, pulling big repos wasn't a problem
<awilkins> But maybe pushing is different
<awilkins> I mean, pulling still eats a few 100MB
<awilkins> I'm using 0.4 with 1.9 and 0.5 with bzr.dev (no extensions built)
<jelmer> the code that handles some of this stuff is a lot different between 0.4 and 0.5
<jelmer> although 0.4 shouldn't be leaking that much either
<awilkins> Does 1.10 rc1 have "foreign" ?
<jelmer> yes
<awilkins> I suppose it's marked as compatble in the code, that answers my question
<awilkins> Bah, no installer anyway :-)
<jelmer> Importing bzr-svn or bzr.dev into svn works fine here, btw, no heavy memory usage
<jelmer> I wonder what's making it problematic for you
<awilkins> It's a lot more paths and size than bzr.dev
<lifeless> yo
<awilkins> bzr.dev is 1013 files and ~15MB
<jelmer> hey lifeless
<jelmer> lifeless, travelling in some strange part of the world or just awake at night?
<awilkins> This is 6237 paths and 62.5 MB
<lifeless> uds
<awilkins> And most of that happens in a single revision (which it seems to be having trouble with)
<jelmer> ahh, of course
<awilkins> I think that one revision has about 3600 paths in it and most of that data
<jelmer> awilkins, ah, that may be slow indeed
<awilkins> Pulling similar sizes FROM svn repos  (and larger) doesn't seem to cause the same explosion of memory
<jelmer> all texts for the commit have to be kept in memory during push
<jelmer> all changed texts, that is
<awilkins> Ow
<awilkins> Hmm, that's still only 65 MB though?
<awilkins> I realise that overhead is important but... 1.25 GB of it?
<lifeless> jelmer: all at once? Can't you callback on each separately?
<jelmer> awilkins: I suspect there's more going on
<awilkins> As do I :-)
<jelmer> lifeless, it can be done a bit more lazily
<awilkins> It consumes the memory very quickly on reaching that third revision
<jelmer> lifeless, but I doubt that's really the problem here
<awilkins> jelmer: There are quite a few merges in either direction on this branch, would that affect it?
<awilkins> Well, not by the third revision (duh)
<awilkins> Right, time for a shower and a quick forage for wife-food
<awilkins> I shall come back later
<jelmer> awilkins_away, should't matter
<jelmer> python really sucks when it comes to debugging memory usage :-/
 * Tak s/debugging //, get kicked from channel
<lifeless> Tak: it is higher on memory usage than some lower level languages, due to various choices; but it should be ok for nearly everything, as long as you don't leak :)
<lifeless> (where a leak could be contained to a single function but still be very large)
<Tak> I know, I'm only kidding
<Tak> besides, I'm a ruby fan, I don't have any room to complain
<lifeless> heh!
<LarstiQ> jelmer: iirc I've been happy with http://guppy-pe.sourceforge.net/ in the past
<evarlast> can I get a log for a folder in a branch? am I stupid for wanting to do so?
<NfNitLoop> evarlast: I was wanting to do that just the other day.
<NfNitLoop> I didn't find a way to do so, though.
<Tak> hmm - it works for a branch from a svn repo
<NfNitLoop> right, you can bzr log <branch>
<NfNitLoop> but not bzr log <subdir>
<NfNitLoop> or, if you do, you just get a single revision for when the dir was created.
<NfNitLoop> not when all files within that dir were last modified.
<Tak> I mean, it works at the directory level for a branch from an svn repo
<jam> lifeless: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4935F649.2010706%40arbash-meinel.com%3E
<jam> I'd like to base the rest of my work on it
<jam> since it makes the map/unmap "stable"
<lifeless> jam: sure
<jam> thx
<lifeless> upgrading to intrepid right now, and I'm on leave today
<jam> sure
<jam> It isn't something you have to do
<lifeless> if you think its ok, I suggest you build on iti anyhow
<jam> but since martin, you, and spiv are all afk...
<lifeless> or even land it, and we review it later
<jam> I guess I'll go for that, then.
<kjcole> Any instructions on removing a damaged knit file w/o consequence?  I have determined that the contents of the file are something I removed from the repository long ago.
<kjcole> I'm just looking for a way to cascade it's removal without screwing up bzr.
<lifeless> kjcole: so, if the file is used by *any* revision still in the repository, bzr will be unhappy whena ccessing that revision
<lifeless> the easiest way to have a completely clean repo is to make a new one and branch everything into it
<kjcole> lifeless: I tried branching.  No luck.
<lifeless> kjcole: it errored?
<kjcole> lifeless: Yep.
<lifeless> kjcole: ok. do you have any idea of how the damage occured?
<kjcole> lifeless: "bzr check" reveals a zlib.error "invalid distance too far back"
<kjcole> lifeless: No idea how it occurred, but it occcured a long way back: The file in question was removed in revision 3, and the repository's up to revision 80.
<lifeless> kjcole: ok. do you have another copy of it anywhere?
<kjcole> lifeless: I only learned of it while trying to move the repository from an old dapper machine w/ bzr 0.8.2 to a hardy machine w/ a more current bzr.
<kjcole> lifeless: Of the repository? No.
<lifeless> ok
<jelmer> LarstiQ, I couldn't get guppy to work and the project appears to've been dead since 2005
<lifeless> so you have a damaged data file for revision's 1 and 2
<lifeless> and the rest is fine.
<lifeless> (as far as you know)
<kjcole> lifeless: I guess.  Since only a single knit file gives an error, and there are two other knit files with the same starting name...
<kjcole> lifeless: (I'm gonna check the dates on those files.  BRB)
<kjcole> lifeless: all created on the same day.  (It's been a while, but what I believe I did was bzr init, add everything in an existing directory tree, commit, and then weed out the few things I didn't want.
<kjcole> lifeless: (all on the same day).
<lifeless> ok
<lifeless> so I suspect a disk bit error, as its data that bzr has had no reason to touch for a very long time
<kjcole> lifeless: The damaged file isn't something I would have changed -- it was part of the Python Library Reference docs that was inadvertently sitting in the tree.
<lifeless> kjcole: the easiest thing to do would be to trim revision 1 and 2 - by rebasing the rest of the branch
<lifeless> kjcole: exactly, its data that was probably written fine, but not read from for several years
<kjcole> lifeless: This sounds promising.  Thanks.
<lifeless> I believe someone posted to the list a recipe to do this, they didn't have a damaged repo,but rather had text they couldn't show people and needed to eliminate; same principle though
<LarstiQ> jelmer: hmm
<LarstiQ> jelmer: I'm reasonably sure it was guppy that I used a couple of months ago to debug memory issues.
<LarstiQ> jelmer: but I'll look it up after dinner.
<kjcole> lifeless: Oook.  If worse comes to worse, since I don't intend to move backwards on this, I'll try to generate a history report (log plus list of files affected) and just "rm -rf .bzr" and start again.
<kjcole> lifeless: But I wanted to salvage what I could first.
<lifeless> kjcole: you should be able to salvage everything but the damaged revs.
<beuno> lifeless, hey hey. Are you in SFO yet?
<kjcole> lifeless: to the list archives, then -- I hope there was a decent subject line. ;-)
<lifeless> beuno: yes
<beuno> lifeless, cool. We're heading towards the UDS hotel today
<kjcole> lifeless: Thanks again.  Later.
<lifeless> kjcole: anytime
<lifeless> beuno: cool
<vila> jelmer: regarding bug #303959, I'm done with the fixes I could make to bzr. Have you seen my last comment ? Does that sounds right ?
<ubottu> Launchpad bug 303959 in bzr "missing redirect handler: no repository found when pulling a branch from bzr-playground" [High,Fix committed] https://launchpad.net/bugs/303959
<vila> lifeless: it turns out it was a bit more work than anticipated but I think the result was worth it (IMHO)
<lifeless> vila: the key question for me is 'can jc2k pull'
<vila> if jc2k == bug reporter: return True
<lifeless> John Carr
<vila> See the last bug comment for a more elaborate answer
<lifeless> also, 'return jc2k == bug_reporter'
<vila> hehe
<lifeless> I've read it now
<lifeless> yes, I concur, bzr-svn should handle foo->foo/ as 'cannot be a svn repo'
<vila> also, 'ireturn jc2k == bug_reporter' doesn't cover the implicit else: return None :)
<lifeless> it returns False istead
<vila> which isn't the answer I wanted to give :)
<Jc2k> o_O
<Jc2k> bug_reporter.state == 'amused'
<vila> Jc2k: did you try my patch ?
<Jc2k> vila: not yet. just got home, in a bit of a rush..
<lifeless> jelmer: ping
<jelmer> lifeless, pong
<vila>  bug_reporter.state == 'checking_later_I_promise' :-)
<Jc2k> vila: is it in bzr.dev?
<Jc2k> otherwise me needs somewhere to pull or grab patch from
<vila> not yet, but it is in the branch associated with th bug: lp:~vila/bzr/303959-redirection
<Jc2k> ooh shiny
<vila> Jc2k: feeback very welcome since I can't reproduce the bug with my actual setup
<Jc2k> will spin in next 45 minutes if i can, otherwise it will be on my todo for asap
<lifeless> vila: am I right that in theory this bug is fixable just via bzr-svn?
<lifeless> [the actual reported fault, I mean]
<jelmer> lifeless, yes
<lifeless> jelmer: hi
<vila> lifeless: totally
<lifeless> jelmer: so pinging re this bug; also how did split-inv work for you;
<jelmer> lifeless, split inv seems to work fine, especially now those two changes are in
<jelmer> I also noticed that CHKInventory.has_id() is quick while CHKInventory.__contains__() isn't
<lifeless> faster/slower/can't-tell-yet?
<jelmer> In percentages, it's definitely faster (smaller percent of work is now in updating the inventory)
<lifeless> jelmer: __contains__ isn't defined on CHKInventory :P
<jelmer> lifeless, I was seeing references to __iter__
<lifeless> oh right
<lifeless> probably an implicit behaviour
<lifeless> I'll move the __contains__ definition
<jelmer> lifeless, the remaining culprits are:
<jelmer> - Repository.add_inventory_delta() (22%)
<jelmer> - VersionedFile.add_lines() (15.59%)
<jelmer> - VersionedFile.get_record_stream() (13%)
<lifeless> 22% is still quite high
<lifeless> fix for __contains__ pushed
<lifeless> what does that 22% break down into?
<jelmer> let me just run it again locally
<rockstar> lifeless, holy crap, why are you awake!?
<lifeless> I'm in mountain view
<rockstar> lifeless, okay, that makes more sense.  :)
<lifeless> awake is not the right term though
<rockstar> lifeless, about the memory middleware, I can land it, but it's a SERIOUS hack.
<lifeless> rockstar: is it in its own module?
<rockstar> Basically, it reads it's own memory usage from proc
<rockstar> lifeless, yes, loggerhead requires a flag to use it.
<lifeless> rockstar: bzr has a function to do that btw
<jelmer> lifeless, new results:
<rockstar> lifeless, bzr has a serious lack of documentation.  :)
<jelmer> add_inventory_delta(): 13%
<jelmer> CHKInventory.children: 36.12%
<jelmer> VF.add_lines(): 21%
<rockstar> lifeless, one of these days, I'm going to start doing things on my TODO list, and writing docs for bzr is on there.
<jelmer> VF.get_record_stream(): 14.46%
<lifeless> rockstar: we have docs :> problem is knowing what to look for :)
<jelmer> the rest is (obviously) bzr-svn overhead
<lifeless> rockstar: bzrlib.trace.debug_memory
<rockstar> lifeless, I think that Launchpad Code team kinda has that problem too.  Those guys are REAL slackers.  :)
<lifeless> rockstar: probably wants patching to accept a callback function
<rockstar> lifeless, great, I'll take a look at it.
<lifeless> anyhow
<lifeless> I woud land it if its ugliness is isolated
<lifeless> jelmer: are those percent-of-total?
<lifeless> and do you mean CHKInventoryDirectory.children ?
<jelmer> lifeless, yes
<jelmer> lifeless, they are percentages of total
<lifeless> what are the callers of .children?
<jelmer> bzr-svn itself uses it to recursively remove entries, and to find the file id a file had in the lhs parent inventory
<lifeless> for the latter, path2id is better
<lifeless> for the former, can you enlarge? I thought you used an inventory delta now?
<jelmer> except I have to find the id based on the parent file id and the current file name
<jelmer> lifeless, yes, I do use an inventory delta, but inventory deltas require all entries that are removed to be mentioned explicitly
<lifeless> jelmer: ok
<lifeless> so back to finding the id , you have old_parent_id, new_file_name ?
<jelmer> actually, the other way around
<jelmer> new_parent_id, old_filename
<lifeless> this is in the case of a reparenting?
<lifeless> and is old-filename the basename or path_from_tree_root
<jelmer> old-filename is the basename
<jelmer> I can work around it and only check children in case there is a reparenting
<jelmer> but it surprises me a bit .children is so slow, even though it could've cached that data
<jelmer> (since this is a from-scratch import, and all the inventory entries have been added in this session)
<lifeless> jelmer: entry.children is dynamically populated
<lifeless> apply_by_create starts with a fresh cache
<lifeless> jelmer: so, you have new_parent_id, old_basename - and do you know what the old_parent_id was?
<lifeless> (i'm trying to understand whats really going on here)
<lifeless> we have a (parent_id, basename) -> file_id index in development4
<lifeless> its not really exposed directly, but if it fits your needs we can make sure it is
<jelmer> that is *exactly* what I would need here
<lifeless> bbs I hope
<lifeless> jelmer: do an isintance and have a poke at it then
<lifeless> see CHKInventoryDirectory.children for example code
<jelmer> Thanks
<lifeless> jelmer: I wasn't sure it would help though because you have a new,old pair rather than new,new or old,old
<jelmer> lifeless, what's the easiest way to query parent_id_basename_to_file_id for this sort of information?
<jelmer> I see a iteritems(), but I'd rather avoid that if possible..
<jelmer> lifeless, in a lot of cases, it will actually be old,old
<jam> lifeless: I also noticed create_by_apply_delta being a bit slow for the mysql conversion, (about 50% of total time), and I'm guessing it is because we start with a fresh cache each time.
<jam> Well, CHKRepo.apply_inventory_delta() reads the basis revision_tree from scratch
<jam> which means it has to page in everything
<jam> even if it just paged in that one
<lifeless> jelmer: iteritems([(id, name)])
<lifeless> jam: it needs a page cache not an entry cache I think, for this particular use case
<jam> lifeless: I think we need *something* :)
<lifeless> jam: sure
<jam> There are several bits that may effect this
<jam> 1) hash tries shrink the tree depth, so we probably won't have as many pages to bring in
<lifeless> jam: what mysql conversion are you referencing in this conversation btw
<jam> converting my mysql repo to --dev4
<lifeless> kk
<jam> The current tries are about 9 nodes deep
<jam> w/ something like 18 node changes per commit
<jam> let me double check
<jam> average of 18.8 inv changes per revision
<jam> average depth of 6 for the file_id=>entry
<jam> and depth of 9 for pid,name=>file_id
<jam> max depth 17, 19 respectively
<lifeless> jam: lets hook in it and then perf test; we can change our minds :)
<jam> with an average of 3.8 texts per commit
<jam> 2) a page cache would make accessing the pages cheaper
<jam> the problem is figuring out what the lifetime is
<lifeless> jelmer: iteritems with a filter should be very efficient
<jam> since it seems like it should be shared between all the CHKInventories at least
<lifeless> jelmer: so you can actually query all your changes for a commit at once
<jelmer> lifeless, thanks, iteritems() seems to work
 * jelmer does another lsprof run
<jelmer> unscientifically speaking, it seems to be faster
<lifeless> :P
<beuno> so...
<beuno> anyone know what could cause this: http://paste.ubuntu.com/80499/
<beuno> new error for me
<lifeless> jelmer: jelmer for the 'recursive file id gathering'
<beuno> ah, bug 303856
<ubottu> Launchpad bug 303856 in bzr "caching writes to pack repository causes ShortReadvError on pushing stacked branch" [High,Fix committed] https://launchpad.net/bugs/303856
<jelmer> lifeless, the recursive file id gathering doesn't affect performance I think
<beuno> mwhudson, ping
<jelmer> not significantly, I mean
<jelmer> lifeless, It only gets called in the rare situation that you remove an entire subtree
<jelmer> lifeless, the other code (parent_id,basename->file_id) gets called at least once for each changed file
<lifeless> jelmer: yeah, you can write a recursive query just on that index though
<lifeless> jelmer: that will avoid processing all the entry data for the removed files
<jelmer> lifeless, ah, cool
<lifeless> jelmer: so did you get an lsprof result with the updated code?
<jelmer> almost done, just 300 more revisions left
 * jelmer uses the vala svn repository for testing these days
<lifeless> jelmer: what are vala's dimensios
<jelmer> 2400 revisions, 817 files in the last revision
<lifeless> so small :)
<lifeless> beuno: update your bzr, you will be fine
<jelmer> lifeless, well, this used to take a few hours with bzr-svn :-)
<lifeless> jelmer: ah
<lifeless> jelmer: I think you will like CommitBuilder.record_iter_changes
<jelmer> anyway, results are in:
<jelmer> seems this just isn't a signifcant factor anymore..
<beuno> lifeless, doing that now...
<beuno> crappy hotel wireless
<jelmer> VF.get_record_stream(): 25%
<jelmer> Repository.add_inventory_delta(): 18%
<jelmer> VF.add_lines(): 30%
<jelmer> svn file parsing, etc; 12%
<jelmer> the rest is overhead from bzr-svn itself
<jelmer> lifeless: in other words: please can we have Inventory.parent_basename2id() ?
<lifeless> jem er, lets make it generalish
<lifeless> e.g. Inventory.iter_child_ids([(parentid, None_or_asename...])
<lifeless> the same interface as iteritems on the dict
<lifeless> that can be easily implemented on Inventory, and on CHKInventory is a trivial thunk
<jelmer> sure
<lifeless> it (return self.parent_id_basename_to_childid.iteritems(query))
<lifeless> jelmer: if you wanted to doa patch for bzr.dev adding that for Inventory, I'd be delighted to review it.
<jelmer> Yeah, I'll have a look at doing that
<jelmer> lifeless: create_by_apply_delta() is slow mainly because of CHKMap.apply_delta() (11%) and CHKInventory.__getitem__ (5.8%)
<lifeless> so, the 11% is the delta application
<lifeless> make sure you're running up to date brisbane-core
<lifeless> uhm
<lifeless> can you drill into those a little further? or post a callgrind file ?
<jelmer> CHKMap.map() takes 7.6%
<lifeless> within the 11%?
<jelmer> No, out of the total
<jelmer> so ~ 70% of CHKmap.apply_delta()
<jelmer> http://samba.org/~jelmer/bzr/vala.callgrind
<lifeless> yes, but is all that from apply_delta I mean
<jelmer> yes, it's all from apply_delta
<jelmer> unless I'm interpreting the view kcachegrind gives me wrong
<lifeless> oh nice, kcachegrind got a facelift
<lifeless> so 2000 delta calls becomes 14K map calls
<lifeless> and 17K map calls
<lifeless> sorry 14K __getitem__ calls before
<lifeless> and that 17K becomes 58K with recursive handoffs
<lifeless> but _iter_nodes is 70%
<lifeless> (relative)
<lifeless> and get_record_stream is 63% of that
<lifeless> so if you wanted to do an experiment
<lifeless> add a global cache (using the LRUCache) in chk_map.py
<lifeless> whenever a page is read
<lifeless> add the page under the CHK
<lifeless> e.g. sha1:123456789012347890 -> page_bytes
<lifeless> and in _iter_nodes lookup pages there first
<lifeless> make it a decent size, say 2M == 512 items
<jelmer> lifeless: It's going to take me a while to do that, given that I'm not familiar with that code. Do you perhaps have those changes ready ?
<lifeless> let me take a quick toilet break and I'll whip it up
<jelmer> or can you point out what exactly to insert, etc?
<jelmer> thanks
<`mousey> does anyone know if you can diff a single file when using tortoisebzr? everytime I try to diff revisions it shows a diff of every single modified file
<beuno> http://tech.slashdot.org/article.pl?sid=08/12/04/1625226
<beuno> gittorrent?
<lifeless> `mousey: right mouse on the file perhaps?
<lifeless> jam: ping
<lifeless> jam: you use get_record_stream directly quite a bit; I'd like to avoid that if we could, helper function on $object - like the _read_bytes one perhaps
<lifeless> jam: also, why do you use an adapter rather than just asking for get_bytes_as('fulltext') ? You have asked for them to be fulltextable always
<lifeless> jelmer: pushing a read record cache now, writes-into-cache in a second
<lifeless> jelmer: give it a spin
<lifeless> jelmer: - still here?
<arrbee> /topic
<`mousey> lifeless: yeah, I've tried the right mouse, and it shows the revisions where the file was modifier, however doing a diff on 2 revisions will show every file that was changed between the 2 revisions
<`mousey> i'm not sure if it's a bug or an intended feature
<lifeless> if you're entering the historic diff from a single-file, I'd call it a bug, but if you're entering from a directory, its usualy to show the recursive diff
<lifeless> jelmer: ping
<markh> jam: did you have any luck with that box?
<`mousey> yeah, it sounds like a bug. I'll see if I can fix it and supply a patch
<`mousey> oh, also, is it possible to kick off an external merge program when diffing a single file from tortoisebzr?
<lifeless> `mousey: I don't know
<Rolly> you can with the command line
<Rolly> maybe you could alias the diff command
<lifeless> jelmer: ping
<markh> jam: apparently not :)  it appears there is no dns
<jelmer> lifeless, re
<jelmer> lifeless, are you still there as well ? :-)
<jelmer> VF.get_record_stream(): 25%
<lifeless> jelmer: yes
<jelmer> VF.add_lines(): 37%
<jelmer> Repo.add_inventory_delta(): 10.78%
<jelmer> svn overhead: 12%
<jelmer> that's with your first revision
<lifeless> jelmer: is that a significant improvement?
<jelmer> lifeless, add_inventory_delta() is down 7%
<lifeless> good
<lifeless> ok, use the second rev, should be better still
<mwhudson> beuno: hi
<jelmer> lifeless, running
<mwhudson> beuno: pong pong
<lifeless> is it :cvar: to epydoc a class variable?
<mwhudson> lifeless: yes
<beuno> mwhudson, hi hi!
<beuno> what can you tell me about bug 303856
<ubottu> Launchpad bug 303856 in bzr "caching writes to pack repository causes ShortReadvError on pushing stacked branch" [High,Fix committed] https://launchpad.net/bugs/303856
<beuno> I upgraded to the latest bzr nightly
<beuno> but it still broke
<beuno> I had to delete and push again
<mwhudson> beuno: it was caused by an interaction between the new autopack code and some caching
<beuno> mwhudson, and it
<mwhudson> it was disabled in the 1.10 branch at least
<beuno> it's suppose to be fixed in trunk?
<jelmer> lifeless, last change doesn't seem to've helped much
<mwhudson> dunno, bzr log --short | less and read i guess :)
<lifeless> jelmer: interesting; are you sure the first run only had the first patch ? :)
<jelmer> get_record_stream() -> 25%, add_inventory_delta() -> 11%, add_lines() -> 36%
<jelmer> lifeless, perhaps the first run had the second patch as well
<beuno> mwhudson, heh, ok
<lifeless> jelmer: ok
<beuno> mwhudson, did you happen to peak at my email about LH?
<mwhudson> beuno: only peek
<lifeless> so 25% reading from disk, 36% writing to disk (will incur a read as well, for every write), and 11% in metadata
<beuno> right, so I haven't tricked anyone into fixing it yet
<lifeless> jelmer: is < 50% of the time in bzrlib ?
<jelmer> lifeless: basically, yep
<mwhudson> beuno: i'll read it more thoroughly next week i guess
<beuno> mwhudson, I hope to make time to fix it by then. We'll see
<beuno> it would be good to rollout the latest version on LP soon-ish
<lifeless> jelmer: well, I'm happy with bzrlib being less than half the time
<lifeless> lower is better of course
<jelmer> lifeless, well, 25%+36%+11% > 50%
<lifeless> jelmer: add_lines uses get_record_stream
<lifeless> jelmer: I'm not sure those figures are summable; can you post the callgrind?
<jelmer> lifeless, according to callgrind it uses get_content_maps but not get_record_stream()
<jelmer> http://samba.org/~jelmer/bzr/vala.callgrind
<jelmer> back in ~30
<lifeless> kk
<lifeless> jelmer: there is definitely still overlap
<lifeless> apply_delta -> get_record stream
<lifeless> and -> add_lines
<lifeless> why does fetch call get_record_stream?
<lifeless> jelmer: I will be back, but afk for a bit (heading to hotel)
<jelmer> lifeless, fetch calls get_record_stream() to fetch the data so it can apply the svn delta to it
<jelmer> at the moment, I only have an implementation of the svn delta algorithm on streams
<jelmer> bytestreams, that is, not line-streams
<jelmer> if there's some easy way around that, I'm interested :-)
#bzr 2008-12-05
<lifeless> jelmer: what deltas does svn use?
<lifeless> ideally you can provide an adaptor to allow you to use insert_record_stream
<jelmer> it's byte-based
<lifeless> ok
<lifeless> so add_lines does get_lines(), applies delta, does a diff(), writes the text out
<jelmer> basically it's a list of instructions like "insert this sequence of bytes at offset X"
<lifeless> so we're doing twice as many get_lines() as needed
<jelmer> ah, cool
<lifeless> this will be nontrivial for you
<lifeless> but look at insert_record_stream
<lifeless> conceptually, you would define a new record type ('svn-delta')
<lifeless> and then look at KnitVersionedFile.insert_record_stream to teach it how to coerce that to a more useful form
<lifeless> the key thing is that in that function you can e.g. emit a knit record directly (because you may know what lines were altered, or something similar)
<jelmer> hmmok
<lifeless> some assembly will be required, but the goal of the interface is to permit this - as the first external user, you'll have to poke things to line up more
<jelmer> I'll file a bug about this, it's something nice to look at in the future but I'd like to get 0.5 out at all first
<AfC> lifeless: batteries not included
<lifeless> jelmer: yes, for sure
<TheMuso> c
<Toksyuryel> Is a feature like this planned for bzr? 'cause that would be pretty awesome http://tech.slashdot.org/tech/08/12/04/1625226.shtml
<Rolly> Looks interesting
<mneptok> KERNEL 2.6.35 = AWESOME QUALITY!!!! 10/10!!! PLZ SEED! (p.s. doesn't play on my 286. i have VLC).
<lifeless> Toksyuryel: I don't know of anyone working directly on it; doing dissemination based networking is probably better down further down the stack so that mor ethings can benefit, but - if someone gets the bug and haks it up, the more the merrier
 * Toksyuryel nods
<vila> hi all
<lifeless> hi vila
<lifeless> beuno: yo
<beuno> lifeless, hey hey
<lifeless> so
<lifeless> I want to show you a little about using the profiling middleware
<lifeless> cause it just confused me :)
<lifeless> are you crashing yet, or got a few ?
<beuno> I have a few. IRC or RL?
<lifeless> IRC is fune
<lifeless> *fine*
<beuno> ok, sjoot
<beuno> er
<beuno> shoot
<lifeless> to start with, get a browser with lh running against something that is indexed
<lifeless> svn is best, but you probably haven't pulled all the branches etc yet
<lifeless> so bzr.dev or lh itself or something, it sfine
<beuno> I've got LH on LH indexed and running
<lifeless> kay
<lifeless> type something into the search box without hitting enter
<lifeless> just to get completion results showing
<lifeless> now, stop lh
<lifeless> and run it with --profile
<lifeless> then hit the down arrow key once in the browser, which will cause a single refresh of the completion results
<lifeless> stop lh
<lifeless> and run kcachegrind 1-stats.callgrind
<beuno> http://paste.ubuntu.com/80740/
<beuno> traceback!
<lifeless> you have an old bzr-search, I fixed that bug
 * beuno pulls
<lifeless> TMI
<beuno> hrm
<beuno> pulling didn't do it
<beuno> of course, it helps if I pull the right thing...
<lifeless> what did you pull?
<beuno>   File "/var/lib/python-support/python2.5/paste/httpserver.py", line 166, in wsgi_start_response
<beuno>     assert 0, "Attempt to set headers a second time w/o an exc_info"
<beuno> AssertionError: Attempt to set headers a second time w/o an exc_info
<lifeless> heh
<lifeless> well hit down again, until it works
<beuno> I pulled bzr-search, but not the one that I'm using for bzr
<lifeless> then cachegrind the one that worked
<beuno> ok, nothing seems to be working
<beuno> maybe I should stop doing it on a checkout
<lifeless> just do bzr unbind
<lifeless> you canbzr bind later
<beuno> ok, now
<beuno> let's run it through kcachegrind...
<beuno> which I don't have, and will take 22 minutes to get with all it's deps.......
<lifeless> heh
<lifeless> get it, you needs it
 * beuno stares at apt while it downloads
<lifeless> give it tha ol evil eye
<lifeless> ok, so let it install, I show you tomorrow
<beuno> kei
<beuno> it's really insisting on taking those full 22 minutes
<beuno> so it's downloading
<beuno> and I haave that callgrind file
<beuno> so we can have fun on the bus tomorrow
<lifeless> :>
<lifeless> I have a question
<lifeless> what are 'apps'
<beuno> that's a question for mwhudson. He chose the name, and I just made it work in my head. To me, it's the paste stuff.
<lifeless> ok
<lifeless> cause its the branch app that appears to be chewing up time
<beuno> that's odd, it shouldn't really do much
<lifeless> it calls get_history unconditionally AFAICT
<beuno> which should have a nice cache
<beuno> both internal and sqlite
<lifeless> profile -> trasnlogger -> httpexceptions ->apps.error ->apps.filesystem ->apps.filesystem->apps.branch->search
<lifeless> we call last_revision twice
<beuno> ah, hm
<lifeless> it takes 56% of the time
<beuno> that's bad
<lifeless> ciao!
<lifeless> see you on ze bus
<beuno> :)
<beuno> have a good night
<nbjayme> hello all. greetings from the philippines!  did launchpad change the port number of the bzr+ssh access? i keept on having a Connection timeout error on port 22. :(
<Peng_> nbjayme: No, it didn't.
<Peng_> nbjayme: You might find #launchpad more helpful.
<nbjayme> thanks Peng_.
<nbjayme> my clumsiness.... ï»¿bzr push sftp://bazaar.launchpad.net <---- is the right url.
<jam> vila: ping
<vila> jam: pong
<jam> good morning
<jam> Any chance you could try to review: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E
<jam> I mentioned it to Aaron yesterday, but he hasn't commented.
<jam> It seems it is a fairly serious regression in stacked repositories
<jam> so I'd like to land it before 1.10
<jam> Also, I wanted to chat with someone whether I should be releasing 1.10-final today, or doing rc2 instead ?
<jam> (Given that bug)
<vila> Re-reading (but from last read you got at least a BB:I-like-the-topo-order-so-go-go-go :)
<vila> You have one import pdb; pdb.set_trace()
<vila> jam: My feeling there (having read the thread as it came in) is that sorting by topo order is the key.
<vila> You know my feelings about it and here you say it makes things simpler (good) so it should make it more robust
<jam> vila: thanks for catching the pdb, it sure stands out in BB :)
<vila> Now, as you describe it, this bug is nasty and hard to reproduce which testify that you have a good grasp on it. As such, you make reviewer life hard: either I give you an approve nased on trust or I need to work as hard as you :)
<jam> So... with just the topo-order fix, it will still create Fulltexts at merge revisions
<vila> OrderingVersionedFilesDecorator is just a test helper ?
<jam> OVFD is a test helper, yes
<jam> I split it out into another patch
<jam> though perhaps that got "superseded"
<vila> Wow, so you really pinpoint the bug in the test
<jam> yeah, it di: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4936F5EF.2060208%40arbash-meinel.com%3E
<vila> Ha, I thought I read that but wasn't finding it in the submission
<jam> vila: yeah, the bug is really a cascade of about 3 different failures
<jam> which made writing a test case.... interesting
<jam> Considering the fix was small, it took me all day to finish the test case.
<jam> but at least I got a full handle on the bug
<vila> That itself grants aBB:approve I think
<jam> and feel confident about the fix
<vila> The code modification is light, you ran the full test suite ?
<jam> I did not, I'm on win32 where it doesn't pass anyway
<jam> I ran bits I thought were appropriate
<jam> (And trust that PQM will run the whole thing for me :)
<vila> Ok
<vila> jam: voted
<vila> Now, regarding inclusion in 1.10, I'm not the RM, but given the effort that went into stacked branches related bugs, I'll vote for inclusion
<vila> Are *you* the RM ?
<jam> I'm the RM for 1.10-final(ish)
<jam> yes
<jam> poolie is away
<vila> So, I didn't follow closely the bug history, were there some feedback that triggered your patch based on 1.10rc1 or is it just a work-in-progress that happens to be finished now ?
<vila> I don't have a strong preference for rc2 or final anyway as long a 1.11 serie is opened anyway  :-)
<jam> vila: bug #304841 is on 1.10rc1 + martin's patch
<ubottu> Launchpad bug 304841 in bzr "bzr push raises RevisionNotPresent" [Critical,Fix committed] https://launchpad.net/bugs/304841
<jam> his patch was for bug #303856
<ubottu> Launchpad bug 303856 in bzr "caching writes to pack repository causes ShortReadvError on pushing stacked branch" [High,Fix committed] https://launchpad.net/bugs/303856
<vila> I mixed up the two, thanks
<vila> 303856 was targeted to 1.10final, that's a good hint to go with final
<vila> I mean, you already put more polish on it (and addressed a critical bug), release !
<balor> I accidently added a directory to my bzr repo.  I've not checked in the change.  Is there any way to undo adding the directory (and it's contents) before I check in?
<balor> bzr remove
<balor> just works
<jam> balor: "bzr rm --keep"
<balor> jam: I did bzr rm --force
<balor> jam: then recreated the dir.
<balor> jam: thanks though.
<jam> np
<jam> keep would have meant not needing to recreate it
<LeoNerd> I've just installed bzr-svn and I'm trying to  bzr push svn+ssh://server/path  from my existing bzr native branch. I get an instant assert error, which doesnt' seem to give much detail. Anything I can try to debug this?
<LeoNerd> The particular line that fails is   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/remote.py", line 52, in __init__
<LeoNerd>     assert svn_url.startswith(self.svn_root_url)
<lifeless> balor: or bzr revert <dir> would have kept it too
<LeoNerd> Ooh... OK.. bug perhaps?
<LeoNerd> svn+ssh://server//root/path/here   dies,   svn+ssh://server/root/path/here   works fine
<jelmer> LeoNerd, any chance you can file a bug?
<LeoNerd> debian reportbug be OK?
<jelmer> yeah, sure
<LeoNerd> done
<lifeless> hi jelmer
<jelmer> 'morning lifeless
<lifeless> jelmer: did you see the bzr-svn branch I tossed up?
<jelmer> lifeless, yeah, thanks for that
<jelmer> lifeless, I'm about to rebase it on 0.5
<lifeless> jelmer: ok
<jelmer> lifeless, merged into 0.5
<lifeless> jelmer: thanks. bzr-search needs get_transaction on repository (not direcyly, but  for Repository.iter_file_bytes
<jelmer> fwiw, bzr-svn doesn't do Repository.iter_file_bytes()
<lifeless>   File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/repository.py", line 1399, in iter_files_bytes
<lifeless>     transaction = self.get_transaction()
<lifeless> it inherits it
<lifeless>   File "/home/robertc/.bazaar/plugins/svn/repository.py", line 175, in get_transaction
<lifeless>     raise NotImplementedError(self.get_transaction)
<LeoNerd> Mm.. So this "determining changes" it's running on a new repo.. What's that for, and how long is it going to take?
<LeoNerd> It's been chewing away for about 10 minutes now..
<lifeless> jelmer: nvm, it canbe fixed in bzrlib.
<lifeless> jelmer: this is a bit odd
<lifeless> $ bzr search radix
<lifeless> stacking support in bzr-svn is experimental.
<lifeless> nevowlore.py in ...
<lifeless> LeoNerd: it is calculating the shape of the repository in bzr terms
<lifeless> LeoNerd: branches, per file graph and the like
<LeoNerd> Right. It suddenly finished without warning :) I think the progress meter is broken
<lifeless> LeoNerd: following that it will be able to start pulling
<LeoNerd> It was claiming 0/204005 for aaages
<LeoNerd> Hrm.. it doesn't preserve timestamps. No big issue, but it just upsets the stats a bit :P
<lifeless> how do you mean?
<LeoNerd> I've pushed a bzr branch into the svn repo, and according to our "trac" view of svn, it was all modified a few minutes ago, rather than last week
<jelmer> LeoNerd, see the FAQ
<jelmer> you can make bzr-svn modify the svn:date property, but it requires changing the settings in your svn repository
<LeoNerd> Ahhright
<lifeless>  jelmer so - whats that stacknig warning about, that svn branch isn't stacked
<jelmer> lifeless, it happens whenever versionedfiles are involved
<lifeless> :( I know this is a repeating theme, but how can I turn that warning off?
<jelmer> there's no way to disable it at the moment
<jelmer> I'd rather not allow turning that off, at least not in any released versions of bzr-svn, as the versionedfiles stuff is pretty much untested
<jelmer> and it allows people to do b0rked imports
<jam> lifeless: BB:approve on the iter_file_bytes fix, though if you could wait to submit it until after I've gotten 1.10 out the door, I would appreciate it
<lifeless> jam: that was fast :P
<lifeless> jam: tell me when to land it
<lifeless> jelmer: how do you mean [borked imports]
<jam> lifeless: I saw it on the bazaar-commits list while going through some other stuff :)
<jam> I'll let you know when PQM is free
<jelmer> lifeless, if you use "bzr branch --stacked" it uses versionedfiles and that can broken
<jelmer> if there's some easy way to only warn when doing a stacking clone, I'm happy
<jam> lifeless: for your InterDifferingSerializer change (where you buffer 100 revs at-a-time, and use apply_inventory_delta). What tests should I be looking at bringing across?
<jam> I found a couple small issues for it
<jam> and would like to get it merged into bzr.dev
<jam> so we can have the improved version in-play and under-regular-testing
<lifeless> jam: I had hit commit 2 seconds earlier :)
<lifeless> jelmer: what goes wrong with the imports if they do this?
<lifeless> jam: well first, add_inventory_delta, which poolie had some review feedback on
<jam> lifeless: I don't see your "apply_inventory_delta" fix in BB
<jam> ah, this one? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480811102304s60b1df9cnf62aec9748a61346%40mail.gmail.com%3E
<jelmer> lifeless, inconsistent text parents, text contents
<lifeless> jelmer: !
<lifeless> jam: no
<jelmer> lifeless: this is why there is a warning :-)
<jam> yeah, looking closer I realized that
<jam> still looking
<lifeless> jelmer: your warning is not accurate :P its not experimental its known broke
<jelmer> lifeless, I'm not aware of any cases where that has happened, but the code is not very well tested
<jelmer> and that's the sort of thing that *would* happen
<lifeless> jelmer: oh
<lifeless> jam: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1223873271.9015.266.camel%40lifeless-64%3E
<jam> lifeless: what do you think about calling it "add_inventory_by_delta" ?
<jam> And was Martin's main complaint that it was against an arbitrary rev? Rather than only the basis?
<jam> I guess you already agreed to _by_delta
<lifeless> I'm fine with add_inventory_by_delta, it is more clear
<jam> I guess I'm a bit confused by his comment: "I still think it's dangerous to have something that looks like a delta  but is not,"
<lifeless> thats the basis_delta list
<jam> If you haven't said "recording_deletes = True" it is not an accurate delta?
<lifeless> see the list for a convesation - bb deleted his initial comments when he commented again
<lifeless> jam: yes
<lifeless> jam: so I proposed to him that we make basis_delta be get_basis_delta()
<jam> and we need to not have a delete for the current functionality?
<lifeless> and if you haven't called recording_deletes, then get_basis_delta() errors
<jam> that sounds ok, but I don't quite have a grasp on when/why you need to *not* record the deletes in the basis_delta
<jam> It seems like you would need it to update the WT as well
<lifeless> the existing commit driver generates it's own basis delta object
<lifeless> that is
<lifeless> in bzr.dev, and anything like plugins that is using CommitBuilder directly, code makes its own delta by using the return value from record_entry and adding deletes by hand
<lifeless> with the patch, commit.py is fixed, but other clients wouldn't be - they would end up with a CommitBuilder object with what 'looks' like a good delta, but still wouldn't have deletes in it
<Tak> are there existing bzr icons somewhere for things like branch, pull, merge, ...?
<lifeless> Tak: bzr-gtk might have some
<lifeless> jam: breakfast time
<jam> lifeless: eat hardy. I think I have a feeling now
<jam> so basically, you want get_basis_delta() to fail if you aren't aware of the new API
<Tak> it appears to be using stock gnome icons atm
<lifeless> jam: yah; simply if !self._recording_deletes: raise AssertionError("you can't use this until you've updated your apip usage per ...")
<jam> lifeless: So... to set this variable True... we could do a Constructor variable, or bikeshed a bit on the proposed name (will_record_deletes()?). I prefer the constructor approach, except you have to pass it through Repository.get_commit_builder() which is a bit ugly
<jam> I suppose we have a slightly smaller api compatibility issue if we just have a function on CommitBuilder
<jam> as SVNCB can just inherit that function
<jam> (though if it doesn't respect it... we have a problem anyway, so probably better to have it fail)
<jam> who are all these people that have bzr-dbus installed?
<jam> Is it a Recommends somewhere?
<lifeless> jam: for compatibility I avoided constructor
<jam> yeah, I went that route too
<lifeless> jam: a client that does not use the function will work fine
<lifeless> jam: because they won't try to get the delta, and the finish_inventory method knows to only use the delta if it is going to be valid
<lifeless> jam: probably
<lifeless> (re bzr-dbus)
<jam> ?
<lifeless> 03:11 < jam> who are all these people that have bzr-dbus installed?
<lifeless> 03:11 < jam> Is it a Recommends somewhere?
<jam> Ah probably a Recommends
<jam> sure
<jam> I thought that was the last line of the previous statement. :)
<jam> lifeless: for the default implementation of "add_inventory_by_delta". Should we be adding "create_by_apply_delta" to Inventory and using it instead?
<jam> It means requiring an Inventory.copy() which is a bit slow
<jam> but is necessary for CHK inventories.
<jam> We happen to know the lifetime of the inventory in add_inventory_by_delta is safe
<jam> but apply_delta is not always a safe function otherwise.
<lifeless> jam: I don't think so
<jelmer> jam, bzr-gtk recommends bzr-dbus
<lifeless> jam: create_by_apply_delta doesn't make sense to me on th ein memory invetory, not in the same way
<lifeless> jam: the key ting here is that *repository* is the interface for adding inventories to
<lifeless> jam: heading over to MV now, lets chat in about 2 hours ater the opening
<jam> np
<jam> enjoy the show :)
<jam> lifeless: you can go ahead and submit your iter_files_bytes fix.
<jkakar> I've just added 11MB of crap to a branch and committed it... and then realized that will bloat subsequent branches after merging this one to trunk.
<jam> jkakar: bzr uncommit
<jkakar> jam: That won't work, as I did the commit several revisions ago.
<jam> jkakar: it would still work, you just have to do more to get things back
<jkakar> jam: I've realized I can trim down that 11MB to 300k and now want to remove the history of that 11MB entirely...
<jam> however, you can install the bzr-rebase plugin
<jam> and have it help you recreate the extra revs
<jkakar> bzr-rebase has never worked for me.  I probably don't understand how to use it.
<jam> jkakar: I *think* you want bzr uncommit -rBEFORE_I_WAS_FOOLISH
<jam> bzr revert
<jam> bzr replay -r AFTER_I_WAS_FOOLISH..-1
<jam> well, you probably need to keep 1 branch around to replay from
<jkakar> Woah.  I'll try that, thanks.
<jam> make sure to check "bzr help replay" just in case I have some syntax wrong
<jkakar> jam: It worked!   Thanks a lot. :)
<jam> np
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | 1.10 is released! (5 Dec) | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<lzhang> is there an easy way to see files that have been bzr rm'd in the file?
<lzhang> in the current directory*
<lzhang> bzr rm'd and committed in the past
<etank> I have bzr installed on an ubuntu box and the windows bzr installer on a XP box. how can i do a checkout/branch/clone of my repo to on the Windows box?
<etank> the initial bzr init, etc was done on the ubuntu box
<jam> jelmer: ping, you just announced bzr-svn 0.4.16, but it doesn't seem to be tagged in http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/
<jelmer> bleh, I suck at this
<jelmer> jam, Sorry, that's at least the third time you have to remind me :-(
<etank> i get the following when i try to do a branch
<etank> C:\Documents and Settings\user\Desktop>bzr branch ssh://user@ipaddr:~/Code myCode
<etank> bzr: ERROR: Unsupported protocol for url "ssh://user@157.184.82.74:~/Code"
<jelmer> etank, you probably want sftp:// or bzr+ssh://
<jelmer> jam, should be tagged now
<jam> jelmer: so you are now tagging it as "debian-0.4.16" right?
<jam> rather than bzr-svn-0.4.16
<jam> btw, 0.4.15 also is not tagged
<etank> jelmer: with either of those i get this now "bzr: ERROR: Invalid url supplied to transport: "invalid port number ~ in url:"
<jelmer> etank, please use a / rather than a :
<jam> etank: the URL you want is probably: sftp://user@host/~/Code
<jam> if you want to use bzr+ssh then it would be
<etank> ok
<jam> bzr+ssh://user@host/home/user/Code
<jelmer> jam, yeah, debian-0.4.16-1
<jam> bzr+ssh doesn't support ~ yet
<jam> jelmer: that really messes up the bzr-builddeb I have
<jam> as in... it always wants bzr-svn-0.4.16
<jelmer> jam, I'm still tagging the upstream release as bzr-svn-0.4.16
<jam> Ah, I guess I just need to edit .bzr-builddeb/defaults.conf
<jelmer> jam, just the debian packaging as debian-0.4.16-1
<jelmer> jam, so you want to merge in debian-0.4.16-1 but have it build against bzr-svn-0.4.16
<jam> k, I should mention the bzr-svn-0.4.16 isn't there *either*
<jam> and neither is 0.4.15
<jam> nor debian-0.4.15
<jelmer> ah, that's actually a bzr-builddeb bug that I think has been fixed
 * etank is wondering if using the python sources would be better
<jam> anyway, if I go back and "bzr merge lp:bzr-svn && bzr revert && bzr merge lp:bzr-svn/0.4" I seem to have all the tags
<jelmer> jam, now pushed with the original upstream tags
<etank> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require
<jam> I'm not sure why they aren't in your packaging branches
<etank> d)
<etank> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x01714810>
<jelmer> jam, bzr-builddeb's "bzr merge-upstream" command used to not pull in tags
<etank> thats what i got with  bzr+ssh
<jelmer> I think James fixed that recently
<jam> etank: if you are getting that, it means the ssh connection closed
<jam> What version of the bzr client are you using ?
<etank> im not sure why though
<etank> one sec
<jam> "bzr --version" should tell you
<etank> bzr-setup-1.9.exe
<etank> Bazaar (bzr) 1.9
<jam> k, that one should be fine
<etank> i can ssh to the box with no problems using putty
<jam> etank: are you using custom keys or anything like that?
<jam> or just username & password?
<etank> nope. password loging
<etank> login i mean
<jam> and when you do "bzr branch bzr+ssh://..." it doesn't prompt you for a password?
<etank> jam: nope
<etank> C:\Documents and Settings\elake\Desktop>bzr branch bzr+ssh://elake@157.184.82.74/Code myCode
<etank> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require
<etank> d)
<etank> that is the exact ouput
<etank> i wonder if it is something in the sshd_config that needs to be changed
<jam> etank: ah, I have an idea
<jam> try doing
<jam> set BZR_SSH=paramiko
<jam> on the command line
<jam> and then running bzr branch
<jam> and if that fails
<jam> try
<jam> set BZR_SSH=plink
<jam> plink should fail because it doesn't support passwords as a sub-process
<jam> but it may fail in a *different* way
<jam> etank: did you rename "plink" to "ssh" btw?
<jam> as that would probably confuse us
<etank> nope
<etank> neither of those worked
<etank> pscp elake@elake-ibex:/home/elake/Code/mailer.py ./  <-- that command would work though
<jam> etank: you might try looking at "My Documents\.bzr.log" to see if there is any more info there
<etank> SocketConnectionError: Unable to connect to SSH host 157.184.82.74; EOF during negotiation
<jam> jelmer: Why would "dch" keep trying to add a new record with your name instead of mine?
<jelmer> I'm listed as maintainer
<jelmer> debia/control
<jam> jelmer: yeah, I was accidentally using "-m" thinking I needed it as the update message
<jam> rather than realizing it set the "use the ID of a maintainer" flag
<jelmer> I've done that a couple of times as well
<jelmer> bzr commit ruined dch for me
<jam> etank: does it say anything about failing to import paramiko, etc?
<etank> jam: no but here is the output of the last two tests http://dpaste.com/96468/
<etank> maybe the .ssh/know_hosts part is the issue
<jam> etank: can you try using "sftp://" just to see if that gives different results?
<jam> (I don't expect it to, but we can try it)
<etank> jam: same thing
 * etank wonders where putty puts is known_host info
<jam> etank: with bzr-1.9 we shouldn't actually be using putty
<jam> we should be using paramiko to connect
<jam> as plink doesn't allow us to ask the user for a username and/or password
<jam> (so it works only if you are using ssh keys)
<etank> i was going to look at puttys file and place it where bzr wants to find it
<jam> I don't *think* it is a known_hosts issue
<jam> something weird is going on, though if both "BZR_SSH=paramiko" and "plink" are failing
<etank> bzr: ERROR: Unable to connect to SSH host elake-ibex; (10061, 'Connection refused')
<jam> what shell are you using?
<etank> windows command shell
<jam> and you don't have something like a non-standard ssh port, right?
<etank> cmd.exe
<etank> nope
<etank> 22. default install on the ubuntu side
<etank> back in a few
<jam> etank: ... for the .bzr.log you gave, I can imagine that if BZR_SSH is plink it will fail because we cannot ask for a password
<jam> for the "set BZR_SSH=paramiko" I don't see why it would be failing
<jam> for the other one, it is definitely *using* paramiko
<jam> as the exception traceback is coming from that code
<lifeless> jam: so
<lifeless> jam: I don't mind if you want to write a create_by_apply_delta for Inventory, but I don't think its going to be any faster or anything; and its another method to support
<lifeless> create_by_apply_delta on CHKInventory was/is semi private
<jam> I agree that it isn't going to be faster
<jam> it is more about consistent apis between different Inventory implementations
<jam> considering that "apply_delta" is public
<jam> and certainly a more dangerous function than "create_by_apply_delta"
<lifeless> apply_delta isn't on CHKInventory at all
<LarstiQ> jelmer: how about a bzr-dch plugin? ;)
<jam> lifeless: I seem to be getting build failures for bzr-svn because it can't find the bzr packages
<jam> and the bzr-svn ones require >1.10
<jam> do you know if this is just transient?
<jam> (I also happened to upload bzr-svn *before* I uploaded bzr, as I was trying to make sure I got all the packages built before I updated the ppa)
<jam> (but I already did one "retry" and it still is unhappy)
<lifeless> jam <-> jelmer
<lifeless> jam: You'll need to up load bzr, upload bzrtools, upload bzr-svn, then update the ppa
<lifeless> this requires a separate ppa and package copying
<jelmer> jam, you may get away with a build-dependency on 1.9
<jam> So the specific error seems to be this line:
<jam> After installing, the following source dependencies are still unsatisfied: bzr(inst 1.9-1~bazaar1~hardy1 ! >= wanted 1.10~)
<jam> And I'm concerned about whether the 1.10-1~bazaar1~hardy1
<jam> is evaluating versus 1.10~ correctly
<jam> well, *will* evaluate
<jam> obviously it is only finding the old 1.9-1 so far
<jam> hmm.. bzrtools built fine
<jam> ah, but Jelmer didn't update the control file for bzrtools
<jam> it still says 1.9~
<jelmer> jam, I didn't update the build dependency
<LarstiQ> 1.9~ for what, the version of bzrtools, or the dependency on bzr?
<jelmer> jam, that's still at >=1.9~, but shouldn't matter
<jelmer> jam, the runtime dependency I did update
<jam> LarstiQ: the bzrtools 1.10 package only depends on bzr 1.9
<jam> for some reason, the bzr-svn ppa is failing to build the 0.4.16 package because it depends on bzr >= 1.10~
<jam> I don't know if it was because my upload ordering was reverseed
<jam> or if it is just having a problem finding the packages now that they are present in the ppa
<jam> I would guess that my upload order confused the initial attempt
<jelmer> jam, what makes you say bzrtools depends on bzr 1.9..?
<rocky> jelmer: hey, is there a bzr-svn release for bzr 1.10 yet?
<jam> but I would have thought it fixed when I did "retry"
<jam> rocky: bzr-svn 0.4.16
<jam> jelmer: Build-Depends-Indep: bzr (>= 1.9~), rsync
<jam> though I also see:
<rocky> awesome, thanks
<jam> After installing, the following source dependencies are still unsatisfied: bzr(inst 1.9-1~bazaar1~hardy1 ! >= wanted 1.10~)
<jam> sorry
<jelmer> jam, That's just saying building the package should work with 1.9 and 1.10
<jam> Depends: ${python:Depends}, bzr (>= 1.10~), bzr (<< 1.11~), patch
<jelmer> jam, seems fine to me
<jam> Well, bzr-svn does have "bzr >= 1.10~" in its "Build-Depends"
<jam> which bzrtools doesn't have
<LarstiQ> I don't think bzrtools needs it?
<jam> to build? probably not
<jam> I would have assumed bzr-svn wouldn't need it to *build* either
<jam> The discussion may not matter in a bit
<jam> as it seems the ppa *might* be figuring out that it really does have access to bzr >= 1.10 now
<jam> at least, the link to the "lpia" build went away
<jam> which I'm hoping means it successfully built
<jam> In the future, I just need to make sure to upload bzr before any plugins
<jam> It certainly has to be able to grab packages from the ppa itself, otherwise it wouldn't have been able to install bzr-1.9 either
<jam> since that only exists in a ppa, IIRC
<jam> I didn't think 1.9 has made it into any release
<BratscherBen> is there a possibility to use Hooks as in subversion? As far as I see, hooks in bzr are registered in ~/.bazaar/plugins which affects all usage of bzr. In my concrete example I want to run a bzr export in a remote repository after push, but not in all my repositorys.
<etank> jam: yeah i did the set for paramiko and it is still a no go
<LarstiQ> BratscherBen: hooks can check which branch they're operating on, and have programmatice access to it's branch.conf
<LarstiQ> (and to ~/.bazaar/ config as well if needed)
<BratscherBen> yes, but I want that this command is run not only when I check something in, but also when others do
<BratscherBen> so is the post_push hook called on the remote server, when somebody pushes or only on the machine that pushes?
<BratscherBen> the docu says âruns on clientâ
<jam> BratscherBen: there is a hook that is run on the server side (post-branch-tip-changed, IIRC)
<BratscherBen> yes, just found it
<jam> Apparently it may be getting a semi-bogus URL at the moment (because when run on the server things are run in a chroot)
<etank> im not getting the bzr on windows thing :/
<BratscherBen> so I assume I have to install a plugin in /usr/share/pyshared/bzrlib/plugins for which I also need root access and have to check there, from which repository I am called
<lifeless> BratscherBen: you should set the hook on the server, it will run for all branches on the server; you can then filter that down by checking its a branch you want to take the action on
<jam> etank: unfortunately, it "just works" here... which makes it all the more difficult
<jam> also, when we use an all-in-one installer we lose some of the ability to debug
<jam> if it was installed into a regular python install
<BratscherBen> sounds like a solution, but not a nice one
<etank> i can do a regular python install
<jam> then you can drop down into a python shell, and try various things
<etank> jam: will it work with py2.6?
<etank> the site said 2.4 and 2.5 so that is why i went with the all in one installer
<jam> vila has been working on 2.6 compatibility. I believe it currently works
<jam> They did some odd backwards-incompatible changes in 2.6
<LarstiQ> but there might not be a 2.6 installer
<BratscherBen> the solution in other vcs are nicer, why bzr has not such an option to just run a shellscript in .bzr/hooks/post-tip-change ...
<jam> LarstiQ: I would guarantee there isn't :)
<jam> BratscherBen: in a distributed setup, you don't always have control over ".bzr/hooks/*" and that tends to lead to running $RANDOM other person's code
<jam> which is a good way to have a security problem
<jam> That said, there is a "shell-scripts" plugin that adds support for shell hooks
<BratscherBen> the person who owns the repository has control over this
<jam> I don't remember the exact name
<lifeless> BratscherBen: there is a plugin that can do what you want; but you can as a user in your own account setup plugins too
<BratscherBen> I managed it now with this shell-scripts plugin. Problem here is a bit, that the post_change_branch_tip_hook is executed while a still is in progress and so the lock is not free. I made a workaround like {sleep 3; bzr export foo.zip} around to avoid this, but it of course is not really nice
<BratscherBen> but it works, thanks for the answersâ¦
<luigi> hi
<luigi> is python 2.6 supported?
<LarstiQ> luigi: it should be
<luigi> ok
<NfNitLoop> 3.0?  ;p
<luigi> yeah
<NfNitLoop> ... really?
<luigi> dont know
<LarstiQ> NfNitLoop: no
<NfNitLoop> I didn't figure so. :)
#bzr 2008-12-06
<lifeless> beuno: ping - bzr session now
<lifeless> beuno: in 'bragi'
<rocky> hey, what versions of python does bzr 1.10 "officially" support?
<beuno> rocky, 2.4 and 2.5
<rocky> is 1.11 aiming for 2.6 support? (officially)
<beuno> rocky, I don't think we'll be officially supporting 2.6 very soon. Supporting 3 versions of python sounds a bit hell-ish
<rocky> it does, but i would hope for a shift to 2.5/2.6 up from 2.4/2.5
<lifeless> 2.6 should be fine with 1.10
<lifeless> rocky: 2.4 going is more a factor of distro release schedules and company migration needs than anything else
<rocky> lifeless: i asked about "official" because when i tried 1.9 on py2.6 (which "should" work) i found several plugins i used  didn't work with 2.6
<rocky> anyways, bzr rocks, keep up the good work ;)
<jelmer> well, plugins are different from bzr core of course :-)
<jelmer> apparently bzr-svn requires >= python 2.5 these days :-/
<rocky> part of why i'm asking is because i'm considering integrating bzr into my cluemapper suite (trac integration) and i require >= py2.5 and would like to update it to 2.6 at some point
<jelmer> I don't think anybody is opposed to 2.6 support, but it may be useful to file bugs if you find things don't work with 2.6 yet
<lifeless> rocky: plugins - file bugs on them
<rocky> right
<lifeless> rocky: I mean, I don't *have* python2.6 available on my machine, I can't really fix bugs:)
<rocky> everyone can have py2.6 available on their machine :)
<rocky> unless you're running msdos or something ;)
<lifeless> $ apt-cache search python2.6
<rocky> wget Python-2.6.1.tar.bz2 && tar jxf Python-2.6.1.tar.bz2 && cd Python-2.6.1 && ./configure --prefix=$HOME/python2.6 && make && make install
<Peng_> Oogh.
<rocky> at least that's what i just did on my 3 ubuntu desktops :)
<lifeless> rocky: yeah, 'no'.
<lifeless> :)
<rocky> lifeless: i guess my line was a tad bit longer than yours ;)
<lifeless> rocky: :)
<Lutin42> Hi! I have a bzr repository. Today, I copied the whole folder onto a USB key and from an other computer, changed some files in it. I did not do any bzr operations. Tonight, I copied the folder back to the first computer in a different folder. Now, bzr status tells me that all the file  have been modified (which is not true).
<Lutin42> Any reason this happens?
<Lutin42> Any way to fix it?
<Rolly> have you tried bzr revert?
<beuno> Lutin42, well, the files probably changed properties like owner and such
<beuno> bzr revert will throw away all those changes
<beuno> so make sure that you don't have anything you don't want to loose
<Lutin42> hmmm... I can do this. But I'd like to figure out what happened
<Lutin42> I will look at the property
<Lutin42> Is time relevant?
<jfroy|work> jelmer: are you aware of a problem with bzr 1.10 and bzr-svn 0.4.16 in create_auth_baton?
<jelmer> jfroy|work, no
<jfroy|work> I'm getting a TypeError exception from that method (auth.py:181)
<jfroy|work> "Auth providers should be list"
<jfroy|work> Any ideas?
<jelmer> jfroy|work, no, sorry. Is providers actually a list?
<jfroy|work> totally should be
<Lutin42> ok; the permissions have been messed up
<lifeless> Lutin42: time isn't relevant
<lifeless> Lutin42: I would guess the execute bit was changed or something
<lifeless> Lutin42: what does 'bzr diff' show?
<lifeless> Lutin42: and can you pastebin the output of status, for justa few files, so we can see it
<Lutin42> I fixed the permission of one of the file and it does not show any more in the status
<Lutin42> so all is good :)
<jfroy|work> jelmer: nm must have been a bad build
<jfroy|work> actually that's exactly what happened
<jfroy|work> your Makefile is not robust enough
<jelmer> patches welcome :-)
<jelmer> the Makefile is just a convenience wrapper around setup.py though, not intended as the primary build mechanism
<jfroy|work> correct
<jfroy|work> the problem is that it uses which to find Python and bzr
<jfroy|work> But on the system I was using, the default python is not the same as the python used by bzr.
<jfroy|work> All kinds of bad things ensued.
<jfroy|work> Ideally it should parse the path returned by bzr --version
<jfroy|work> (which is what my patch will do)
<Peng_> beuno: fwiw, I'm not sure the Loggerhead changes improve memory usage for me much.
<Peng_> beuno: It *might* be a bit better. It's at 120 MB right now, but it usually jumps to 150 instead.
<beuno> Peng_, 120 vs 150?
<beuno> the major win should be in total usage
<beuno> it shouldn't keep on scaling
<Peng_> What do you mean?
<beuno> it leaks memory for us
<beuno> until it crashes
<beuno> on large trees
<beuno> brb
<Peng_> eep
<arekm> hello, does bzr have commands that works like git log -p (producing both, changelogs and diffs at the same time - ex http://pld.pastebin.com/f1c76c250) ?
<Peng_> beuno: Since the latest Loggerhead trunk stuff, mem usage has actually gotten worse for me. But the workload is a bit different than usual, so it might be expected.
 * Peng_ goes back to being away
<pygi> mr
<Peng_> s/expected/because of that/
 * Peng_ goes back to being away again. :P
<arekm> hmm, looks like there is no such feature in bzr :-( most commonly used command by me for git repos
<arekm> on the other hand http://wiki.frugalware.org/Git_setup says "not possible without plugins"  so maybe there is a plugin for that already
<arekm> so is there a plugin that does this? https://lists.ubuntu.com/archives/bazaar/2008q1/038202.html
<arekm> matkor: https://bugs.launchpad.net/bzr/+bug/202331 and https://bugs.launchpad.net/bugs/227335
<ubottu> Launchpad bug 202331 in bzr "log should be able to show diffs as well" [Medium,Confirmed]
<matkor> arekm: he he, you are not the only one [to cite GnR ;) ]
<beuno> Peng_, that's not very good news  :(
<beuno> what version of bzr are you running?
<Peng_> beuno: bzr.dev.
<Peng_> Hmm, Loggerhead just recently started loading plugins. I wonder if that could be involved?
<Peng_> I have no idea /how/, but..
<beuno> Peng_, ah, right. That patch probably shouldn't of gotten in
<beuno> it does load plugins
<beuno> actually, I'm not sure if that's such a bad thing...
<bpierre> hi
<Flimm> What's the difference between bzr get and bzr branch?
<bpierre> Flimm: get is just an alias for branch
<Flimm> OK, thanks
<derekS> hello. i messed up my branch and committed a huge file. i want to remove any history of this commit
<derekS> because now my .bzr is way too big
<derekS> how do i do this?
<bpierre> you could uncommit
<bpierre> and then clone the branch
<bpierre> the new one will not contain the uncommited revision
<bpierre> it's more complicated if you're using a shared repo
<derekS> good plan
<derekS> nope not
<Peng_> Even if you are using a shared repo, it's not that complicated.
<bpierre> how would you do it? reconfigure --standalone on each branch using it, recreate the shared repo, and reconfigure --shared?
<bpierre> or is there a command to completly wipe out the revision?
<Peng_> bpierre: Create a new repo and a branch inside it, "bzr heads" in the original repo, pull each one into the new repo, then swap the repos out.
<Peng_> ("bzr heads" comes from bzrtools.)
<derekS> Peng_: you hang out here too :)
<bpierre> ok
<Peng_> derekS: Hi. :)
<derekS> i am considering putting my bzr repo in something like Dropbox. its only me who uses it, any comments for or against it?
<derekS> i am thinking it might be easier then pushing/pulling on 2 computers
<pygi> jelmer, lifeless: you rock ;)
<Peng_> derekS: Pushing/pulling/merging is not that hard.
<bpierre> mmm
<bpierre> Peng_: I just tried heads on one of my repo, and I'm not seeing the head of each branch using it
<derekS> Peng_: i know ;)
<lifeless> pygi: thanks? :)
<pygi> lifeless, why the question mark? :p
<derekS> hmm, i uncommitted, and did a clone, the new folder is bigger than the old :)
<bpierre> :P
<bpierre> I tested it and it worked for me
<pygi> lifeless, you can probably expect our TOC next week, so you can do a quick check so we could create final revision of it :)
<bpierre> derekS: same repository formats?
<derekS> bpierre: yeah, just realize i might have had to do 2 uncommits
<lifeless> pygi: wasn't sure what you where thanking me for :)
<pygi> lifeless, ah, now you know then :p
<lifeless> jml: ping me when you are up please
<beuno> Peng_, so, memory usage is still up for you?
<derekS> so when you push a directory, it just copies the .bzr?
<luks> if you push to a remote server, yes
<derekS> so what kind of compression is used? my .bzr folder is significantly smaller than the contents of the repo
<luks> it stores only the changes (not the full history), and the data are then gzipped
<luks> oh wait
<luks> by 'repo' you mean actual bzr repository, or your working tree
<derekS> bzr repo
<derekS> because the working tree has actual data
<derekS> the remote push doesn't
<luks> well, it might be using a shared repository
<luks> what's inside the .bzr folder on the server?
<derekS> just the .bzr
<luks> I mean inside it
<derekS> README  branch  branch-format  branch-lock  repository
<luks> ah, then it contains the repository as well
<derekS> means all the data gzipped?
<luks> delta-compressed and gzipped
<derekS> thanks :)
<CyberSnooP> Hi. I'm having trouble with the SVN plugin on bzr-1.9 on windows. I've ran the setup, but things like  "bzr version" now say:
<CyberSnooP> Unable to load bzr-svn extensions - did you build it?
<CyberSnooP> cannot import name client
<CyberSnooP> Does anyone know how to fix this?
<jelmer> CyberSnooP, how did you run the setup?
<CyberSnooP> Downloaded bzr-setup-1.9.exe and kept the defaults
<jelmer> that should include bzr-svn I think
<CyberSnooP> Well, the plugin is there and bzr tries to load it indeed
<CyberSnooP> but somehow it fails to load with the above error
<CyberSnooP> The only clue seems to be: "cannot import name client". So probably I'm missing a dependancy, but I couldn't find which one, or how to fix it
<jelmer> CyberSnooP, that file is part of bzr-svn
<jelmer> CyberSnooP, it is built when you run setup.py
<jelmer> CyberSnooP, how did you install bzr-svn?
<jelmer> CyberSnooP, also, I think there was an updated version of the bzr 1.9 setup that fixed some issues, it may fix stuff in bzr-svn as well
<CyberSnooP> I didn't install bzr-svn manually, but I've only used the bzr-setup-1.9 which should have bzr-svn bundled
<jelmer> CyberSnooP, in that case, it sounds to me like a broken setup
<Jc2k> jelmer: any chance of that pack code :)? sorry to bug but im blocked on it atm.
#bzr 2008-12-07
<lifeless> Jc2k: what pack code?
<jml> lifeless: ping
<pygi> jml is alive! :)
<pygi> amazing :)
<jml> yes.
 * pygi goes rolling :)
<pygi> jml, you got my mails, right? :)
<jml> I got at least one :)
<pygi> jml, which one? :p
<jml> nah, I got em both
<pygi> good good :)
<pygi> 2:40AM, you Aussies ...
<pygi> xd
<lifeless> jml: yo
<jml> lifeless: hi
<lifeless> jml: join /#pyunit-friends
<jml> pygi: you left?
<jml> Mario__: yay internet.
<pygi> jml, please gimme ip again in pm :)
<lifeless> jelmer: btw, SvnBranch.last_revision() is very slow AFAICT
<robin_dewd> guys what's the latest workaround for working with branches that have symlinks on windows? is it cygwin all the way?
<Rolly> robin_dewd: I think so. Cygwin and the win32 symlinks plugin
<robin_dewd> yep. the win32 symlinks plugin just worked for me and I was able to branch
<Rolly> cool
<robin_dewd> it was just that it was a little outdated in its last check in. thx
<Peng_> Oogh, LH's memory usage is really being problematic.
<Peng_> since I'm on a small vps.
<Jc2k> lifeless: git pack reader/writer.
<Jc2k> for bzr-git
<Oli``> Is there a command to list all the currently ignored files?
<luks> bzr ignored
<luks> or bzr ls --ignored if you don't want the matching patterns
<LeoNerd> When bzr execs "ssh", is there a nice way that ssh can determine it's doing that?
<LeoNerd> My 'ssh' is really a shell script, that detects if it's running via screen, and if so, starts the command in a new screen window
<LeoNerd> This upsets bzr, because it means the 'ssh' command itself exits very quickly
<Peng_> LeoNerd: Well, it runs "ssh bzr serve --inet --directory=/ --allow-writes", so you could check if those are the arguments?
<Dvyjones> What software should I use if I want to host bazaar repositories?
<Peng_> Dvyjones: What kinda hosting? At minimum, all you need is OpenSSH.
<Peng_> (or another sftp server I guess)
<Dvyjones> Peng_: I want to be able to set up repositories that should be accessible and editable by different users...
 * Dvyjones tried bazitis, but it wouldn't work..
<Peng_> Use Launchpad? :P
<Dvyjones> Well, I have git hosting, and someone asked if I could do bzr hosting too...
<Peng_> Sorry, but I don't have experience with bzr hosting (aside from a simple single-user setup)
<Oli``> luks: thanks =)
<Oli``> If I add something and then write add ignore pattern that matches it, does it automatically stop being versioned?
<luks> no
<luks> run `bzr rm --keep FILE` to unversion it, if that's what you want
<Oli``> Exactly what I was about to ask =) thank you!
<haaa> hi all... i have a problem with bazaar and ftp. everytime when i push i get "Cannot lock LockDir"
<haaa> the problem is that bazaar executes "site chmod 0700". my ftpd only unterstands "site chmod 700"
<haaa> is there any possibility to fix it?
<jelmer> haaa, please file a bug, mentioning what you did here as well as the name of your ftp server
<jelmer> haaa, We should be able to add a workaround for it
<Alexplay> http://mivenganza.com/index.php?c=viral&m=index&id=563c74d45bc246f4099d8dbbcf400b39
<lifeless> jelmer: hi
<jelmer> lifeless: 'morning
<lifeless> does buildfarm have/need subunit support?
<lifeless> or does it jus t get processed logs?
<jelmer> lifeless, our buildfarm currently uses its own custom format
<jelmer> for historical reasons
<jelmer> I would like to switch it to subunit at some point (saves duplicate code), but haven't gotten round to it yet
<lifeless> jelmer: cool; doing some subunit hacking at the moment
<jelmer> ah, nice
<lifeless> parrot are looking for a replacement for tap
<jelmer> The Samba client library is somewhat standalone now, btw
<jelmer> I hope to make it a separate thing at some point ("libtorture")
<jelmer> parrot is the Haskell Perl 6 implementation, is it?
<lifeless> I've put up a couple of brnaches, for tags and skip/xfail
<jelmer> lifeless, nice
<lifeless> parrot is the vm project
<jelmer> lifeless, we should really package this up and include some simple scripts that e.g. take subunit text and generate HTML reports
<lifeless> jelmer: right. I'm really regretting using scons :(.
 * jelmer nods
<lifeless> jelmer: anyhow, I'm all up for packaging it; if the build system gets in the way, then switching would be fine (but not setup.py :P - because it builds normal C libs etc)
<jelmer> lifeless, cool
<jelmer> lifeless, I already filed an ITP a while ago, and did some work on packaging but got stuck because of scons back then
<lifeless> jelmer: yeah, I'm so not attached to scons
<jelmer> lifeless, where switching means switching to GNU make, I assume?
<lifeless> jelmer: GNU make would be fine; autoconf + automake + handoff to setup.py for the python code is fine too, or various other alternatives
<lifeless> the requirements are: something that works
 * jelmer isn't sure whether he can meet those somewhat outrageous requirements
 * lifeless laughs
<lifeless> heck, even setup.py for the lot would be better; but it really doesn't seem like a good fit for building libraries [non python extension module ones anyhow]
<Jc2k> jelmer: the initial test run with bzr-svn 0.5 has finished running.
<Jc2k> the main thing i noticed was the key error we saw in bigboard and evolution. i'll try and get you something useful when i feel alive again
<Kobaz> bzr: ERROR: No repository present: "bzr+https://user@bzr.local/bzr/usrLocalLibrary/trunk/"
<Kobaz> that was working a few days ago
<Kobaz> i run bzr info on the server side, and it looks okay
<Kobaz> ph wait
<Kobaz> i have 1.5 on the client and 1.9 on the server
<Kobaz> i broke it
<Kobaz> https://bugs.launchpad.net/bzr/+bug/306029
<ubottu> Launchpad bug 306029 in bzr "bzr status broken" [Undecided,New]
<Kobaz> yeap
<Kobaz> can i modify a previous commit message
<reinerp> i am having trouble connecting to an svn-repo using bzr+svn as an anonymous user. can someone help me?
<jelmer> Jc2k, ah, thanks
<jelmer> Jc2k, I hope to have a fix for that this weekend
<jelmer> Jc2k, haven't been able to upload my bzr-git changes yet :-/
<jelmer> Kobaz, You can uncommit the revisions with the commit message you would like to change and commit again
<jelmer> reinerp, hi
<jelmer> reinerp, what's the problem you're seeing?
<reinerp> well, I get the error message "ERROR: bzrlib.plugins.svn.core.SubversionException: ("PROPFIND request failed on '/svn/mhaecker/open-source/nsNet'", 170001)"
<reinerp> trying to branch, I use bzr branch svn+https://anonymous@ipx11390.ipxserver.de/svn/mhaecker/open-source/nsNet
<reinerp> after that, I am asked twice for a password: <https://ipx11390.ipxserver.de:443> Subversion repository anonymous password:
<jelmer> what version of bzr-svn?
<reinerp> and then: <https://ipx11390.ipxserver.de:443> Subversion repository None password:
<reinerp> so I am not sure if there is a problem with the server or if the anonymous user is not correctly transmitted
<jelmer> reinerp, tbh, that repository doesn't allow me to log in with svn itself either
<jelmer> so it seems right that bzr-svn asks for a password
<Jc2k> jelmer: kind of blocked on the pack right now :-\
<jelmer> Jc2k, sorry :-/
<reinerp> yes, i asked my friend if he enabled anonymous access, but I think he has to check that again. but thank you very much for your help!
<lifeless> Jc2k: you can't unpack ?
<jelmer> lifeless, git pack
<jelmer> this is about the bzr-git pack code
<lifeless> jelmer: yes,  I know :)
<Jc2k> lifeless: unpacking off the wire :-\
<Jc2k> i suppose i could pipe in to git-unpack-objects and read the objects out of a dummy repo :)
<lifeless> jelmer: yes,  I know :)
<lifeless> sorry, network glitch
<Kobaz> $ bzr push
<Kobaz> HTTPS user@bzr.local, Realm: 'Bazaar Repository' password:
<Kobaz> bzr: ERROR: Server sent an unexpected error: ('error', "'module' object has no attribute '_has_key_from_parent_map'")
<Peng_> Kobaz: What version of bzr on the client and server?
<Kobaz> 1.10
<Kobaz> if i do a bzr push again, i don't get the error
<Kobaz> it's like 1 out of three pushes, i'll get tat error
<Kobaz> s/tat/that
<Peng_> I've got no idea then. Sorry. :P
<pygi> Peng_, whats the problem'
<pygi> ?
<Kobaz> the one i pasted
<Peng_> pygi: Here's a transcript from right before you joined: http://paste.pocoo.org/show/AkdAJiOEP0D5TK2FDQ7k/
 * Peng_ thinks pastebins are fun
<Kobaz> oh right, heh, he joined late
<pygi> Kobaz, do you use stacked repo?
<Kobaz> i have a shared repo, and then a branch inside it
<pygi> Kobaz, bzr info -v pls
<Kobaz> http://www.pastebin.ca/1279091
<pygi> Kobaz, try upgrading the branch
<pygi> and let me know what happens while I go hunt for some food :p
<Kobaz> upgrading?
<Kobaz> form what to what?
<pygi> Kobaz, to branch format 7
<pygi> jml, sleeping? :)
<spiv> Good morning.
<pygi> hi spiv .)
<pygi> :)
<jml> pygi: no, I'm just on a call.
<pygi> jml, ;)
<Kobaz> pygi: oh
<Kobaz> pygi: how would i do that
<pygi> Kobaz, bzr upgrade :)
<Kobaz> ah
<Kobaz> sounds easy enough
<pygi> Kobaz, let me know if that helps
<Kobaz> bzr: ERROR: Not a branch: "/usr/local/library/perl/".
<pygi> well, then obviously that's not a branch? xD
<Kobaz> it is
<Kobaz> hmm
<Kobaz> well /usr/local/library is a branch
<Kobaz> okay
<Kobaz> cd..
<Kobaz> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<LarstiQ> Kobaz: this is about '_has_key_from_parent_map', right?
<pygi> LarstiQ, it is, yes
<LarstiQ> then upgrading your branch format will not do anything.
<pygi> so wrong assumption
<LarstiQ> Kobaz: does ~/.bzr.log contain an entire backtrace for that error? I'd like to know which python module it's having problems with.
<Kobaz> LarstiQ: yeah
<Kobaz> LarstiQ: lemme see
<Kobaz> http://pastebin.ca/1279128
<Kobaz> http://pastebin.ca/1279130
<LarstiQ> meh
<LarstiQ> Kobaz: unfortunately it doesn't contain the server side backtrace.
<LarstiQ> Kobaz: how about the ~/.bzr.log on the remote side?
<Kobaz> k
<Kobaz> what about that pycurl module?
<LarstiQ> not related, and harmless
<Kobaz> k
<Kobaz> where would it be
<Kobaz> i'm using the mod_python via apache method
<Kobaz> for the server
<Kobaz> it's not in the web users home dir.. although it's not writable by the web user
<LarstiQ> oh wow :)
<LarstiQ> Kobaz: I've never tried that, with bzr+ssh I'd say in the homedir of the user you're sshing in as.
<LarstiQ> and I'd indeed assume the user the mod_python process runs as
<Kobaz> ack
<Kobaz> i broke bzr again
<Kobaz> http://pastebin.ca/1279139
<Kobaz> oh
<Kobaz> i installed pycurl
<Kobaz> and now it's able to download the cert to verify it
<Kobaz> does bzr have support for local cert verification?
<LarstiQ> what do you mean with local?
<Kobaz> like, local to the user
<Kobaz> rather than using the system ca certs
<LarstiQ> Kobaz: don't think so.
<LarstiQ> unless pycurl does that by itself
<Kobaz> i have a self signed cert on the server
<Kobaz> looks like it's this bug
<Kobaz> https://bugs.launchpad.net/bzr/+bug/82086
<ubottu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]
<Kobaz> removing pycurl fixes it
<Kobaz> heh
<LarstiQ> Kobaz: right.
<LarstiQ> Kobaz: I'm falling asleep I'm afraid. Anyway, it looks like for some reason the python process has a different module imported than it expects.
<LarstiQ> Kobaz: figuring out what it is expecting and what it is getting would be the first step to solving this.
<Kobaz> mmm
#bzr 2009-11-30
<mwhudson> are all bzr+http accesses at the http level POSTs to $branch_url/.bzr/smart ?
<spiv> mwhudson: some might be to higher directories I suppose, if bzr tries to look for shared repos and the like
<mwhudson> spiv: for read-only launchpad i guess we can mostly ignore that?
<spiv> mwhudson: IIRC bzr will try to prefer the first .bzr/smart that seems to work, though.
<spiv> mwhudson: I think so.
<mwhudson> spiv: cool
<Peng> For me it accesses both repo/branch/.bzr/smart and repo/.bzr/smart.
<Peng> That's if I use an "http" URL. If I use "bzr+http", it only uses repo/branch/.bzr/smart.
<lifeless> mwhudson: what is the relevance of read-only lp to this?
<mwhudson> lifeless: to what?
<lifeless> bzr+http accesses
<Peng> Well it'd be nice if LP supported it, no? :D
<Peng> Why not straight bzr://?
<lifeless> Peng: code.launchpad.net ?
<mwhudson> lifeless: someone requested bzr+http specifically on the bazaar list
<lifeless> Peng: or bazaar.launchpad.net ?
<mwhudson> lifeless: just thinking about how hard it would be
<lifeless> mwhudson: forward .smart to loggerhead?
<lifeless> as loggerhead already does bzr+http doesn't it ?
<mwhudson> lifeless: yeah maybe
<Peng> Cuz what LP needs is Loggerhead using even more CPU and RAM!
<mwhudson> well the one we have on launchpad doesn't do bzr+http cause of the way it's set up wsgi-wise
<mwhudson> but that's strictly a detail
<mwhudson> Peng: possibly not the same loggerhead as the code browsing one, i guess
<lifeless> mwhudson: if we're adding loggerhead instance and haproxying between them, I'd make them all the same.
<lifeless> mwhudson: and just add lots.
<mwhudson> lifeless: yeah
<Peng> Kinda silly to run Loggerhead *just* for .bzr/smart.
<mwhudson> Peng: there's not much point following me on both twitter and identi.ca btw
<Peng> mwhudson: Shrug. I usually do that anyway. Just in case one of them explodes or something, I guess.
<mwhudson> fair enough
<lifeless> Peng: but it wouldn't be just for it.
<lifeless> Peng: we'd get more cpus working on code browsing at the same time.
<Peng> Yeah, that sounds good.
<Peng> Err, did that sound sarcastic?
<lifeless> no.
<lifeless> did you meant it to be? If so, FAIL.
<Peng> Heh. I did not.
<lifeless> http://robey.lag.net/2009/11/29/more-git.html is interesting
<lifeless> just that the values and behaviours we recommend are still valuable to robey ;)
<lifeless> Peng: as for why not straight bzr://, we could do that. But we have http open in the firewall, *and* loadbalancing software for it, already.
<Peng> Ah.
<Peng> Plus it's probably better for users behind firewalls, too. Though not those behind weird proxies.
<lifeless> POST should be fine for them
<lifeless> its non-smart http that really exercises the bug db of proxy vendors
<Peng> Oh, good point.
<poolie> afc, mwhudson, lifeless: so what i meant when i said anonymous ssh may be easiest is just that it may be easiest, not necessarily fastest
<poolie> lifeless: want to send any mail about patch piloting?
<lifeless> poolie: yes
<lifeless> poolie: but its not work for me, so will happen later
<lifeless> poolie: I have to do a sweep of the things I'm piloting anyhow
<poolie> np
<lifeless> poolie:  bug 489993 - please consider landing that as-is; I agree we can overhaul the area, but fixing the logic inversion won't add debt or decrease test coverage.
<ubottu> Launchpad bug 489993 in bzr "bzr 2.1.0b3 reports interpreter path on Mac OS X with a .dll extension" [Low,Confirmed] https://launchpad.net/bugs/489993
<poolie> yes
<poolie> i didn't realize on the first reading that there was a logic inversion
<poolie> thus the confugison
<lifeless> cool
<poolie> lifeless, i don't understand why you think handing over in-progress patches will cause rework
<poolie> have you seen this happen?
<poolie> i have seen other people want different things from a patch
<poolie> but, that's life
<poolie> we can resolve it
<dOxxx> hey poolie, just popping so we can sort out this 489993 thing quickly
<poolie> bug 489993
<ubottu> Launchpad bug 489993 in bzr "bzr 2.1.0b3 reports interpreter path on Mac OS X with a .dll extension" [Low,Confirmed] https://launchpad.net/bugs/489993
<poolie> yep
<poolie> i agree with your patch and i'll merge it
<poolie> how's that?
<dOxxx> ok :)
<dOxxx> I was just a bit confused
<dOxxx> there was some back and forth with lifeless about whether it should be changed to just remove that whole section
<dOxxx> but if you're cool with it as is, that's fine by me. I pushed one more little change to add a comment referencing the doc url on the py2exe env like you suggested
<poolie> i think that would be better but it's good to merge as it is
<dOxxx> alrighty, minimal interference patch it is :)
<dOxxx> I shall bid you good night then. Seeya later.
<lifeless> poolie: because its going to cause new conversations
<poolie> if there's been conversation about the patch not captured in the review?
<lifeless> no, because the new pilot is likely not to have participated in the review so far
<poolie> and... they may have questions that they'll ask now, but that would otherwise have gone unasked?
<lifeless> I see this happen quite a lot - with experienced folk it doesn't matter, as you say we can address it.
<lifeless> but if we really want to be helping these casual contributions get through, deliberately provoking that seems risky to me.
<poolie> sorry what is "this" and "that"?
<poolie> what i mean is
<poolie> if changing from one reviewer to another requires the patch to be reworked
<poolie> that seems like a pretty serious problem
<poolie> like people are enforcing very different standards or something
<lifeless> uhm
<lifeless> I'm clearly not expressing the concern well.
<poolie> iiuc the concern is
<lifeless> I'm talking about things like scope expansion, 'taste' and so forth, not the actual standards or functional defects.
<poolie> you've replied to a review last week saying "please do X and I'll merge it"
<poolie> and then I come along this week and say "oh please do Y too"
<poolie> ..?
<lifeless> as a for instance, yes.
<lifeless> if there is a pilot handoff I'm concerned that this will happen a lot more.
<poolie> ok
<poolie> so if it was you all the way through
<poolie> you might sometimes do that, actually
<poolie> saying "I've just realized we should do Y too"
<poolie> but you'd probably at least notice you were doing it?
<lifeless> right. Probably with 'sorry' in there too.
<lifeless> :)
<poolie> right:)
<poolie> that seems like something we could in princple do across reviewers?
<lifeless> yes, I'm not claiming exclusive ownership of these issues for patch pilot handoffs.
<poolie> say that by default if one reviewer sets requirements for scope or cleanliness, we won't come back and raise them later?
<lifeless> just a raised frequency.
<lifeless> why do you want the handoff?
<poolie> i want the pp process to be:
<lifeless> I mean, you say the software doesn't model it, but I don't see why the software needs to, it already shows a submission date which is all you need.
<poolie> while not active_reviews.empty(): active_reviews().pop().resolve()
<lifeless> If there was a 'correct' actions_I_should_do list, I would be totally +1000 on that process.
<lifeless> but we seem to be pretty far off that.
<lifeless> I'd rather focus on giving a fantastic experience to new contributors that the pilot efficiency right now - particularly as the pilot efficiency is already quite high IME.
<lifeless> s/that/than/
<poolie> so
<poolie> i think having one person deal with them all the way through is a better experience than changing hands
<poolie> however, i think having *somebody* follow up monday is better than having the original person follow up later
<lifeless> poolie: why would the original person be following up any later than the new pilot?
<poolie> i think they might be busy with other things or distracted when their week is over
<lifeless> poolie: I mean, to be clear, I have no objection to more people helping out. But having the pilot stop on friday night seems wrong.
<poolie> i would say their obligation to help finishes friday night
<poolie> or their commitment
<poolie> i want to make it easy enough on developers that they will do it
<lifeless> what I find odd is that the two people that have done it so far haven't had an issue with this.
<poolie> ok
<poolie> i think this discussion is running dry
<poolie> i'm not going to avoid touching reviews you've already commented on
<lifeless> I am happy if you *want* to touch everything
<poolie> i'm also not going to move the goalposts on the submitter without good reason
<lifeless> I just want you to also pilot new things landed up to friday next week. Given that piloting only ever blocks on getting a second reviewer, this should be very easy for you.
<lifeless> poolie: bah, my first sentence parses badly; please apply logic-checker on reading it :)
<lifeless> I wasn't ever suggesting you should avoid reviewing stuff
<lifeless> that would be nuts
<poolie> you're saying you want me to promise to keep reviewing anything that lands this week, for as long as it takes?
<lifeless> give me a minute pease, ringing tim to get bzr/+activereviews unbroken.
<lifeless> poolie: yes
<poolie> vila, hi, around?
<poolie> want to talk about https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/13832
<bialix> poolie: hi
<bialix> are you here?
<bialix> hello all
<poolie> hi there
<bialix> hi, can you say some ETA on next 2.1 release? (b4 or rc1)?
<bialix> I need to plan next qbzr release accordingly
<poolie> sure
<bialix> the date is already known?
<poolie> according to https://edge.launchpad.net/bzr/2.1 it's the 14th of december
<poolie> and i don't see any reason to change that
<bialix> thanks poolie, that's fine for me
<poolie> we haven't been totally precise but we've been pretty close to those dates
<bialix> poolie, I'm thinking about blogging on new cool features in qbzr 0.17, somrthing like LP guys wrote for their release announcements (with screenshots et al)
<bialix> there is main bzr blog
<bialix> or I can start special qbzr blog
<bialix> because I have no access to main bzr blog, so I'm in doubts
<poolie> i would like that a lot
<bialix> poolie, do you think I should start dediacted blog? From other hand the chances that I'll blog in the future maybe not very high
<poolie> i can certainly give you access
<poolie> i think you should just put it there and tag it qbzr
<bialix> can I do series of post, one for each separate feature?
<poolie> sure
<bialix> what you need from me to give me access? sign with blood ;-)
<poolie> your prefered email address?
<bialix> should be listed on my page: https://launchpad.net/~bialix
<poolie> ok, sent
<poolie> let me know if there's any problems
<bialix> got your mail
<bialix> hmmm
<bialix> it said "bialix" username already exists
<poolie> ! :)
<bialix> ok, I've reset the password and now successfully login
<bialix> don't see bazaarvcs blog though
<bialix> poolie: on the page "My blogs" there is no bazaarvcs
<bialix> I don't know what I'm doing wrong
 * poolie looks
<poolie> try now?
<bialix> poolie: works now, I'm in
<poolie> great
<poolie> i see gary already posted about some things
<bialix> poolie: ok, found magic button "New Post". it seems I can write
<bialix> thanks
 * bialix don't use wordpress so will need some time to learn
<poolie> great
<poolie> give it a try?
<bialix> what do you mean?
<bialix> I'll post tonight, after work
<vila> hi all
<poolie> hi vila
<poolie> i just posted some things on bug 353370 in regard to your patch for that
<ubottu> Launchpad bug 353370 in bzr "Lines cut off at 80 chars regardless of actual terminal size" [High,Fix committed] https://launchpad.net/bugs/353370
 * vila reading
<poolie> also i'm going to logoff soon
<vila> poolie: ok, I'll comment there then
<poolie> bialix: do you have any ideas how to debug bug 490228?
<ubottu> Launchpad bug 490228 in bzr "Crash in groupcompress during commit operation" [Undecided,New] https://launchpad.net/bugs/490228
<vila> oh, you commented on the mp too
<poolie> yeah
<bialix> hi vila
<poolie> then i thought that bugs were a better place
<bialix> poolie: right now I can't say anything useful
<poolie> so essentially i think we should fix the api somehow
<poolie> bialix: ok, i just wondered if you knew a better way to get a good stacktrace?
<bialix> no
<bialix> maybe jam
<poolie> vila: istm that "how wide is the terminal" should at the lowest level sometimes say "i don't know " or "i'm not sure" and then what happens with that depends on how you're going to use ti
<poolie> it*
<poolie> not sure though
<vila> hmpf
<vila> exactly what I was going to say :-)
<poolie> :)
<poolie> the good thing is there are only a few callers
<vila> which means: 1) don't bother for log --line 2) progress bars are drawn only if the termiaal width is known
<vila> i.e. don't outsmart the user and let it fix it's terminal width if things go wrong
<vila> with the caveat that we don't want do *not* display progress bars too aggressively ?
<vila> hi bialix
<bialix> poolie: btw irclogs bots seems broken
<bialix> bonjour vila
<poolie> bialix: thanks
<poolie> on irclogs.ubuntu.com?
<bialix> yes
<bialix> since Saturday no new logs
<bialix> for all channels
<poolie> mm i see
<poolie> thanks
<poolie> vila: so istm we should: let terminal_width return None and check the callers will cope
<poolie> and also make it trust COLUMNS even if not on a tty
<vila> that's sound pretty close, I have to check COLUMNS behavior a bit more since I discovered some strangeness there (at least the behavior is not as clear as I thought)
<vila> but yeah, if COLUMNS can't be fully trusted, use BZR_COLUMNS
<poolie> bialix: i filed a ticket for it; nobody's responding at the moment
<poolie> good night all
<vila> poolie: good night
<bialix> fullermd: ping
<thrope> hi - is it possible to copy a file with hisotry?
<Peng> thrope: no
<thrope> oh - thats a pain
<Peng> Yeah.
<Peng> Bazaar's design makes it a bit tricky, and nobody has done the work yet.
<thrope> ok - thanks
<vila> thrope: out of curiosity, why do you want to do that ? I generally needed that in CVS days because I couldn't rename a file, but now ?
<thrope> vila: forking a file... working on a paper/report and had a script to produce figures for it.... but now changing the structure of report completely so I'm going to change it, but still want the old one around
<thrope> I guess I could tag or something instead but I'd rather make a copy and have them both there so I can compare more easily
<vila> thrope: how about creating a new branch while keeping the old one around ?
<thrope> vila: yeah I could do that I guess... but I run the code on a number of difference machiens that are all bound so it would mean working out which one is bound to what etc
<thrope> its ok just to loose the history in this cae... can always look back at the original file
<bialix> vila: I have use case for you: split big file into 2
<thrope> bialix: thats a better one ;)
<vila> bialix: I know there are valid use cases, I wanted some fresh input :)
<bialix> vila: I'm just encounter this use case *today*
 * bialix sighs and hides
<vila> bialix: And what are your expectations with regard to future merges ?
<bialix> I'm happy to not have future merge, but like to preserve annotations
<thrope> maybe merge to original with a warning that file has been copied and merge not applied to copied file
<bialix> different file-ids today makes future merge after split the pain too
<kostja_osipov> hi
<kostja_osipov> how do I retrieve per-file comments for a revision from the command line?
<beuno> kostja_osipov, bzr log FILE -r REVISION?
<kostja_osipov> hm...
<kostja_osipov> is there a way to get all comments for all files at once?
<beuno> bzr log FILE?
<kostja_osipov> beuno: imagine I have a revision number: 2640.4.4
<kostja_osipov> I can do bzr diff -c 2640.4.4
<kostja_osipov> that gives me a diff that this revision introduced
<kostja_osipov> I can do bzr log -c 2640.4.4
<kostja_osipov> that gives me the changeset comment for that revision
<kostja_osipov> well, I could of course do bzr log <file1> -c 2640.4.4
<kostja_osipov> then bzr log <file2> -c 2640.4.4
<kostja_osipov> and so on
<kostja_osipov> but that will take quite a while (the patch changes many files)
<beuno> kostja_osipov, there ar eno per-file comments on commits
<beuno> commits are atomic
<kostja_osipov> beuno: it's a terminology issue I guess. when I commit, I can write per-file comments.
<beuno> kostja_osipov, I am not aware of such thing with bzr
<kostja_osipov> beuno: try bzr gcommit ;), click on a file, you can add a file-specific commit comment.
<beuno> ah, right
<beuno> I'm not sure how that gets stored though
<beuno> jelmer may, if he's around  :)
<kostja_osipov> yeah, so now I'd like to get it back
<bialix> kostja_osipov: I think you can't yet
<bialix> I have ideas for adding such feature to qbzr though
<beuno> bialix, it's stored as metadata, right?
<bialix> as revision properties
<bialix> something like ci --fixes
<ChrisMorgan> I'm trying to log in to Launchpad Bazaar (on Windows) and it's not working at all.
<ChrisMorgan> I'm getting: bzr: ERROR: Connection error: Unable to authenticate to SSH host as |  chris.morgan@bazaar.launchpad.net   |   supported auth types: ['publickey']
<bialix> beuno: only bzr-gtk currently supports per-file commit messages (this is MySQL thingy)
<bialix> ChrisMorgan: you have to use SSH keys
<bialix> ChrisMorgan: hint: pageant, puttygen
<bialix> there is nice tutorial on lp wiki
<ChrisMorgan> How?  I have an SSH key up there, but I can't work out how to feed the private key into Bazaar
<bialix> ChrisMorgan: pageant?
<beuno> kostja_osipov, that basiclly means that you can't get it from the command line, you will need to write a script
<ChrisMorgan> pageant?
<bialix> ChrisMorgan: what are your SSH client on Windows? How do you generate SSH key?
<ChrisMorgan> I generated it with PuTTY
<bialix> great
<bialix> now run pageant -- this is part of Putty package
<bialix> pageant.exe
<ChrisMorgan> Is this to turn it into id_rsa.pub?
<bialix> it will start small icon in system tray area
<bialix> no
<bialix> no
<bialix> no
<bialix> you should have *.ppk file
<ChrisMorgan> OK; running.
<ChrisMorgan> Yep
<bialix> private key generated by puttygen
<ChrisMorgan> Added ppk
<bialix> double click on pageant icon and add key
<bialix> now run bzr again
<ChrisMorgan> Then?
<bialix> then what?
<bialix> run your bzr command again
<ChrisMorgan> OK... so what did pageant do? :/
<ChrisMorgan> Thanks :-)
<bialix> pageant is putty key agent
<bialix> it provides bzr with your private key
<ChrisMorgan> So it has to be running all the time when I use bzr?
<bialix> you may want to put pageant into autostart entry
<kostja_osipov> beuno: ok,I"m ready to write a script
<bialix> yep
<kostja_osipov> do you have some how-to or something?
<kostja_osipov> I have over 200 changesets for which I need this stuff.
<bialix> kostja_osipov: look at log code
<ChrisMorgan> lifeless: #bazaar should redirect to here; #bazaar was my first guess (incidentally then, why is there a CIA bot sitting in there?)
<kostja_osipov> bialix: i see
<bialix> there is similar thing to per-file messages: branch nick
<kostja_osipov> okay?
<bialix> look how branch nick extracted from revision
<bialix> it's basically access to properties dict
<bialix> you may want to look into bzr-gtk code to see exact key values
<bialix> kostja_osipov: I think actually bzr-gtk is your friend here
<kostja_osipov> bialix: something like this:
<kostja_osipov>       # per-file messages
<kostja_osipov>         file_info = revision.rev.properties.get('file-info', None)
<kostja_osipov>         if file_info is not None:
<kostja_osipov>             if isinstance(file_info, unicode):
<kostja_osipov>                 file_info = file_info.encode("utf-8")
<kostja_osipov>             file_info = bencode.bdecode(file_info)
<kostja_osipov>             if file_info:
<kostja_osipov>                 for fi in file_info:
<kostja_osipov>                     to_file.write('%s%s%s\n' % (indent, "     @ ", fi['path'],))
<kostja_osipov>                     if fi['message']:
<kostja_osipov>                         for line in fi['message'].rstrip().split("\n"):
<bialix> pastebin please
<kostja_osipov>                             to_file.write('%s%s%s\n' % (indent, "        ", line,))
<kostja_osipov> heh ;)
<bialix> yep, something like that
<bialix> I don't have copy of MySQL branch to test it ;-)
<kostja_osipov> bialix: ok, I think I can actually already access this functionality indirectly via:
<kostja_osipov>  bzr log --mysqlcommitemail -c 2630.4.3
<kostja_osipov> (this switch comes from mysql plugins)
<kostja_osipov> pretty nice:
<kostja_osipov>    2630.4.3 Dmitry Lenev	2008-05-24
<kostja_osipov>             WL#3726 "DDL locking for all metadata objects"
<kostja_osipov>             
<kostja_osipov>             Fixed failing Windows builds by adding mdl.cc to the lists
<kostja_osipov>             of files needed to build server/libmysqld on Windows.
<kostja_osipov>      @ libmysqld/CMakeLists.txt
<kostja_osipov>         Added mdl.cc to the list of files needed for building of libmysqld.
<kostja_osipov>      @ sql/CMakeLists.txt
<kostja_osipov>         Added mdl.cc to the list of files needed for building of server.
<kostja_osipov> (sorry for flooding the channel -- is it not allowed here?)
<bialix> there is plenty of ru people in your team?
<kostja_osipov> some; what team do you have in mind? server runtime?
<bialix> I dunno
<bialix> I'm not sql hacker, just qbzr hacker
<bialix> kostja_osipov: btw, I have evil plan to add support for per-file messages to qbzr; to qlog, qann and qci
<kostja_osipov> we have multiple server teams, each works on an area. In runtime therea are 3 Russians, 3 Norwegians, 1 Swede, 1 Brazilian, 1 German, etc
<kostja_osipov> bialix: I'm not using q* stuff
<bialix> this is not to you personally
<kostja_osipov> bialix: my #1 wish would be that cherry-picking (bzr merge -c) would automatically transfer all comments along with the patch.
<bialix> kostja_osipov: you can replay revision and then merge it
<bialix> or rebase if replay refuse because of conflicts
<mthaddon> jam: RT#36031 is about configuring PQM to use python2.4, and the last comment in there is about asking you guys to let me know when you're ready for me to change the configs to use "make pqm-test" as the pre-commit hook - that sound familiar?
<jam> mthaddon: indeed it does. I replied to your email
<jam> vila: are you around?
<mthaddon> jam: great, thx
<vila> jam: hi ! Glad to see you back, I hope your son and you are going better
<jam> yeah, a bit of a cough left, but no fever, etc.
<jam> vila: just wondering how babune, et al are holding up
<jam> freebsd seems to have failed again?
<vila> yeah, lots of trouble :-/
<vila> the combined upgrade of karmic/vbox made many slaves unstable or losing connections, I'm upgrading the gentoo one right now hoping to get it stable :-/
<vila> I'm torn between migrating to hudson or waiting to have more stability back :-/
<vila> In fact I'm suspecting some change in buildbot itself (brought by the karmic upgrade_
<vila> )
<bialix> hi jam, glad you're back
<vila> jam: in summary, I have the Ubuntu slaves up and running, I'm trying to fix the others while manually running the test suite when I can
<jam> hi bialix
<bialix> jam: without you even there is no announce for latest releases
<bialix> btw, jam, maybe it's just me so paranoid, but I think latest regression on windows custom globber with replacing all \ with / is serious enough to not put it into wild
<kostja_osipov> vila: btw, I've finally gotten to the file-id
<kostja_osipov> problem
<kostja_osipov> indeed, when the file is added by the cherry-picking command, there is no file-id issue
<kostja_osipov> it would be really great if it was possible to change file-ids. I'm not the only one who has stepped on these rakes...
<vila> kostja_osipov: once you start sharing any history, you can't change file-ids or revi-ids anymore
<vila> I understand the pain, but I can't think of a good work-around. What you did was telling bzr that you created a new file and then you want to merge it with another one. Until we implement file-tokens (the exact name escapes me right now), there is little that can be done.
<vila> But once there are implemented, you'll be able to "join" two files saying to bzr: look, these files are really the same one
 * vila hates saying: come back later, we'll have a such better solution :-(
<kostja_osipov> vila: this is a pretty unique situation we're in
<kostja_osipov> i hope it'll be a one-time issue
<bialix> vila: path tokens
<vila> kostja_osipov: yeah, it's a usability issue, but one that can lead to some lost hours :-/
<vila> bialix: thanks ! I was close :)
<bialix> yeah :-D
<kostja_osipov> vila: the reason I got trapped in this is that I thought that bzr merge -c is equivalent by cd source; bzr diff > ~/tmp; cd dst; patch -p0 < diff
<kostja_osipov> but it actually isn't
<kostja_osipov> bzr merge -c is a very "interesting" command.
<kostja_osipov> it doesn't transfer the original revision id; but on the other hand it's not an equivalent of diff + patch
<vila> kostja_osipov: yes. You should *never* user patch
<kostja_osipov> it is unclear why :)
<vila> err, I meant: You should never *have* to use patch
<kostja_osipov> I would stick to always using bzr merge -c if I understood exactly what it does
<kostja_osipov> vila: the reason I used patch instead of bzr merge was this:
<vila> kostja_osipov: roughly the same as patch, but taking renames into account :)
<kostja_osipov> I'm cherry-picking a changeset.
<kostja_osipov> it contains changes to files that are not yet in the destination tree
<kostja_osipov> so I get a lot of conflicts.
<kostja_osipov> the easiest way for me to solve them all was to:
<kostja_osipov> bzr diff > ~/patch
<kostja_osipov> bzr revert
<kostja_osipov> patch -p0< ~/patch
<kostja_osipov> this way I don't have to manually revert all "new" files which I don't want
<kostja_osipov> but I figured it has a gotcha :)
<kostja_osipov> so I restarted from a fresh tree, and re-done bzr merge -c, this time bzr reverting all new files I didn't want
<kostja_osipov> and now I seem to be all set
<nmb> vila: I'm free if you've got a chance to talk about 395714
<vila> nmb: Neil ! I've talked with Glenjamin, I'm pretty sure this is caused by bzr-svn, I know why and how to fix it.
<nmb> Cool!
<vila> s/pretty sure/now sure/
<nmb> vila: I'm glad we tracked down where it was coming from.
<nmb> vila: Would you like me to try with disabling bzr-svn or do you have all the datapoints you need?
<vila> nmb: sure ! Thank you so much for your efforts there !
<nmb> vila: checking...
<vila> The root cause is that bzr-svn is using the requests in a way that is not supported. I've talked with jelmer and will make the necessary changes in bzr
<vila> and may be even provide a patch for bzr-svn so all code paths are covered
<vila> nmb: search for req.follow_redirections = True in bzr-svn transport.py, this option can't be used with authentication
<vila> that's where I didn't understand how it occurred to you (I haven't read the traceback close enough :-/)
<nmb> vila: If I disable bzr-svn, it works on the glenjamin.co.uk URL and on my local URL where I discovered the bug.
<vila> nmb: and that explains why I didn't reproduce it (the machine I used didn't have bzr-vsn installed)
<Noldorin> hi. i'm trying to set up loggerhead on an http server here, but don't know how to go about it
<Noldorin> could anyone direct me please?
<Noldorin> lifeless: hello?
<nmb> Noldorin: I've just done it.
<jelmer> vila: Please let me know if there's anything I can do to help with that
<vila> nmb: Great ! Thanks for checking
<nmb> Noldorin: Tell me more about your setup
<Noldorin> nmb: excellent. well i'm trying to set it up on an iss7 server (with isapi-wsgi installed)
<nmb> vila: I'll mark my branch as abandoned and the merge proposal as obsolete as well
<Noldorin> so far i've just uploaded the loggerhead files and the dependencies
<nmb> Noldorin: loggerhead usually works as a proxied local web application...
<vila> jelmer: well, waiting for the OPTIONS support in bzr you can try to rewrite dav_options to use do_catching_redirections instead of using req.follow_redirections but I'm not sure it's worth the effort and you should keep your energy for tomorrow :-D
<vila> nmb: ok, thanks
<Noldorin> nmb: yeah, that's what i gathered from the main web page
<jelmer> vila: :-)
<nmb> Noldorin: I don't know IIS, but the general structure is that loggerhead runs on the server on port 8080...
<Noldorin> i'm on a shared server here...
<Noldorin> although with a number of config options
<Noldorin> hmm
<Noldorin> how are you running it>?
<nmb> Noldorin: then you proxy a particular location from your webserver to pass the requests on to loggerhead
<Noldorin> right
<nmb> Noldorin: I'm using Apache as the outward-facing HTTP server
<Noldorin> dedicated server?
<Noldorin> looks like i'll have to play with some isapi-wsgi config settings
<nmb> Noldorin: yep, dedicated server
<Noldorin> nmb: hmm. i'm stumped how to get it running on a shared iis server now
<Noldorin> or any server for that matter
<Noldorin> any tips?
<Noldorin> i mean, not having access to the command line is a bit of a pain here
<nmb> Noldorin: you can't run any command line programs?
<Noldorin> nmb: at least i'm not aware how to do that on a shared server
<nmb> Noldorin: loggerhead is running as a service on an Ubuntu machine, but the command that starts it is "loggerhead/serve-branches --prefix=/bzr --port=8080 /var/bzr"
<Noldorin> mm
<Noldorin> which is why i'm not sure where to proceed now
<nmb> Noldorin: where /var/bzr is where the branches live
<nmb> Noldorin: I know that it is possible to set up commands to run on startup under Windows, but I am not enough of a Windows admin to know how.
<nmb> Noldorin: Can you get a terminal services/remote desktop login on that shared server?
<Noldorin> i don't believe so
<Noldorin> nmb: http://www.storminternet.co.uk/hosting_aspnet.asp - i have the ultimate package
<Noldorin> hmm
<Noldorin> i don't even have ssh available it seems
<Noldorin> nmb: anyway around that, you think?
<guilhembi_> Hello. An exception is generated in some bzr plugin that we have in MySQL; I'm running bzr in the debugger, but bzr seems to catch it, print the traceback to some debug file, and terminate. I'd rather want bzr to not catch the exception, so that debugger (winpdb) stops there. How can I do this?
<nmb> Noldorin: No, I don't think so.  Loggerhead needs to be run as a program on a local python installation (as far as I know)
<Noldorin> nmb: mm, that's what i'm afraid of. i wonder if there's any pure-http alternative
<guilhembi_> vila: do you know?
<nmb> Noldorin: http://bazaar-vcs.org/WebInterfaces for your different options
<Noldorin> nmb: thanks. i'll take a look
<nmb> Noldorin: Particularly webbzr: http://thoughts.enseed.com/webbzr/
 * guilhembi_ tries -Derror
<vila> guilhembi_: BZR_PDB=1 before bzr is what I'd use on Linux, you'll have to find how to do that on windows
<guilhembi_> vila: I'm using Linux
<vila> oh, then it should work :)
<guilhembi_> vila: but it does put me in the ordinary text-based debugger; isn't there a way to
<guilhembi_> 1) not catch the exception
<guilhembi_> 2) not have bzr start the debugger, but rather I start bzr in the debugger that I choose
<guilhembi_> ?
<vila> no idea for 1 & 2, but you may be able to replace the bzr call to pdb to the debugger you want ?
<guilhembi_> vila: that would require attaching the debugger (winpdb) to a running process via some command-line,
<guilhembi_> which I don't yet know how to do, but which I can research.
<vila> guilhembi_: look at exception_to_return_code in bzrlib/commands.py
<guilhembi_> vila: thanks
<vila> guilhembi_: I just installed winpdb and used launch 'bzr info', it started the bzr script and waits for input, hacking exception_to_return_code seems the way to go...
 * vila foes back to kitchen
<vila> s/foes/goes/
<guilhembi_> bbl
<jelmer> vila: I'd rather wait for OPTIONS to be in bzrlib and help out with that where possible
<jelmer> the stuff in bzr-svn is already quite hackish and untested
<jelmer> (well, not unit tested - it was tested manually)
<Noldorin> hi. i'm trying to run loggerhead on my server, and i'm getting the following error:
<Noldorin>  File "D:\inetpub\vhosts\noldorin.com\httpdocs\python\loggerhead\loggerhead\main.py", line 24, in <module>  from bzrlib.plugin import load_plugins ImportError: No module named bzrlib.plugin
<Noldorin> any idea what i need to do to fix it?
<phinze> hey folks, so how much of an overhead price do i pay with bzr+ssh versus $OTHER_BETTER_TRANSPORT
<thumper> phinze: bzr+ssh gives streaming of revisions, which is v.good
<thumper> phinze: bzr+ssh has the overhead of ssh compared to just the bzr protocol itself
<phinze> well that sure _sounds_ good ;)
<thumper> phinze: has higher semantic communication between client and server
<thumper> phinze: so not just at a filesystem level
<phinze> exactly, and i'm wondering about how much that overhead is costing me on `bzr up`
<thumper> phinze: whose server?
<phinze> our dev group's central repository server
<phinze> so i have the ability to switch the transport if there is reason to
<phinze> s/switch the/recommand a switch to another/
<phinze> blah, *recommend
<thumper> if it is all your servers
<thumper> then perhaps bzr protocol is enough
<thumper> I'd ask a core bzr person though
 * thumper looks at lifeless
<bialix> I have couple of questions
<fullermd> bialix: I have a couple answers.  1492.  Yellow.  Yes, in a vacuum.
<bialix> 1) If I want to call external GUI to resolve conflicts as 3-way merge, but I did merge --weave and have only THIS and OTHER. What can I use instead of BASE?
<bialix> fullermd: missed
<bialix> evening fullermd :-)
<fullermd> Darn.  I was so close...
<fullermd> I don't know that you can.  External conflict resolution tools are mostly based around 3-way merge, aren't they?
<bialix> fullermd: I think the right answer is "vacuum"?
<phinze> thumper: sounds good, thanks
<bialix> fullermd: not all
<bialix> many tools can work in 2-way merge mode
<fullermd> To deal with --weave aftermath, they'd have to implement weave merging themselves, which means they'd also need all the line history too, not just a couple source files.
<phinze> i imagine jam would know also
<thumper> phinze: that he would
<bialix> fullermd: it was joke?
<bialix> I have example of 1-way merge tool which can be progressed to 2-way: editor
<fullermd> Not really, know.  Weave merge implies working with a lot of intermediate history, so it's way outside the scope of what you could get from BASE/THIS/OTHER files.  That only covers 3-way.
<bialix> but weave in the end generatest THIS and OTHER?
 * bialix looking for jam
<bialix> jam1: are you around?
<fullermd> Well, there's nothing to generate with those two.  There's just what we had, and what the other side had.
<jam1> bialix: ?
<fullermd> BASE is the only generated one of the 3, but it only makes sense in 3-way (that's why it's 3-way after all).  With weaves, there is not 'base' of the whole file.
<bialix> jam: weave merge
<bialix> what can I use s BASE after weave merge?
<bialix> to resolve conflicts in 3-way style?
<jam> bialix: unfortunately there isn't really a BASE, I believe there is a MySQL bug about it, and I'm trying to investigate if we can put *something* for BASE
<jam> but really, the BASE is not very well defined for weave
<bialix> I can use empty file, but it sounds weird?
<bialix> I'm sketching new external merge support for qbzr
<bialix> I'm trying to understand what should I do with conflicts when there is no BASE file
<bialix> maybe I can puth file with conflicts there as BASE?
<bialix> fullermd: I'm using WinMerge a lot ast time, it's only provides diff/merge tool based on 2 sides: their/mine files
<bialix> and I can merge changes even without BASE
<bialix> the tool is able to find common lines and then highlight lines where text at both sides are different
<jam>  bialix: 2-way diff is equivalent to 3-way with BASE being empty
<bialix> I don't have experience with real 3-way tools yet
<jam> so the main difference is that there are places where the two texts differ and one clearly supersedes
<bialix> so, empty file in the end, as I thought
<jam> 2-way can't tell you that
<jam> all it can say is "they differ here"
<bialix> jam: but after bzr doing merge we have only valid conflicts in the file?
<bialix> maybe winmerge doing the right thing by parsing conflict markers, instead of rely on THIS/OTHER
<bialix> so there is no obvious answer, empty file as first guess
<bialix> second question: versioned tags
<bialix> today we have very unpleasant merge scenario at work when tags was not propagated because there already tagged
<jam> so using conflict markers is a 2-way diff, after we've already worked out the 3-way base
<bialix> jam: anybody has sketches or plan on how versioned tags could be implemented?
<donri> is there something similar to git add -p, that is commit only some changes to a file?
<jam> donri: generally done by doing the inverse with "bzr shelve" first
<jam> to pull out the changes you don't want
<bialix> donri: we have similar to git stash
<jam> then commit what you do
<lifeless> moin
<donri> sounds backwards and cumbersome
<donri> uhm, but thanks :)
<bialix> lifeless, jam: versioned tags: how's hard they would be to implement?
<lifeless> phinze: how long does 'time ssh <server> bzr help' report
<jam> bialix: the concept isn't very difficult, figuring out how to present it to the user is
<lifeless> bialix: coding it? not long. deciding on semantics? oh, a year or two :P
<phinze> lifeless: good call --> real 0.357s user/sys: 0.003s
<donri> is there something like rebasing in git?
<bialix> what is semantic?
<lifeless> bialix: how they should behave
<bialix> donri: yes, bzr-rebase (bzr-rewrite) plugin
<donri> nevermind, i can probably google that one
<donri> thanks
<bialix> lifeless: a bit better than today
<Noldorin> hi lifeless
<bialix> deletion of tags are not propagated, tags are not mergeable
<Noldorin> lifeless: it seems i have isapi-wsgi on my server...
<bialix> jam: does user realy need to have other presentation than it is today?
<bialix> jam: git seems to use signed tags concept? when there is author who created tag, and when
<jam> bialix: how do you present when tags conflict
<bialix> as other conflict: special metadata in working tree or branch?
<bialix> jam: the problem is today they always conflicts, even if other side update the tag made by this side
<bialix> ok, it seems git has the same problems with tags
<bialix> it just has name of tag author
<bialix> jam, lifeless: in the past poolie suggested to use empty string instead of revid to allow push/pull of tag deletion. does adding such thing to current tag dict will be considered a format break?
<bialix> btw, according to git manual if tags conflict then my tag wins over other tags
<bialix> so bzr in the same area here
<bialix> perhaps I should send mail to main list?
<jam> bialix: so one possibility would be to store the tags as a .weave file where the current tags is just a sorted list of lines
<jam> adding/deleting/etc a tag is just adding a new text to this list
<jam> that will propogate
<jam> support deletes
<jam> support adds
<bialix> so every tag will be separate file?
<jam> etc
<jam> no, one file, sorted list of tag value pairs
<bialix> sorted by tag name?
<jam> yeah
<jam> that can conflict accidentally from regular merges, but rarely I would guess
<bialix> is it possible to add additional metadata here? author of tag and date?
<bialix> jam: does such weaved tags should live in .bzrmeta?
<jam> .bzrmeta is for versioned texts that are part of the tree
<jam> I would consider this separate
<jam> if you put it in .bzrmeta, then I would have it .bzrmeta/tags and just a plain text file, versioned normally
<jam> with the main problem that tag operations must then be "bzr commit" to work
<bialix> you wrote "regular merge" so I've confused
<bialix> yep, like in hg
<bialix> and that sucks
<fullermd> I think if you think around and around it enough times, you end up with the conclusion that versioned tags require another axis of versioning (much like editing commit messages)
<bialix> I think you're right
<bialix> the more I think about this, the often I conculde this
<bialix> exactly the same as you saud
<bialix> said
<bialix> sorry
<jam> fullermd: right, hence putting it into a weave
<bialix> (couple of years is old enough?)
<jam> which is equivalent to a knit, but is only a single file :)
<fullermd> And hey, we can put content filtering rules on that axis too, and re-open THAT argument at the same time!
<bialix> jam: where I can read about weave for mere mortals?
<fullermd> Well, that's just storage semantics.  It's working out the extra axis that takes the time.
 * bialix fears to say v.p.
<fullermd> You can't just store it as a .weave in the WT; that opens up all sorts of horrific bootstrap issues.
<jam> fullermd: yep
<bialix> I know
<bialix> chicken-eggs
<Noldorin> hi. i'm trying to run loggerhead on my server, and i'm getting the following error:
<Noldorin>  File "D:\inetpub\vhosts\noldorin.com\httpdocs\python\loggerhead\loggerhead\main.py", line 24, in <module>  from bzrlib.plugin import load_plugins ImportError: No module named bzrlib.plugin
<Noldorin> any ideas what i need to do please?
<bialix> Noldorin: what version of bzr are you using?
<Noldorin> 2.0.1 i believe
<Noldorin> but i guess it's the version of bzr that loggerhead wants to use that is important
<bialix> are you installed standalone bzr.exe or python-based? you need the latter
<Noldorin> bialix: since it's on the (shared) server, i guess it indeed has to be the latter
<bialix> Noldorin: bzr version output tells you the truth
<Noldorin> i guess i just need the entire source for bzr?
<Noldorin> the version that loggerhead uses
<bialix> you can download python-based installers from LP
<bialix> for your python version
<bialix> 2.4 - 2.6
<Noldorin> bialix: it's a shared server, so the best i can do is transfer files via ftp
<bialix> I don't understand what it means "shared server"
<kirkland> i'd like to use bzr export, but --exclude debian/
<kirkland> is that possible?
<kirkland> i see --filters, but I don't understand how to use it
<bialix> kirkland: --filters is different
<kirkland> bialix: okay ...  so is there any convenient way to --exclude?
<bialix> kirkland: it seems there is no
<bialix> delete debian after the export?
<Noldorin> bialix: virtual server? i.e. a non-dedicated one - i have to access it via a control panel
<bialix> Noldorin: so how you installed loggerhead?
<Noldorin> i haven't exactly yet
<Noldorin> but the server has isapi-wsgi
<Noldorin> so i think i can just run loggerhead/main.py
<bialix> so put there bzr sources from tarball
<bialix> but I fear this is wrong path
<Noldorin> that's what i was thinking yeah
<Noldorin> what do you suggest then?
<bialix> I have no real experience with VPS
<bialix> try eith bzr sources first
<bialix> all you need is to put bzrlib in the same folder where main.py resides, perhaps
<mathiaz> Hi!
<jam> hi mathiaz
<mathiaz> How do you handle a directory that has been moved during a merge?
<mathiaz> in my use case, upstream has introduced its own debian/ directory
<mathiaz> and that conflicts with the existing debian/ directory in the ubuntu branch
<mathiaz> how can I solve this (ie keep the debian/ directory from the ubuntu branch)?
<abentley> lifeless: do you have an estimate of how long it would take to fix bug #375013 ?
<ubottu> Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013
<lifeless> abentley: a week or more
<abentley> thumper: ^
<thumper> lifeless: why?
<abentley> lifeless: Thanks.
<thumper> lifeless: is that just a gut feel?
<lifeless> thumper: because we have to make commit use the same data integrity checks fetch does
<thumper> lifeless: or have you some background in it
<thumper> lifeless: this is something I'd dearly love to see fixed
<lifeless> thumper: and that is best done by moving commit to the same api, which will reduce overall code size too
<lifeless> but that means revving the streaming api to meet commits needs
<lifeless> you /might/ be able to hack something up in only 2 or three days by duplicating the checks and the extra data fetches
<lifeless> but I would guarantee that doing it that way will lead to bugs and concurrency issues (such as smart server protocol errors )
<lifeless> not to mention that duplicating code adds technical debt
<lifeless> thumper: to summarize, this is a deep defect, not UI level, fixing [so that it stays fixed] requires care and addressing some 4+ year old api issues.
<thumper> lifeless: ok, thanks for the summary
<lifeless> turning off the error is easy, one-line. Preventing the repo corruption that that causes is the hard part ;)
<mathiaz> one solution to my problem (completely different debian/ directories for the upstream and ubuntu branches) would be to have an intermediate branch (upstream-nodebian) where the debian/ directory would be removed
<mathiaz> and then merge the intermediate branch into the ubuntu branch - would this work for subsequent merges?
<jelmer_> mathiaz, I think you would still get conflicts when you merge in changes from upstream to debian/
<jelmer_> (somebody please correct me if I'm wrong)
<mathiaz> jelmer_: well - in that particular use case, I don't care about the upstream debian/ directory
<mathiaz> jelmer_: ie changes from the upstream debian/ directory should not be merged into the ubuntu debian/ directory
<jelmer_> mathiaz: when you merge from upstream and upstream has modified debian/ since your last merge, bzr will attempt to apply the changes but will be unable to find the relevant files so will create conflicts
<mathiaz> jelmer_: ah ok. This will happen when you merge the upstream branch into the upstream-nodebian branch?
<jelmer_> mathiaz: dealing with those conflicts shouldn't be too hard though if you don't care about what upstream did
<jelmer_> mathiaz: yes
<mathiaz> jelmer_: ok - in which case  we know what we wanna do about those conflicts
<mathiaz> jelmer_: now if upstream decides to remove their debian/ directory from their upstream branch, can we merge directly the upstream branch again (instead of upstream-nodebian)?
<jelmer_> mathiaz: yeah
<mathiaz> jelmer_: merge the upstream branch directly into the ubuntu branch
<mathiaz> jelmer_: and there shouldn't be any problem in terms of branch history?
<jelmer_> mathiaz: *nod*
<jelmer_> mathiaz: actually, you shouldn't need a upstream-nodebian branch either - you should be able to merge upstream directly and resolve the conflicts there
<mathiaz> jelmer_: well - How do I resolve the conflict then?
<mathiaz> jelmer_: the ubuntu debian/ directory is moved to debian.moved/
<mathiaz> jelmer_: and the upstream debian directory is added as debian/
<jelmer_> mathiaz: Remove the existing debian/ directory and then "bzr mv debian.moved debian"
 * mathiaz tries
<jelmer_> mathiaz, after that, you should be able to resolve the conflicts and "bzr status" should no longer list any changes to debian/
<mathiaz> jelmer_: http://paste.ubuntu.com/331989/
<NfNitLoop> mathiaz: you should've done bzr rm debian
<jelmer_> mathiaz: try "bzr rm debian" before the mv
<mathiaz> jelmer_: right - bzr remove --force debian/ works as expected
<mathiaz> now - what is going to happen during the next merge if upstream updates its debian/ directory?
<mathiaz> will the ubuntu debian/ directory be moved to debian.moved/ again?
<NfNitLoop> I would've assumed that since you've locally deleted the debian/ directory, it wouldn't try to merge into yours.  Don't files/dirs have unique IDs behind the scenes?
<jelmer_> mathiaz: I'm not entirely sure but I think you'll get files in the root directory named control.THEIRS or something like that
<jelmer_> you'll have to remove those files and run "bzr resolved"
 * NfNitLoop makes some test cases. :)
<NfNitLoop> Oh, weird.  Even though I deleted the directory explicitly in the local branch... it still moved the local version to *.moved
<NfNitLoop> when changes happen in that dir upstream.
<NfNitLoop> Though, I guess it's good that bzr isn't just swallowing changes that you might've cared about.  *shrug*
<mathiaz> NfNitLoop: well - in my use case here, I'd rather discard any change made by upstream in their debian/ directory
<NfNitLoop> Unfortunately it looks like you'll have to do that every time they make a change in their debian/
<mathiaz> NfNitLoop: ok - we can script that anyway. Thanks for helping with this!
<rbriggsatuiowa> what are the differences between "Contents conflict in" vs "Text conflict in"?
<shakaran> Hi, I have a bazaar repository, but I need convert it to a SVN. It is possible?
<lifeless> yes
<lifeless> the bzr-svn plugin can do this for you
<shakaran> Could you give me the exact command or some guide for read?
<Noldorin> hi. what do i need to include in my path to reference bzrlib.plugin ?
<NfNitLoop> shakaran: http://tinyurl.com/yjoa4w2  ;)
<shakaran> NfNitLoop: lol xD
<NfNitLoop> Noldorin: as in, you want to 'import bzrlib.plugin'?
<Noldorin> NfNitLoop: the exact line is: from bzrlib.plugin import load_plugins
<NfNitLoop> Hrmm.   bzrlib.plugin is already in my path on my server.
<NfNitLoop> did you install bzr with the install script, or just unpack it into a directory?
<Noldorin> NfNitLoop: just unpacked it to a dir. problem is that i'm on a shared server, so the best i can do is include it in my path it seems
<Noldorin> scriptDir = os.path.dirname(os.path.realpath(__file__))
<Noldorin> sys.path.append(os.path.realpath(os.path.join(scriptDir, '../../bzrlib/')))
<Noldorin> that's what i currently have
<NfNitLoop> Hrmm, I'm not sure.
<NfNitLoop> I remember not having much luck with mucking with paths at runtime in Python.
<Noldorin> NfNitLoop: shouldn't including bzrlib in the path like that be enough?
<Noldorin> i see...
<NfNitLoop> I would think so, yeah.
<NfNitLoop> but I'm not an expert on that bit. :)
<Noldorin> fair enough
<Noldorin> thanks anyway
<Noldorin> i'm just not sure how else to import that module in a shared server env
<lifeless> Noldorin: you dont want bzrlib in the path
<lifeless> Noldorin: you want the directory that bzrlib is in, in the path.
<Noldorin> oh i see
<Noldorin> heh
<Noldorin> lifeless: that does the trick. now it can't find paste however
<Noldorin> there's a dir called Paste-1.7.3 in the same dir as bzrlib
<lifeless> whats inside that directory
<NfNitLoop> Ponies!
<Noldorin> lifeless: setup.py, paste/, docs/, etc.
<blueyed> Is there any way to merge from an uncommon ancestor (with the same content)? bzr adds a lot of conflicts since files/dirs are considered to be new/different.
<lifeless> Noldorin: then you want to add the Paste-1.7.3 dir to the path too, at a guess.
<Noldorin> right ho
<Noldorin> lifeless: now i'm getting an even stranger error:
<Noldorin> ImportError: cannot import name __version__ ".
<Noldorin> from the line:
<Noldorin> from loggerhead import __version__
<lifeless> that means that there is a directory 'loggerhead' that looks like a module but isn't the right loggerhead module.
<Noldorin> lifeless: indeed it appears so.
<Noldorin> i'm afraid i'm going to have to go through a list here....heh
<Noldorin> ImportError: No module named pkg_resources ".
<lifeless> jam: Bug 437003
<ubottu> Launchpad bug 437003 in bzr/2.0 "Failure to autopack because of 'missing inventories'" [High,Confirmed] https://launchpad.net/bugs/437003
<lifeless> jam: nvm
<Noldorin> lifeless: any ideas?
<lifeless> Noldorin: you are missing some dependency
<lifeless> possibly setuptools o r something
<Noldorin> lifeless: not according to the loggerhead readme
<Noldorin> oh gosh...
<Noldorin> but i'll need all the bzrlib dependencies too, eh?
<lifeless> Noldorin: pkg_resources is a dep of paste, I think.
 * Noldorin looks for a list of bzr dependencies
<Noldorin> oh i see
<Noldorin> lifeless: it doesn't seem to be available as a download though...
<lifeless> its not called pkg_resources. I think its setuptools
<Noldorin> right
<Noldorin> lifeless: right, so simpleTALs is giving me some trouble
<Noldorin> ImportError: No module named simpletal.simpleTALUtils ".
<Noldorin> despite having included the dir in my path
#bzr 2009-12-01
<mwhudson> i don't think loggerhead strictly depends on setuptools but it does use pkg_resources
<mwhudson> (which most people have because setuptools itself depends on pkg_resources aiui)
<Noldorin> mwhudson: yeah, i'm sure you're right. i included the whole thing just to be safe thuogh
<Noldorin> right, now a non dependency-related issue
<Noldorin> The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are "".
<mwhudson> Noldorin: it's not a cgi app
<Peng> Yeah, Loggerhead doesn't need setuptools. To run, anyway. I dunno about installing it.
<Noldorin> mwhudson: hmm. yeah, it's wsgi. and the server apparently supports that via isapi-wsgi
<Noldorin> but i'm not sure how to tell it to use wsgi
<Peng> The usual practice is to use HTTP and have the server proxy to it.
<mwhudson> Peng: btw, if you want to steal stuff from http://bazaar.launchpad.net/~launchpad-pqm/launchpad-loggerhead/devel/annotate/head%3A/start-loggerhead.py and incorporate it into loggerhead proper that would be great
<lifeless> Peng: windows VPS server, nothing usual about it :)
<Noldorin> Peng: yeah, so i've been told. but i'm on a shared server
<mwhudson> (i'm thinking of the improved logging and the timeout stuff)
<Noldorin> lifeless: exactly :S
<Peng> lifeless: Ah.
<Peng> mwhudson: Hm.
<Peng> ...Great, now I'm speaking in two-letter grunts.
<mwhudson> Peng: well i guess what i really mean is "have you seen this stuff" ?
<Peng> Perhaps it would be easier to get FastCGI working?
<Peng> mwhudson: I knew of launchpad-loggerhead, but hadn't looked at it much.
<Noldorin> Peng: i'd need a fastcgi -> wsgi interface though
<Peng> Noldorin: What? You mean like flup?
<lifeless> isapi-wsgi may be that interface already
<lifeless> inside the server
<Noldorin> Peng: not sure, honestly
<Peng> Eh. I'm not going to pretend to know anything about Windows servers.
<Noldorin> this is all fairly new to me
<Peng> Or that I know what this conversation is about. :P
<Noldorin> lifeless: yeah quite possibly
<Noldorin> i'm just not sure how to use it :S
<Peng> mwhudson: lp-lh is under a different license...
<Peng> I think.
<Peng> Yeah, Loggerhead is
<mwhudson> Peng: oh god it probably is agplv3 isn't it
<Peng> GPLv2.
<Peng> mwhudson: :D
<mwhudson> and loggerhead is gpl
<mwhudson> yay
<mwhudson> we can probably get this fixes
<mwhudson> *fixed
<dOxxx> I'm running selftest on windows and I'm getting a lot of these: http://pastebin.com/m3a6c05f0
<dOxxx> It's making it pretty hard to see the "real" errors in tests :P
<Peng> (Thank goodness for licenses. Otherwise I would've had to come up with an excuse not to work on it. ;-)
<Noldorin> lifeless, mwhudson: are you stumped then?
<Noldorin> i certainly am now...
<Peng> I'm more or less happy with my logging setup, so working on that makes me want to bang my head on the wall without any benefit. :P
<Peng> I haven't run into the other things it works around, but they look interesting. 'specially the threadpool_options.
<lifeless> Noldorin: I have no idea, haven't had at any point :)
<lifeless> Noldorin: I'd guess that you don't have a proper wsgi app setup, *or* that isapi-wsgi doesn't support what we do, or something else.
<Noldorin> heh. it's really going to be much less pain using webbr i think
<Noldorin> yeah, it's just too tricky on a windows servers, let alone a shared windows service i think
<lifeless> I'm sure its doable, but other than saying 'good luck' and 'ask mwhudson if you need wsgi pointers'... I can't do much for you.
<mwhudson> loggerhead is set up bit oddly compared to many wsgi things
<mwhudson> it's more like a "http server that uses wsgi" rather than "a wsgi app" i think
<mwhudson> (this would probably be good and not that hard to fix if you knew how)
<Noldorin> lifeless: if i had the time and effort to spare, perhaps
<Noldorin> but alas i do not
<igc> morning
<Noldorin> alright
<Noldorin> too late to be hacking now, methinks
<Noldorin> thanks for your help, all
<Noldorin> 'night
<maxb> Does any documentation for bzr-git exist?
<lamalex> Hi, i keep getting this bzr: ERROR: [Errno 13] Permission denied when i do bzr update
<lifeless> lamalex: check your .bzr.log
<jelmer> maxb: the normal bzr documentation should apply
<maxb> jelmer: I'm starting to think that despite "bzr git-import" existing, there's no way to pull further revisions from a non-HEAD git branch?
<jelmer> maxb: git-import can be run repeatedly
<jelmer> but there's no other way to pull from a non-HEAD git branch
<jelmer> (since bzr doesn't have a way of addressing colocated branches)
<maxb> It would be nice to invent such a thing, even if it only was relevant to bzr-git and bzr-hg
<lifeless> it was agreed on thelist ~ a year back
<lifeless> I don't recall what the agreed way /way/
<lifeless> s/way/was/
<jelmer> lifeless: I don't think there was an agreed way
<maxb> Was the idea of doing something bzr-git specific shot down already?
<jelmer> lifeless: at least I don't recall seeing anything
<jelmer> maxb: Yes, that's a bad idea - it means we'll have migration issues later and break existing URLs
<dOxxx> I'm getting a lot of TypeErrors about Tuple when running selftest on Windows, any idea what's going? http://pastebin.com/m3a6c05f0
<lamalex> lifeless: i dont see on..
<lamalex> s/on/one
<jelmer> lamalex: should be in your home dir
<maxb> jelmer: Well.... it's sad that bzr-git remains crippled for the want of a consensus
<maxb>  remote.py |    7 ++++++-
<maxb>  1 file changed, 6 insertions(+), 1 deletion(-)
<maxb> ^ and I've made it work more or less with merely that
<spiv> lamalex: 'bzr --version' should tell you where it is
<lamalex> jelmer, lifeless: yah, found it. http://paste2.org/p/541334
<spiv> dOxxx: interesting, is this with current lp:bzr ?
<dOxxx> spiv: yes
<dOxxx> I was running --parallel=subprocess on win32
<spiv> dOxxx: are all the C modules up to date?
<dOxxx> spiv: this was from source without C modules compiled
<spiv> (i.e. have you run whatever the windows equivalent of "make build"?)
<spiv> Ah, so no C modules?  Hmm.
<dOxxx> spiv: I'm not even sure how to do that on Windows :)
<spiv> dOxxx: python setup.py build_ext -i, IIRC, but there may be tricky dependencies or something more to it...
<poolie> hello spiv, doxxx, jelmer
<dOxxx> spiv: hmmm
<dOxxx> hey poolie
<spiv> dOxxx: I can reproduce it here
<dOxxx> spiv: that's good, I guess :)
<spiv> dOxxx: probably a bug in the pure python fallback code for John's StaticTuple work
<jelmer> hi poolie
<dOxxx> spiv: should I file a bug?
<jelmer> maxb: agreed
<lamalex> anyone know about that error? i dont understand the log output
<spiv> dOxxx: yeah
<mkanat> Wow, if you run "nick" on a loomified branch, things explode.
<fullermd> If you nick us, do we not bleed?
<mkanat> lol
 * mkanat just realized his bzr is somewhat old, though.
<mkanat> 1.16.
<dOxxx> spiv: bug 490600
<ubottu> Launchpad bug 490600 in bzr "TypeError: StaticTuple can only point to StaticTuple, str, unicode, int, long, float, bool, or None not <type 'tuple'>" [Undecided,New] https://launchpad.net/bugs/490600
<mkanat> Well, 1.16.1.
<spiv> mkanat: yeah, I think that may be fixed with current bzr + current bzr-loom
 * mkanat nods.
<mkanat> Okay.
<spiv> dOxxx_: thanks!
<shakaran1> Hi, I can have severals parents locations for a branch? I explain that. I have a ppa with bazaar but I need migrate all code to a SVN. If I do a pusth with the url of a SVN, the bazaar branch complains that already exists a parent location and the show a diverged branch
<jelmer> shakaran1, hi
<jelmer> shakaran1: Does the location you're trying to push to already exist perhaps?
<shakaran1> yep, the bazar location exits, and the svn too
<shakaran1> I do: bzr push svn+https://forja.rediris.es/svn/cusl4-tivion
<shakaran1> And I get: bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
<shakaran1> the bzr missing show me: Using saved parent location: bzr+ssh://bazaar.launchpad.net/~shakaran/tivion/tivion/
<jelmer> that's a different location
<jelmer> than what you're pushing to
<jelmer> shakaran1, ^
<shakaran1> yeap, Can I do?
<shakaran1> I dont know how to do it
<shakaran1> I want push all my repo on the SVN
<shakaran1> how to do it then?
<jelmer> shakaran1: did you read the information in "bzr help diverged-branches" ?
<shakaran1>  bzr merge
<shakaran1> Merging from remembered submit location bzr+ssh://bazaar.launchpad.net/~shakaran/tivion/tivion/
<shakaran1> Nothing to do.
<jelmer> shakaran1: What does "bzr missing" on the URL you're trying to push to say?
<shakaran1> In this url, I have a SVN repo,  https://forja.rediris.es/svn/cusl4-tivion how to do bzr missing?
<shakaran1> I have to do something with this
<jelmer> "bzr missing https://forja.rediris.es/svn/cusl4-tivion"
<shakaran1> You have 55 extra revision(s):
<shakaran1> I need to do a commit?
<jelmer> shakaran1: You probably want to push to https://forja.rediris.es/svn/cusl4-tivion/trunk
<shakaran1> jelmer: oh perfect! jelmer you save my day!
 * igc lunch + est
<igc> rest
<poolie> spiv, hi - tell me things? :)
<spiv_> Well, I just discovered duelling pppd processes, which probably explains why I dropped off adsl a moment ago :)
<spiv_> I think I found the cause of https://bugs.edge.launchpad.net/bzr/+bug/490600, and just pushed a simple branch for it.
<ubottu> Launchpad bug 490600 in bzr "TypeError: StaticTuple can only point to StaticTuple, str, unicode, int, long, float, bool, or None not <type 'tuple'>" [High,Confirmed]
<spiv_> I'm a bit concerned about https://bugs.edge.launchpad.net/bzr/+bug/489211, but it's going to be hard to track down without a way to reproduce it locally.  Coincidentally it's possibly the same area of code as 490600, but that's just coincidence :)
<ubottu> Launchpad bug 489211 in bzr ""bzr: ERROR: exceptions.AssertionError: second push failed to complete a fetch set" during checkout" [High,Confirmed]
<spiv_> I've spent some time staring at the relevant code hoping to spot the bug by inspection, but I think I'll have to make a patch to add more logging for the reporter to try.
<poolie> mm i thought that was a dupe
<poolie> but apparently not?
<poolie> well, they're seeing it in a release that's supposed to have the other bug fixed
<poolie> as you say
<spiv> poolie: in a release that fixed the other, with a format (2a) that didn't experience the other.
<poolie> spiv, i was wondering a bit this morning if there were UDD things more important than these bugs
<poolie> but i think these bugs are genuinely high
<poolie> so
<poolie> it's not a bad use of time to work on them
<LaserJock> I'm getting bzr: ERROR: KnitPackRepository is not compatible with RemoteRepository different rich-root support when trying to pull from a branch on Launchpad, any thoughts?
<lifeless> the source has upgraded, probably to 2a.
<spiv> LaserJock: you have mismatched formats, upgrade one (or both) sides to 2a.
<LaserJock> spiv: I think I tried that
<spiv> Your local side isn't 2a, judging from that error.
<LaserJock> bzr info gives an "unnamed" branch format on both sides
<spiv> Try info -v
<LaserJock> so yeah, that doesn't sound right
<spiv> What's the URL of the remote branch?
<LaserJock> format 7 locally
<LaserJock> bzr+ssh://bazaar.launchpad.net/~cjwatson/ubuntu-cdimage/mainline/
<spiv> LaserJock: "format 7" is the format of the branch, for this it's the repository format that matters
<spiv> Right, that remote branch is 2a
<spiv> Whereas your local one is probably something like "Packs 6 ..." rather than "Repository format 2a ..." (to use the descriptions info -v will print)
<LaserJock> spiv: "Packs containing knits without subtree support"
<LaserJock> so do I blow away my repo and start over (not a big deal)?
<lifeless> LaserJock: you run 'bzr upgrade'
<LaserJock> I did
<LaserJock> oh, wait
<LaserJock> I ran bzr upgrade on the branch
<LaserJock> gah, how confusing
<spiv> bzr upgrade, if you have bzr 2.0.0 or newer, will upgrade you to 2a.
<LaserJock> ok, running bzr upgrade on the repo dir
<spiv> It should upgrade both the branch and the repo, IIRC, that's a bit odd.
<lifeless> spiv: it upgrades a single bzrdir last I heard
<spiv> Ah.
<spiv> That's a pity.
<LaserJock> is there any cool ways to make a bzr pull from a repo do pulls from all the branches in the repo?
<LaserJock> I'm searching for better alternatives to bzr multi-pull
<bob2> repo-push ;p
<Peng> spiv: It's unintentional that lp:~spiv/bzr/static-tuple-pure-python-bug-490600 is linked to bug #408193, right?
<ubottu> Launchpad bug 408193 in bzr "bzr branch or checkout --hardlink has no effect in 2a format" [Medium,In progress] https://launchpad.net/bugs/408193
<spiv> Peng: d'oh, yes
<spiv> Peng: it's because I copy & pasted the wrong bug number.
 * spiv fixes
<Peng> :)
<zombor> hello, im trying to run svn2bzr on os x, and i get a "ImportError: No module named bzrlib" error, any idea how to fix it? my bzr install works perfectly fine
<Peng> zombor: svn2bzr? Isn't that...really old? Why not bzr-svn?
<zombor> does that export svn repos into a bzr repo?
<Peng> zombor: Yes.
<zombor> i thought that was for commiting to svn with bzr
<Peng> zombor: It's for bidirectional transfers between bzr and svn.
<zombor> yeah, i don't want to do that
<Peng> zombor: You don't have to push back to svn if you don't want to.
<zombor> i want to take my svn repo, and convert it into a bzr repo
<Peng> zombor: So use bzr-svn.
<Peng> Did I link to http://bazaar-vcs.org/BzrForeignBranches/Subversion? I meant to link to it.
<zombor> im looking at that right now
<zombor> hrm, so how do i use this thing...
<spiv> zombor: bzr-svn?  If you just want to convert one branch "bzr branch svn://.../the_branch the_converted_branch"
<zombor> ah ok, it just uses normal svn syntax
<spiv> Right.  http: and svn+ssh etc should all Just Work.
<zombor> hrm, but i just upgraded to bzr 2.0.2 and it broke my bzr command =(
<spiv> Oh?
<zombor> ah, nevermind, i needed a shell refresh -_-
<zombor> got the svn branching, thanks a lot guys
<poolie> getting back into pilotage
<poolie> review queue jumpers welcome
* poolie changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Helping with patches: poolie
<_Andrew> Hi guys
<_Andrew> Is there a way to export any modified or added files between two different revisions ?
<poolie> you want a whole copy of those files?
<poolie> or just the diff?
<_Andrew> whole copy
<poolie> hm
<poolie> not built in
<_Andrew> I know you can bzr export the whole project
<poolie> you could probably script it by reading the output of 'log -v' or 'status -r'
<spiv> or maybe do a "bzr diff -rX..Y | lsdiff" to get the list of changed/added files?
<spiv> Although I suppose status -r does that too.
<spiv> The bzr-upload plugin must calculate something like this too.
<JonCruz> so... any recommended way to find out what has changed on the server before syncing it on down?
<lifeless> there was a bug report about export I think
<lifeless> do do this
<spiv> JonCruz: perhaps rsync or the bzr-upload plugin would work for you?
<JonCruz> with subversion, "svn status -u" would tell me. I wounder if "-v" on "missing" might help
<_Andrew> spiv, thanks i'll check it out
<_Andrew> I'm looking at the manual online but I can't find the command just to get the latest revision with bzr log?
<spiv> -r -1
<_Andrew> ah!
<_Andrew> thaks
<dOxxx> or -l1
<vila>  hi all
<lifeless> hiya
<vila> revno 4842 broke no-extensions-pure-python support, babune is so confused about that it turned all red
<lifeless> vila: https://code.launchpad.net/~spiv/bzr/static-tuple-pure-python-bug-490600/+merge/15470 ?
<vila> wow
<_Andrew> After I start using a plugin and want to install another do I still need the __init__.py file?
<_Andrew> or do I need to merge the two files ?
<vila> lifeless: sounds very likely
<poolie> hi there vila
<poolie> _Andrew: ?
<poolie> you should have ~/.bazaar/plugins/one/__init__.py
<poolie> and then .../two/...
<poolie> etc
<_Andrew> oh really
<_Andrew> woops
<_Andrew> So actually I should put the plugin in it's own folder
<Peng> Or call them ~/.bazaar/plugins/one.py and two.py.
<_Andrew> but what if two plugins both have __init__.py ?
<_Andrew> Surely you can't just rename them?
<Peng> _Andrew: So, what poolie said.
<_Andrew> Thanks
<poolie> _Andrew: they should have folders named eg 'gtk', 'pqm', etc
<_Andrew> It's working now. :)
<vila> _Andrew: then you'll have one/__init__.py instead of one.py and two/__init__.py instead of two.py
<poolie> containing all their files
<poolie> yay
<bialix> hi
<_Andrew> Branch format 6 is old right?
<bialix> _Andrew: not really
<bialix> it's pack-0.92
<_Andrew> Would it be worth upgrading because many people in our office keep complaining it's slow.
<Peng> _Andrew: The only thing branch format 7 gets you is stacking.
<bialix> Peng is right
<_Andrew> Ah, I read that. I don't need that.
<Peng> _Andrew: This is about performance? Then the important part is the _repository_ format. Well, unless you want to use stacking too.
<_Andrew> I think that if it's not going to make any difference upgrading then I'm not going to touch it
<_Andrew> thanks for the help guys
<Peng> _Andrew: Upgrading your repository to 2a would probably make a big difference.
<_Andrew> oh really?
<Peng> _Andrew: Yes. They were able to squeeze much more awesome into it than the previous formats.
<Peng> _Andrew: What's your current repository format?
<_Andrew> format 7 ?
<_Andrew> er
<_Andrew> format 6
<Peng> Eh.
<Peng> _Andrew: What's the first line of "bzr info -v", and what's the "repository:" line?
<_Andrew>  pack-0.92
<_Andrew> knits without subtree support
<_Andrew> We're using bzr for web development
<Peng> _Andrew: Okay. So you should see a big performance (and disk space) improvement if you upgrade to 2a. It requires a very recent version of bzr, and upgrading to a rich-root format like 2a is one-way.
<Peng> I should rephrase that. You'd have to make the rich-root transition, which is one-way.
<_Andrew> We have bzr 2.0.2 installed
<Peng> Perfect.
<Peng> All of you? There's not that one weirdo who's still using 1.5?
<_Andrew> Right now we're all working via ssh off the server
<Peng> Does the server have 2.0.2?
<_Andrew> yup
<_Andrew> How we're setup is that 5 people have all checked out a copy of trunk which they commit and update to
<_Andrew> and we have a branch named "live" for stuff that is ready to be uploaded
<_Andrew> So what I'm wondering is how would I upgrade this so that it doesn't screw everyone up
<Peng> Is bzr really that slow? Is the repo that large?
<_Andrew> We have about 600 meg of content I think
<_Andrew> Most of the time it's ok but some people you can see that it take a good 5+ seconds
<_Andrew> plus my boss keeps using this as a reason to switch to hg
<Peng> What takes 5 seconds? Bazaar isn't always a speed demon; 2a might not help all that much.
<Peng> _Andrew: Anyway, http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html should help.
<_Andrew> I can't remember
<spiv> _Andrew: definitely upgrade to 2a, it may help a little, or it might help a lot.
<bialix> run bzr with cold cache and you get more than 5 seconds only to start
<spiv> bialix: yeah
<bialix> Peng: "werdo" :-P
<spiv> bialix: run *python* with cold cache and you can get that... :/
<bialix> spiv: right now I see PyQt starting is very slow
 * spiv -> food
<_Andrew> So if I upgrade trunk to 2a what happens when others with checked out copies of pack-0.92 try to commit ?
<bialix> _Andrew: this require local upgrade
<_Andrew> or if I pull changes into my live branch
<bialix> or they will get error
<_Andrew> So I need to upgrade trunk then make everyone checkout a new copy
<bialix> that helps
<Peng> _Andrew: The link explains at least some of it.
<_Andrew> oh sorry I didn't see that link
<bialix> _Andrew: are you using light checkouts or heavy one
<_Andrew> looking at it now
<bialix> ?
<_Andrew> Not sure of the difference
<bialix> bzr info tells
<bialix> you need heavy co to get the power of local repo to speedup local operations
<_Andrew> http://pastebin.com/m3a0e491a
<_Andrew> That's the output of bzr info -v
<_Andrew> but I don't see anything about heavy or light
<bialix> just checkout is heavy
<bialix> _Andrew: does you have many binary files?
<_Andrew> i'm not sure of the ratio but probably. Things like videos, images, etc
<bialix> hg is not much faster with binary files as I know
<_Andrew> Yeah, I'm not too sure either but i'd prefer to keep using bzr
<bialix> you can upgrade to 1.9 format, it has non-rich-root variant, but 2a is recommended default today, so...
<_Andrew> I think it won't be too much trouble
<bialix> you have pack-0.92 which is old, 1.9 is better
<_Andrew> Just make sure everyone commits beforehand
<bialix> will be nice to know how much 2a will be faster for you
<Peng> 1.9 isn't all *that* much better, though.
<Peng> Well, it mostly is. Just not compared to 2a.
<_Andrew> Well, I asked the developer who was having the problem and he said every command was slow. I'll let you know when we do the update
<_Andrew> I guess he means bzr up, st, ci etc
<Peng> _Andrew: If he's using a lightweight checkout, using a heavyweight checkout or regular branch would probably be faster, since bzr wouldn't have to contact the network so much.
<lifeless> vila: I think you should land spivs fix, its nearly 8 here
<vila> lifeless: yup, I was just checking pqm
<bialix> Peng: I disagree with you, but have no time to argue
<sjamaan> Hi
<sjamaan> I'm trying to push to an FTP server using "bzr branch . ftp://some-location"
<sjamaan> It seems to hang on "Get stream" for a long time
<sjamaan> Now that disappeared and doesn't seem to do anything
<lifeless> sjamaan: yes, ftp uses append, there is a bug open about switching to PUT, for most of teh data copying.
<lifeless> just be patient.
<lifeless> also, you would normally use 'bzr push ftp://some-location', not 'bzr branch . URL' to do a push.
<sjamaan> lifeless: I'm making an initial branch
<sjamaan> Not pushing to an existing branch
<Peng> sjamaan: You'd still use push for that.
<sjamaan> ic
<sjamaan> Why is that?
<Peng> Why not?
<sjamaan> Because it's a new branch
<sjamaan> Push is for updating
<lifeless> sjamaan: push will make a branch if one doesn't exist.
<Peng> ISTM the bzr way is easier.
<sjamaan> hm, it finished but didn't make a working copy
<Peng> sjamaan: That's correct.
<sjamaan> I only see an option for --no-tree, but not the inverse
<Peng> sjamaan: Why do you want one?
<lifeless> sjamaan: we dont make working copies over non-local-filesystems
<sjamaan> Peng: I want to make a deployment of a website on a shared hosting provider
<sjamaan> I'd like to be able to push updates easily and thought bzr would be ideal for that
<sjamaan> I only have ftp access, no ssh
<Peng> sjamaan: You should SSH to the server and run "bzr checkout" and maybe install the bzr-push-and-update plugin -- ah.
<Peng> sjamaan: Use the bzr-upload plugin.
<sjamaan> heh :)
<sjamaan> thanks for the pointer
<Peng> sjamaan: It doesn't create working trees on remote FSes because it would be tricky to do things like resolve conflicts.
<sjamaan> Ah, of course
<sjamaan> In my case that's not relevant, but I understand the general case is hard to get right
<Rune> which format does bzr upgrade to when I do not specify a format? bzr 2.0.0
<vila> Rune: 2a starting with bzr-2.0
<vila> lifeless: thanks for adding me to c-a-c-o team, but I just wonder if I indeed apply them as I wanted to or if you did that on your own ?
<vila> s/them/there/
<lifeless> vila: see my mail to the list (not sent yet :)) - and the internal wiki page on contributor agreements
<vila> lifeless: come to think of it, I think I didn't find a way to apply, so certainly you did that on your own :)
<jml> how do I get the bound location of a branch?
<lifeless> branch.get_bound_branch(), I think.
<jml> thanks
<vila> lifeless: lol synchronicity/telepathy on so on ;)
<sjamaan> Peng: The upload plugin works fine. Thanks again for the tip!
<Peng> sjamaan: Great. :)
<vila> spiv: I've landed lp:~spiv/bzr/static-tuple-pure-python-bug-490600, it helps reduce the ~4000 errors, but still 2000 are left :-/
<Morbus> g'day. i'm a newb. how does one "set a configuration option"? http://doc.bazaar-vcs.org/plugins/en/email-plugin.html
<beuno>  Morbus it's usually bu adding it to ~/.bazaar/bazaar.conf
<beuno> or if it's for a specific branch, in ~/.bazaar/locations.conf
<beuno> under the branch's entry
<Morbus> beuno: doesn't that make it compulsory on the user though? i want anyone who uses the master to have the commits mailed out, regardless.
<Morbus> in a svn-based environment, this would be editing the post-commit on the master repo itself.
<beuno> Morbus, it does. I know there's a server-side alternative, but I don't know about it
<Morbus> hrm. alright.
<Morbus> i'll poke around some more.
<RenatoSilva> Morbus: .bzr/branch/branch.conf. Using bzr-email?
<Morbus> RenatoSilva: yeah.
<Morbus> so stick the post_commit_to config option in there?
<RenatoSilva> Morbus: I wrote a patch to allow customization of subject and body: https://code.launchpad.net/~renatosilva/bzr-email/mail-customization
<Morbus> i just want to get it to work first, then i'll worry about beautifying it ;)
<RenatoSilva> Morbus: yes, set the options inside the branch, and anyone using it will be affected
<Morbus> so, where does the plugin get installed?
<Morbus> .bzr/branch/plugins? ;)
<Morbus> or do i just install via the setup.py on the master box?
<Morbus> looks like it.
<RenatoSilva> Can we install plugins inside branches? O.o I know of ~/.bazaar/plugins, and <bzr_home>/plugins
<Morbus> yeah, i just checked out, and python setup.py install.
<Morbus> stuck it in /usr/lib/python2.4/site-packages/bzrlib/plugins/email/tests/ for this box.
<Morbus> so, now just to add the config and hopefully i'm dandy.
<RenatoSilva> email/tests? it should not be in a subdir, it should be in email
<Morbus> yeah, it is. i just randomly pasted one of the installation lines.
<Morbus> is there anyway to debug the sending? i just ptu the config in, made a commit from an external checkout, and no mail. whee.
<Morbus> sending mail manually using /usr/bin/mail does work...
<RenatoSilva> how long you've been waiting?
<Morbus> hrm. nope. not working.
<Morbus> i've been checking the mail log after each send.
<Morbus> i've tried /usr/bin/mail, /bin/mail, and smtplib.
<RenatoSilva> smtp server log? see bzr.log
<Morbus> for the value of post_commit_mailer
<Morbus> what should i be looking for in there?
<RenatoSilva> clean bzr.log and do a commit, then check what's outputted there
<Morbus> there are no errors jumping out at me.
<Morbus> nor are there any indications that email was attempted.
<Morbus> (though a bzr help email does display the help text, suggesting that the plugin was installed)
<Morbus> i'm the only one using the repo at the moment, so there's no confusion about what messages relate to what (re, clean bzr log)
<Morbus> should i be seeing activation of the email plugin in there?
<RenatoSilva> Morbus: $bzr plugins, email should be listed
<Morbus> it is.
<Morbus> post_commit_to = devteam@example.com
<Morbus> post_commit_sender = noreply@intra.example.com
<Morbus> post_commit_mailer = smtplib
<Morbus> is in my /path/to/master/branch/.bzr/branch/branch.conf
<Morbus> i've also tried /bin/mail for the mailer, which works when I run "/bin/mail -s whee morbus@disobey.com" etc.
<RenatoSilva> .bzr/branch/branch.conf? where's smtp_server?
<Morbus> just added that to localhost, did a commit, checked mail and bzr.log and no change.
<RenatoSilva> try localhost:25
<Morbus> reading through https://bugs.launchpad.net/bzr-email/+bug/307988 at the moment
<ubottu> Launchpad bug 307988 in bzr-email "Central repository email?" [Undecided,Invalid]
<RenatoSilva> $bzr version?
<Morbus> 2.0.2
<RenatoSilva> os?
<Morbus> centos, also mentioned in the above bug
<Morbus> i am checking out from an external client - a different machine entirely. one of the reports here suggests that it'll work from a checkout on the server itself - i'll test that out shortly.
<RenatoSilva> are you using bzr commit to test it? push/pull notification is disabled by default
<Morbus> yes, using bzr commit, and just added push/pull too.
<Morbus> still nothing. but i haven't tested a server checkout yet.
<RenatoSilva> tried localhost:25?
<Morbus> yes.
<Morbus> and i'm going over bzr+ssh
<RenatoSilva> man, it's like email plugin is not loaded
<RenatoSilva> crazzy
<Morbus> should i be seeing it loaded in the bzr log?
<Morbus> i see:
<Morbus> 0.023  looking for plugins in /home/bzr/.bazaar/plugins
<Morbus> 0.023  looking for plugins in /usr/lib64/python2.4/site-packages/bzrlib/plugins
<Morbus> 0.084  looking for plugins in /usr/lib/python2.4/site-packages/bzrlib/plugins
<Morbus> and email is in one of those dirs.
<Morbus> but it never says "found email!" ;)
<RenatoSilva> Morbus: $bzr plugins, email should be listed, by that I mean run the command 'bzr plugins'
<Morbus> yes, and i did, and it was.
<Morbus> ran that command on the branch server.
<RenatoSilva> try creating a simple branch, for test
<Morbus> and, what, put in the branch.conf again?
<Morbus> RenatoSilva: here's a question.
<Morbus> RenatoSilva: the checkout on machine B was checkedout BEFORE I made the changes to branch.conf on master branch machine A.
<Morbus> does that matter?
<RenatoSilva> I don't know, but I don't think so. Try not using checkout, try using the branch directly
<Morbus> gasp, something worked.
<Morbus> determining what it was.
<RenatoSilva> if doesn't work, try a fresh branch: bzr init test; copy your lines to ./bzr/branch/branch.conf; create a file, bzr add; bzr commit
<bialix> hello again
<Morbus> RenatoSilva: hrm. while i figure out what made it work, is there anywy to get the diff inline instead of as an attached file?
<bialix> I've just had a situation when after merge new code from source branch was not merged to destination branch
<Morbus> RenatoSilva: bah, looks like that's a symtop of using smtplib.
<Morbus> *symptom
<bialix> any core devs around?
 * Morbus goes back to debugging.
<RenatoSilva> Morbus: I don't think so, unless you patch it as I did
 * Morbus nods.
<bialix> oh, nm, PEBKAC
 * bialix bangs head by wall
<RenatoSilva> Morbus: https://bugs.launchpad.net/bzr-email/+bug/399398
<ubottu> Launchpad bug 399398 in launchpad-code "Diff highlighting in mail body" [Undecided,Invalid]
<Morbus> annoying enough, i just made a third ocmmit (the last two got emailed), and so far, no email. heh.
<Morbus> still waiting.
<RenatoSilva> what made it work?
<Morbus> no idea.
<Morbus> the last two changes i added was commit on push/pull and localhost:25. i wanted to comment one out and see if i could figure out the exact culprit.
<Morbus> but, before i did so, i wanted to do one more commit test to ensure it still worked.
<Morbus> and i'm still waiitng for that email to come in ;)
<Morbus> ok. there it is.
<Morbus> took about 8 minutes to get here.
<Morbus> so, with push/pull true and localhost:25, it worked.
<Morbus> i'm now gonna comment out push/pull and try it again ;)
<vila> jam: ping
<Morbus> note to self: 11628 (both enabled), 11629 (no push/pull)
<RenatoSilva> that bug you linked, the suer still had the problem in last comment, so I don't know if it's invalid
<RenatoSilva> s/suer/user
<Morbus> yeah, but he was always using mail.
<Morbus> i've been using smtplib
<Morbus> that's the diff between the two there.
<Morbus> i need the utf8 capability of smtplib.
<RenatoSilva> if you can understand his problem clearly (did he explain it well? I'm not use, I don't use "centralized" model), and if you can *reproduce* the bug, you can change the status from invalid to confirmed
<jam> morning vila
<vila> morning jam !
<RenatoSilva> s/not use/not sure
<Morbus> RenatoSilva: well, i read his use of centralized as the same thing i came in with: i want emailed commits to be in the master branch, not optionable on the client side.
<vila> jam: did you see bug #490600
<ubottu> Launchpad bug 490600 in bzr "TypeError: StaticTuple can only point to StaticTuple, str, unicode, int, long, float, bool, or None not <type 'tuple'>" [High,In progress] https://launchpad.net/bugs/490600
<Morbus> RenatoSilva: ok, so confirmed.
<Morbus> post_commit_push_pull = True
<Morbus> it was that.
<vila> jam: spiv proposed a partial fix, but there are still ~2000 errors (from the ~4000 initial ones :)
<Morbus> 11629, which didn't have that, didn't come through. 11630, with that, DID come through.
<jam> I did, I'm also thinking that spiv's proposal was probably at the wrong layer
<Morbus> now i'll test with and without port :25 ;)
<vila> jam: babune agrees with you, it's still all red :)
<Morbus> 11631 (without 25)
<RenatoSilva> Morbus: comment there too, saying you also have the same problem and mainly why the invalid status is invalid
<Morbus> 11632 (without smtp_server)
<Morbus> RenatoSilva: yep.
<Morbus> i will.
<jam> vila: all red? Or just red on the slave that doesn't compile the extensions?
<siks> what's the proper way to do a init-repo with a unc path? \\server\path and //server/path don't seem to work
<vila> Morbus: are you using host:25 notation, I know some parts of the code can't grok the embedded port and requires specific variables for the port
<Morbus> RenatoSilva: well, at this point, post_comit_push_pull seems required, even though the docs suggest that it isn't. so i'm not sure it IS invalid.
<Morbus> vila: i'm testing with and without at the moment.
<vila> jam: all slaves run without extensions, so they are all red :)
<jam> vila: really? that seems foolish
<jam> given that our preferred way of running is with extensions...
<RenatoSilva> Morbus: try answer the first comment that was the one arguing it was invalid
<vila> jam: which one should you  chose to run without extensions ? What guarantee will that give you ?
<Morbus> RenatoSilva: yeah, without an explanation of what he consideres "appropriate", it's a bit hard ;)
<RenatoSilva> Morbus: I'm not sure it is invalid because the user is not satisfied in the last comment, so something's wrong
<Morbus> ok, the smtp_server value had nothing to do with it.
<vila> jam: anyway running lots of combinations *is* foolish, that's why we use a bot :D
<Morbus> i tested with localhost:25, localhost, and no smtp_server at all, and all messages came through.
<bialix> siks: is there any error you get?
<Morbus> so it's definitely the push/pull config.
<Morbus> that was the clincher for em.
<RenatoSilva> Morbus: I'm not sure I can get all that info well as I don't use checkouts/centralized model/mail program. I think you can get it better
<Morbus> *me.
<RenatoSilva> Morbus: you have to convince Robert Collins it it not invalid, just because he's the developer :P
<Morbus> aye ;)
<Morbus> how would i set it back to status confirmed?
<Morbus> i got not widgets.
<Morbus> *no widgets.
<Morbus> ah, way at the top there.
<siks> bialix: [Error 58] The specified server cannot perform the requested operation: u'//127.0.0.1/temp/bzr'
<Morbus> anyways.
<bialix> siks: do you have permissions rights?
<jam> vila: I would run 1 bot per platform with extensions. One bot on one platform w/o extensions. One bot on one platform for 3 major python versions (with extensions). That is N platforms + 1 + 3 bots. Not 3*N or 3*N*2 bots, etc.
<siks> bialix: i do
<RenatoSilva> Morbus: either way, if the bug is really invalid, it would be nice if that user and you created an answer for people having the same syntoms. That is, provide detailed context of what you were doing, and the resulting problem: no email, no error. Then provide what is the root cause of that. All this of course, if you find that root cause (ps: maybe what's causing your problem is not causing that user's, so there may be need for two q/a, try contacting him
<Morbus> he's sub'd to the bug, and so am I, so hopefully he'll see it. i certainly will, if he updates.
<bialix> siks: I have slightly different error: bzr: ERROR: No such file: u'//127.0.0.1/temp/bzr/': [Error 53] The network path was not found: u'//127.0.0.1/temp/bzr/'
<vila> jam: yeah, I thought so too for some time, and then I started getting weird failures and I came to the conclusion that trying to be smart is not the point. The not point is to avoid regressions, and you never know *where* the regression will come from. That's why we test.
<vila> s/not point/point/
<bialix> siks: it seems like a bug for me
<siks> bialix: i get that with //127.0.0.1/temp/bzr and the error i showed with \\server
<bialix> siks: I'm sure it worked in the past when I wrote UNC support
<siks> i'm investigating bzr because i really want a new version control system for the company i work for
<siks> really tired of freevcs
 * bialix said on core devs with disapprobation
<vila> jam: there will always be cases like: oh, look, python2.6.2 has a bug but not python-2.6.4 and Fedora will use 2.6.2 as part of its LTS policy, etc
<bialix> siks: as workaround you can assign your UNC path to some letter
<bialix> and file a bug!
<siks> the thing is, we need a central server (which of course is np), and a somewhat central place for the projects
<vila> jam: and that's without mentioning pqm not running py2.4 anymore...
<siks> freevcs has a hierarchy but i don't see a problem why our core bazaar rep can't be a net dir
<bialix> siks: oh, no
<bialix> siks: wait
<jam> vila: mthaddon just changed pqm over to python2.4 as of.. yesterday I believe
<bialix> it works for me with real remote machine
<siks> strange
<bialix> siks: does not work with 127.0.0.1
 * bialix trying with localhost
<bialix> ok, I got error if the path not found, but I can't reproduce your case
<vila> jam: good to know :) But the point is still valid: whatever assumption *I* will make, I will forget some cases and be doomed when the failure is revealed :) So as long as it's a bot running the tests, the more the merrier !
<bialix> siks: with localhost and real existing path I have another error:
<bialix> C:\>bzr init-repo \\localhost\share\bzr
<bialix> bzr: ERROR: No such file: u'//localhost/share/bzr/': [Error 52] You were not connected because a duplicate name exists on the ne
<bialix> twork. Go to System in Control Panel to change the computer name and try again: u'//localhost/share/bzr/'
<bialix> siks: works for me with 127.0.0.1 and real shared folder
<jam> vila: except you also are a big proponent of test isolation
<jam> having 20 bots fail because of one bug
<bialix> you may want to look into .bzr.log and see if there something suspicious about error 58
<jam> doesn't give us defect localization :)
<bialix> siks: do you need password to connect your server?
<siks> nope
<bialix> maybe if you pastebin the relevant part of .bzr.log I may suggest something
<siks> it's not that big a problem anyway, i was just trying out if unc works at all. if we end up using it, it'll be a proper remote host anyway
<vila> jam: you got that wrong I'm afraid, defect localization is about having more failures not less, especially with eager tests where the first failure masks the other ones
<siks> and i can test it locally without unc
<bialix> siks: just a thought: we are trying to make .bzr folder hidden after creation
<jam> vila: if the only bot to fail was the one running without extensions, then it is clear that the bug is when running without extensions
<vila> it's about making tests more focused with more precise contexts
<jam> having 20 bots go red doesn't tell you that
<bialix> siks: perhaps your server refuse to change file attributes?
<jam> it gives you 20 test files to go sift through to see what is wrong
<vila> jam: it's 6 not 20 and it tells me it's it's about running without extensions. *I* read the first report and that's enough to know the cause, I don't need to read the other ones
<bialix> siks: so either mkdir on the server does not work, or something other
<jam> vila: it is 6 because you don't *have* 20 bots...
<bialix> siks: but I see it works for me
<jam> I was using it as "BIG_NUM"
<vila> But if the failure were only on one slave *then* by virtue of defect localization, we'll know it's related to that slave and not only to running without extensions
<Morbus> can i edit a commnt on launchpad? i forgot to sanitze some emails.
<bialix> Morbus: uncommit, commit, push --overwrite
<Morbus> bialix: no, in a comment on a bug, not in a commit ;)
<vila> If we run it on a single slave and it doesn't fail, *we* lose
<bialix> Morbus: you can edit first message, but I don't know the way for other comments
<siks> bialix: hm i guess i'll investigate a little more tomorrow
<siks> running out of works hours soon for today :)
<bialix> siks: np
<Peng> Even if you edit the first message, anyone can click a link and see the first one.
<Peng> Plus a dozen people probably got emailed a copy...
<bialix> today is not my day
<jam> Morbus: also, note that for users that aren't logged in, all things that look like emails are sanitized
<chrisw> hmm, why does Bazaar Explorer on windwos drop a dos box? Why isn't pythonw used instead of python?
<jam> chrisw: it requires a bit of change to how the script is built, and just hasn't been done yet
<jam> I tried working on it once, and ran into problems with py2exe + pyqt + python2.6
<jam> so I couldn't get the build working locally
<chrisw> I also tried to click the "config" button and it crashed...
<jam> vila: so do you run a second time with extensions?
<vila> jam: first with extensions, second with C locale, third without extensions
<chx> how can i edit the subject line of the commit email? maybe a plugin? what should i rtfm?
<bialix> anybody can suggest a way to compress bzr revision-id to hexascii form, and make sure the string will be smaller at least in half?
<bialix> is it possible in theory?
<bialix> I'm using revision id in version of the program (bzr version-info output) and it looks long
<bialix> so I think if I can compress it and later decomress
<tumbleweed> howdy. can anyone give me some good reasons why I should upgrade my projects trunk to 2a instead of 1.6? (1.6 because it makes stacked branches possible)
<jam> bialix: zlib.compress(revision_id) ?
<bialix> jam: if I have 53 chars in orig revid, then zlib makes result 61 chars long
<bialix> in hexascii I'll have 122
<bialix> jam: maybe your groupcompress?
<jam> bialix: there is a fair amount of non-randomness in revision-ids. If you compress them together it will probably shrink, but there is little that could be done for a single string
<bialix> tumbleweed: 1.9
<jam> tumbleweed: 2a is generally significantly smaller on disk than 1.6. Depends on the project
<jam> but bzr went from 200MB => 35MB, etc.
<bialix> maybe I need to reformat timestamp
<tumbleweed> bialix: there's no FAQ on this, what's the major improvement in 1.9?
<jam> tumbleweed: 1.9 introduced btree indices
<jam> but I would still recommend 2a first
<jam> only  reason not to is if you expect people to be using old bzr clients
<tumbleweed> jam: yeah, I'm feeling the pull to 2a, but we don't have a massive code base
<tumbleweed> yes, don't want to make life hard for committers
<bialix> jam: maybe it's possible to do as plugin
<bialix> hmmm
<jam> bialix: possible to compress revision ids? I'm saying that the string is not very compressible
<bialix> :-/
<jam> if you want to include version-info output, the best you could probably do is to map revision-ids to simple integers, and then reference them that way
<jam> then at least you don't end up with the same revision-id multiple times
<bialix> and how I can found from simple integer the real revision id? by creating the map again? so it's basically as sha(revid) to get the index?
<jam> bialix: you store the map in the output
<bialix> no, I can't
<bialix> I've got this program version from customer
<bialix> in this case I need anyway full revid
<jam> bialix: you were saying that the revid is "too big" and wanted to compress it. You could compress the whole output of 'bzr version-info' which would give a smaller total content.
<jam> There isn't a trivial way to shrink a 53-byte string that has as much entropy that revids have
<bialix> ok,  understand
<bialix> I may imagine the way to shrink it based on semantic: email-timestamp-random
<bialix> but this semantic not always will be true
<bialix> it seems when I merge 2 branches which have tag conflicts I don't get any error message. Is it intended?
<lugo> hi
<lugo> i'm having trouble with https://bugs.launchpad.net/bzr/+bug/156462
<Noldorin> hello. what's the best way to interface with bzr if i want to extra information about certain commits/revision/files/etc. ?
<ubottu> Launchpad bug 156462 in bzr ""cannot lock LockDir" on update over http" [Undecided,Invalid]
<NfNitLoop> Noldorin: bzr log -v ?
<NfNitLoop> Noldorin: what sort of extra info?
<lugo> since latest entries in that bug have been posted some time ago, has anyone workaround for that?
<lugo> or informations on how to update using bzr+ssh instead of http? the cmdline output is http://dpaste.org/NwPm/
<Noldorin> NfNitLoop: the sort of info loggerhead extracts
<lugo> *information ;)
<Noldorin> i've been tempted to cobble together something in asp.net that is vaguely equivalent
<beuno> Noldorin, using python is probably the best way  ;)
<beuno> or
<Noldorin> beuno: mm, so i suspected
<bialix> lugo: what tells bzr info on your local checkout?
<beuno> bzr-xmloutput
<Noldorin> does bzr expose some sort of api though?
<Noldorin> ah, interesting
<beuno> Noldorin, yes, it has a python API
<beuno> you can use xmloutput to get XML, but you may need to tweak it to get extra information
<Noldorin> bueno: if i had ironpython on the server, then it would be win. alas, i don't
<Noldorin> i see
<beuno> right
<beuno> verterok built xmloutput to interface with java, and I piled up on top of it for PHP  ;)
<Noldorin> so in theory, interfacing it with asp.net shouldn't be a problem either
<Noldorin> beuno: what did you write in php on top of it?
<beuno> Noldorin, I did xml > mysql
<beuno> and then used that data in an internal workflow software
<beuno> (match commits to projects and people)
<beuno> to some extent, that's what Launchpad does, but without the xml bit
<Noldorin> ah i see
<Noldorin> beuno: well i'm just using this for webbzr accesss, so i don't really forsee a performance issue here
<Noldorin> i think i'll give that a go
<Noldorin> thanks :)
<lugo> bialix, http://dpaste.com/127539/ , checkout of branch: http://bazaar.launchpad.net/%7Eexaile-devel/exaile/exaile-0.3.x/
<beuno> Noldorin, good luck!
<beuno> (and maybe verterok will some day get xmloutput in the core!)
<Noldorin> cheers. i'll report back if i have any success :P
<bialix> lugo: based on the comments in that bug you need to "fix" your master branch url.
<bialix> lugo: open .bzr/branch/branch.conf and find bound_location entry; change %7E to ~
<bialix> save and try again
<lugo> bialix, oh i read tha part but i seem to have misunderstood it, it's working now thank you :)
<bialix> please add the comment to the bug
<bialix> so other people will understand the workaround
<lugo> done
<bialix> thx
<vila> jam: well done, only 22 left \o/
<jam> vila: can you point me to the remaining failures?
<vila> jam: http://paste.ubuntu.com/332463/
<vila> jam: safely ignoring the spurious error: Socket is closed, this heavily points to the smart server serialize/deserializer not supporting StaticTuple ?
<jam> vila: right
 * vila EODing
<vila> g'night all, may the force be with jam ;)
<jml> I wrote this script today that almost does something useful: http://paste.ubuntu.com/332474/
<jml> vila, g'night.
<fullermd> Whew, vila's gone.  Now it's safe to come out.
<james_w> anyone know if it's possible to just have loggerhead serve a directory listing?
<james_w> It's serving all the branches below a directory, but I just want to allow it to access something that's not a branch as well
<beuno> james_w, not currently supported, no
<james_w> ok, thanks
<beuno> my gut feeling is that it shouldn't be tto hard
<beuno> *too
<james_w> I'll find another way around it
<james_w> I just wanted a quick hack to avoid troubling IS
<emmajane> james_w, have you tried just throwing a .htaccess file into the dir?
<emmajane> (with an allow directive)
<james_w> so, I've placed the directory I want to serve under .bzr
<james_w> because apache doesn't then proxy that to loggerhead
<james_w> now I've got a permissions issue
<emmajane> http://viralpatel.net/blogs/2009/03/htaccess-directory-listing-enable-disable-allow-deny-prevent-htaccess-directory-listing.html <---- try that?
<james_w> because it won't follow the symlink out of its tree I think
<emmajane> .htaccess containing: IndexOptions +FancyIndexing
<emmajane> (they may have an allowoverride set to None, but it's worth a shot if that's all you're trying to do)
<james_w> and the main one has                AllowOverride None
<emmajane> grr
 * emmajane shakes her fist
<emmajane> nevermind then. :(
<james_w> so I have http://package-import.ubuntu.com/failures/.bzr/
<james_w> but you can't see the symlink there
<emmajane> which shows no content?
<emmajane> yeah
<emmajane> what are the permissions on the target of the symlink?
<NfNitLoop> and is your web server set to follow symlinks?
<emmajane> I had problems with something similar on DreamHost. It wouldn't do Bazaar properly when symlinked outside of the root directory. I couldn't be bothered to figure out if it was Apache or Bazaar though.
<saedelaere> hi
<saedelaere> i have a question to bzr-cia plugin. somehow when my changelist is long not all changes are posted to my irc channel. anyone seen the same behaviour?
<ckontros> Can anyone tell me what I'm missing here? (the bzr ERROR) http://paste.ubuntu.com/332619 (fresh Inkscape compile from BZR) I'm wondering if I stumbled across an issue for them or just user error.
<jelmer> saedelaere, bzr-cia only submits on new commits
<saedelaere> sure jelmer, i make a commit. this commit has a long changelist. then not all changes are posted to my irc channel. they get cut off at some point.
<saedelaere> by the way you are the creator of this plugin right?
<saedelaere> nice work!
<jelmer> saedelaere, what do you mean with changes ? the commit message?
<jelmer> saedelaere, thanks
<saedelaere> yes the commit message
<jelmer> saedelaere, bzr-cia submits the full commit message
<jelmer> the cutting off is done somewhere inside of the cia IRC bot
<saedelaere> ah ok interesting. i just looked in my cia.cv account, but couldn't find anything to configure this. perhaps it is even a limitation of my irc channel.
<NfNitLoop> IRC does limit the size of a single message.
<NfNitLoop> as well as rate-limit messages.
<NfNitLoop> so it could be getting chopped down the line.
<saedelaere> this must be the source of the problem. anyone an idea how i could circumvent this?
<NfNitLoop>  I don't know bzr-cia.  Is there a way to set a max message length and tell it to split long commit messages into multiple IRC messages?
<NfNitLoop> That could get annoying though if someone commits something with a huge message.
<NfNitLoop> bzr commit -m `cat war_and_peace.txt`
<jelmer> NfNitLoop, it doesn't have anything to do with bzr-cia
<jelmer> saedelaere: You might want to ask in #cia
<saedelaere> jelmer: you are right better to ask there :) thanks for your help guys and have a nice evening all...
<NfNitLoop> Oh.  I didn't realize what cia was.  I thought bzr-cia included its own bot.  heh.  Nevermind. :)
<poolie> hi all
<jam>  hi poolie
<dOxxx> heya
<dOxxx> is it safe to use os.makedirs to make the .bzrmeta dir?
<jam> dOxxx: since it is only a single directory, what is wrong with 'os.mkdir' ?
<jam> but since it is in a working tree, yes it is generally safe
<jam> though I believe makedirs raises an exception if the dir exists
<jam> so you still have to check first
<dOxxx> jam: yeah, I was intending to do that
<dOxxx> I noticed there isn't any other mention of .bzrmeta in trunk. Am I pioneer? :P
<spiv> Good morning.
<starenka> hi, i can't get bzr stable docs in chm (wanna read them on android - pdf viewers suck bigtime) - links are dead, directory listing havent revealed anything either, any chance gettingthem?
<dOxxx> jam: or should I be using tree.mkdir instead?
<jam> starenka: http://doc.bazaar-vcs.org/bzr.2.0.2/downloads/ ?
<jam> or http://doc.bazaar-vcs.org/bzr.2.1.0b2/downloads/
<starenka> oh, ok http://doc.bazaar-vcs.org/latest/downloads/ linked from website are bad than (at least for chm)
<starenka> jam thank you!
<poolie> hello jam
<poolie> jam/lifeless: what is ben's actual objection to launchpad? that we should create an faq?
<poolie> i mean, that i feel like we should create an faq
<poolie> i think it's just that remembering another password would be annoying?
<jelmer> poolie, yeah, that's it basically - and another account to keep up to date
<dOxxx> perhaps he doesn't like giving out personal info?
<Peng> CoughOpenIDCough. :P
<jelmer> dOxxx, there isn't much personal info you have to give out
<dOxxx> just trying to get inside his head :)
<lifeless> poolie: what objection ?
<lifeless> poolie: oh, he has a principled stand.
<poolie> but it's an oddly pragmatic principle to defend
<poolie> i'm just trying to work out what the principle is and I think it is "i don't want to create another account"
<lifeless> hes expressed it before as 'just emailing should be enough' too
<lifeless> he likes debbugs, for instance.
<dOxxx> while an email interface is cool, it is somewhat crude.
<lifeless> lamson + html email with javascript.
<lifeless> ajax-over-email.
<lifeless> would be an interesting hack.
<dOxxx> heh
<fullermd> A matter of perspective...   it's a cheap universal API.  I broke down and cried the day NSI stopped supporting their email interface for registration manglement  :|
<jelmer> is there some way to disable the write-traceback-to-file stuff ?
<dOxxx> this .bzrmeta/ignore thing is trickier than it looks. a lot of stuff is broken by the extra directory in the path.
<dOxxx> makes tests messier
<fullermd> I must say, in this day and age I'm a little creeped out by email control interfaces that don't require crypto.
<jelmer> debbugs seems to be doing (mostly) ok without crypto
<dOxxx> doesn't launchpad though? I thought that's why you could set your PGP key in your launchpad account?
<rockstar> fullermd, the Launchpad interface does if you want to change something.
<fullermd> Yah, but that requires either luck (e.g., in the form of being 'not an interesting target'), or a lot of monitoring vigilence.
<fullermd> To say nothing of the ability to speel...
<Peng> My favorites are the ones where you can make changes that actually cost money over email.
<fullermd> Of course, that also ties in with my creepy feeling seeing patches to add TLS to bzr://.
<Peng> Or those domain registrars/registries where you can change your nameservers.
<dOxxx> would it be cheating if, in bt.test_ignores.TestTreeIgnores.test_add_to_existing if I used tree_ignores_add_patterns to create the initial contents of the ignore file before using tree_ignores_add_patterns again to test adding to an existing file?
<fullermd> Shouldn't have to be patches.  Any protocol written since 2000 should be encrypted by default from the get-go...
<Peng> fullermd: I'm glad the bzr developers don't have to worry about getting encryption right, though.
<fullermd> Except DNS, of course, 'cuz if I have to see one more DNSSEC argument, I'm going to have to kill somebody.
<fullermd> (which of course means I'll probably be indicted by the end of the week, but still...)
<spiv> fullermd: perhaps we just need a smart server mode that verifies gpg signatures on revisions (and checking the gpg keys are from an authorised set) before inserting them ;)
<fullermd> Well, you'd have to go the other way too; smart servers are used for pulling as well as pushing.
<fullermd> I just figure the question should never be "why crypto"; it should be "why not crpyto", and absent a really compelling reason it should just be the default posture.
<Peng> spiv: That feature already exists; it just doesn't work/.
<dOxxx> does this make your skin crawl? http://pastebin.com/m240ae4e7
<dOxxx> in a test
<dOxxx> as opposed to this: http://pastebin.com/d53952ce2
<dOxxx> I'm trying to decide if being abstract about the ignore filename/path is worth the extra hassle.
<spiv> dOxxx: I prefer the latter in this case
<spiv> dOxxx: because the abstraction actually makes it harder to understand the intent
<dOxxx> yeah and to be truly abstract about the path to the ignore file, I'd have to handle the case where there are multiple missing parent directories, which is just insane.
<dOxxx> time for a global search and replace :P
<dOxxx> I need bzr qshelve :)
#bzr 2009-12-02
<lifeless> poolie: have you read transition (iain banks)
<poolie> maybe, is that the new one?
<domas> hi! does bzr support shallow clones?
<chx> domas: sorry, what do you mean?
<chx> domas: also if i got the chance to talk to you, are you now working on Cassandra?
<domas> I'm working on MySQL
<chx> At Facebook? Interesting development :)
<domas> why?
<domas> facebook is mysql shop, isn't it? :)
<chx> well, they released cassandra didnt they :)
<domas> you missed http://www.facebook.com/MySQLatFacebook?ref=nf  ? :)
<chx> yes i did
<chx> anyways, let me answer to my best knowledge -- bzr does not support that but i am a humble bzr user not a developer. afaik bzr works with complete trees always.
<domas> hehe
<chx> or what you really mean by shallow clone?
<domas> yeah, I don't want to know everything about every revision ten years ago
<Peng> Use a stacked branch?
<domas> works locally
<domas> not remotely :)
<chx> use checkout?
<chx> checkout --lightweight?
<domas> it won't be a branch then! ;-)
<chx> you can commit --local :)
<domas> hm! ;-)
<chx> not to lightweight.
<lifeless> domas: we don't support offline shallow clones
<chx> but normal co , yea
<lifeless> domas: we do support online shallow clones - thats a stacked branch. However we don't support committing directly to those yet.
<domas> chx: anyway, to answer properly your question, fb is very much mysql shop, Mark Callaghan started to work few months ago, I joined recently too
<chx> great
<poolie> kfogel: hi, thanks for following up about the contributor agreement
<poolie> all, please take a few stabs at https://answers.edge.launchpad.net/bzr/+questions?field.sort=recently+updated+first&field.actions.search=Search&field.status=Open&field.search_text=
<mwhudson> i think stephen turnbull has managed to find a way to make his network connections travel faster than light...
<Peng> mwhudson: ?
<mwhudson> Peng: claiming that ssh vs not only makes a difference between 5 and 15 ms
<lifeless> 15 light milliseconds
<lifeless> 4486 kilometres, I think
<mwhudson> lifeless: that's about what i came out with
<idnar> hahaha
<Peng> Heh.
<Peng> If you use a master SSH connection, you don't have to reconnect every time.
<Peng> I do that when I'm busy with LP. I figure it'd be rude to keep a connection open 24/7, though.
<lifeless> Peng: its still not long enough to send to the uk and back.
<lifeless> units\n15 light milli seconds\n kilometres
<Peng> I know. I was just sayin'.
<mwhudson> Peng: right
<mwhudson> Peng: keeping an sftp connection open is fine
<Peng> Oh? What's the difference?
<lifeless> and idle master connection is just a tcp socket
<lifeless> more-or-less
<Peng> Oh, really? I would've assumed there was an sshd on the remote side.
<Peng> sshd process*
<lifeless> if we ran sshd
<Peng> lifeless: Oh. Right.
<Peng> So, it's OK to leave a connection open? :D
<lifeless> if mwhudson says so
<mwhudson> well if everyone did it life might get a bit interesting
<mwhudson> but yes, it should be fine
<_Andrew> Anyone here used bzr upload?
<_Andrew> https://launchpad.net/bzr-upload
<lifeless> many people I think
<AfC> If I'd like to use bzr-git, where might I best get it from? It doesn't seem to be in https://launchpad.net/~bzr/+archive/ppa
<Peng> Oh, looks like I opened a connection 7 hours ago and forgot. :D
<Peng> poolie: I'd prefer a lawnmower shed. :D
<poolie> lifeless: i guess discussing which of them is best is not bad
<poolie> but ... random measurements of latency don't seem very correlated with that
<lifeless> EOD
<ovnicraft> hi folks, if i branch a lp:project and make my changes after this i push in other branch, that maintain the stack branch default?
<Peng> ovnicraft: ....Yes?
<Peng> ovnicraft: Pushing to LP will automatically stack on the project's development focus branch.
<ovnicraft> Peng, so the project what i branch has 53MB but pushing after my 2KB changes continue pushing in 70MB, this is for stack?
<Peng> What?
 * lifeless guesses a transcoding issue.
<AfC> I'm so sorry to be dense, but am I missing anything on https://launchpad.net/bzr-git which would tell someone who knows better where to get a .deb of it from?
<vila> hi all
<Kamping_Kaiser> AfC: its packaged in debian(unstable/testing)/derivatives, if you want a newer version you might need to backport yourself.
<AfC> Kamping_Kaiser: ah
<AfC> Kamping_Kaiser: alright, thanks.
<Kamping_Kaiser> AfC: np... if you find a backport for debian stable let me know ;)
<AfC> That's the second time today I've hit "seems like it's time to learn how to add Debian repositories to my /etc/apt/sources.list & pinning with /etc/apt/preferences"
<Kamping_Kaiser> hehe. advice: add the repos to sources.list.d/foo.list
<AfC> Still; it doesn't seem unreasonable to wonder if we might get bzr-git & dulwich into the ~bzr/ppa
<lifeless> AfC: useful commands to know, #432, 'rmadison bzr-git' and 'rmadison -u debian bzr-git'
<AfC> Not sure what might inhibit that.
<poolie> afc, for ubuntu or for debian?
<lifeless> AfC: also apt-cache policy bzr-git
<AfC> poolie: Karmic
<poolie> presumably for ubuntu
<AfC> rmadison?
<lifeless> AfC: 0.4.1-1 is the version in Debian, and in ubuntu:
<poolie> sounds even more like something pornographic
<lifeless>    bzr-git |    0.4.1-1 | karmic/universe | source, all
<poolie> anyhow, good night
<lifeless>    bzr-git |    0.4.1-1 |      unstable | source, all
<lifeless> poolie: :P remote madison
<poolie> :)
<poolie> i did guess actualyl
<AfC> lifeless: jeesh! so it is.
<AfC> Not sure how I missed that. Whatever I searched on didn't turn it up.
<AfC> Oh, well, I looked at the bzr PPA page, since that's where I get Bazaar from, and so the absence of bzr-git there threw me.
<AfC> lifeless: so; _would_ it be appropriate for newer releases of bzr-git & dulwich to be in ~bzr/ppa?
<vila> AfC: yes
 * vila disclaims: I may not be the one doing it :)
<AfC> vila: sure
 * AfC gets that
<vila> AfC: But I was as surprised as you to not find it in https://launchpad.net/~bzr/+archive/ppa
<bialix> hi
<donri> are branches directories like in svn or histories like in git?
<bialix> they are like in bzr
 * chx grins
<chx> donri: yes a branch is a directory but unlike in svn it's one unit you can't checkout a subdir or commit it.
<chx> donri: and that's a GOOD thing. One of the reasons I love bzr.
<donri> uhm. i can't stand thingsl like /project/trunk :/
<bob2> so don't name them that way
<bialix> donri: every branch in bzr is like separate clone in git
<donri> sounds expensive
<bialix> hello vila, have a minute?
<bialix> donri: yeah, and we have rich-roots in addition
<bob2> directories cost up to 4KB of disk
<vila> bialix: ask your question :)
<bialix> so bzr is for rich people. perhaps
<vila> bialix: and hi !
<bialix> vila: about real gui testing in qbzr
<bialix> maybe it's good idea to check some env variable and skip those tests?
<bialix> e.g. QBZR_DISABLE_GUI_TEST
<bialix> or something like that? what do you think?
<donri> a git clone holds complete history, usually quite more than 4kb
<bialix> donri: yep, bzr too
<chx> last i checked, disk space, for all practical usages was free. (youtube videos are not practical :p)
<bialix> donri, but you can cheat and use shared repo
<donri> so if i want a topic branch, i have to copy the whole project?
<bob2> donri: of course not
<vila> bialix: That's a good workaround if you can't find a better way, at least on unix, DISPLAY should be set if you want to be able to display anything, I guess it doesn't matter on windows
<vila> bialix: what is your motivation ?
<bialix> vila: yep, it does not matter on windows, I wanna cross-platform way
<vila> to check what ?
<vila> that a display is available ?
<bialix> vila: I'll add more of such tests, trying to figure out how's better layout our tests
<donri> so if i want a topic branch, i have to keep a directory both for the source branch and the new branch? i quite like the cleanliness of gits "one directory, use commands like checkout to change state"
<bialix> no, I'm just want a useful knob to disable them sometimes for speed reasons
<vila> a test feature, then you can decide how probe() should behave
<bob2> donri: what's your interest in bzr?
<bialix> donri: look http://oxygene.sk/lukas/2009/10/working-with-branches-in-bazaar/
<vila> donri: first you have to understand the difference between a branch and a working tree, in both bzr and git branches are cheap, but in bzr the default workflow creates a working tree for each branch. If you don't want that behavior you have to work a bit more
<bialix> vila: another possibility is to separate gui and non-gui tests to different subpackages and control with selftest regexp
<vila> I don't use git, but I'm pretty sure you have several working trees by working a bit more too
<vila> bialix: that's up to you, but using a test feature will offer greater flexibility
<bialix> vila: does knob via env variable is good candidate for feature?
<bialix> vila: I understand what you mean about $DISPLAY
<bialix> but this is slightly different use case
<vila> anything that can be checked by python code is a good candidate, the sky is the limit ! :) What is the qbzr basic sanity check before displaying any window ?
<bialix> vila: mmm? only presence of pyqt4 I guess
<vila> bialix: hmm, so what happens if I try to run qlog on an headless PC ?
<bialix> headless?
<bialix> what's that beast
<vila> with no screen, a server for example
<bialix> oh, I have no idea
<bialix> perhaps it will eat your kitty
<vila> lol
<vila> ok, that's exactly the missing check :)
<bialix> I suspect qt is smart enough to check this itself
<vila> ...and raise an appropriate error, that's the error you want to check
<vila> bzr-gtk does that in __init__.py.opend_display()
 * bialix checks
<bialix> vila: do you have headless server to check?
<smartgpx> Greetings. I have a documentation 'sanity check' question. Could someone glance at http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/publishing_a_branch.html
<vila> no, the best I can do is to unset DISPLAY I presume, let me checl
<vila> bzr: cannot connect to X server is what I get
<smartgpx> In 'example of the Second Way' I think the final push is typographically wrong (should be PROJECT u/c) and redundant?
<vila> 'bzr: cannot connect to X server' is what I get
<bialix> can you pastebin traceback?
<vila> bialix: no traceback
<bialix> even in .bzr.log?
<vila> even in .bzr.log
 * bialix mutters: interesting bzr-gtk is not support 1.18, but does support 2.1, funny
<bialix> vila: cannoct connect to X server is different from bzr-gtk check ("could not open display")
<bialix> (I know I'm boring and overly pedantic)
<vila> bialix: what makes you think 1.18 is not supported ?
<bialix> there is explicit list of supported versions
<vila> and the errors are different because is not qt maybe ? :-D
<bialix> after 1.17 there is 2.1
<vila> bialix: no, there is a list of supported bzrlib APIs
<bialix> the variable called COMPATIBLE_BZR_VERSIONS
<bialix> not COMPATIBLE_BZR_API
<bialix> (the same remark about bialix boring)
<bialix> ignore me
<vila> bialix: read the next line, what matters is how the variable is used :)
<bialix> thanks vila, I will try to do something about qbzr test suite soon
<vila> bialix: but if you have a patch to clarify gtk sources, it will be welcome :-D
<vila> BIG FLASHING RED JOKE, this code lies anyway, like all plugins only the latests bzr versions are supported, devs are just too lazy to maintain an accurate list :)
<bialix> :-D
<bialix> that's why we don't have such list
<smartgpx> Greetings. I have a documentation 'sanity check' question. Could someone glance at http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/publishing_a_branch.html
<smartgpx> In 'example of the Second Way' I think the final push is typographically wrong (should be PROJECT u/c) and redundant?
<bialix> smartgpx: you're right
<bialix> push is wrong there, because in 2nd case it's checkout
<bialix> smartgpx: I think you're welcome to https://launchpad.net/~bzr-doc
<smartgpx> thanks. still sufficiently 'newbie' to be uncertain, but it seemed to conflict with the explanation in the next sentence.
<smartgpx> I'll look at patching it. (a one-line deletion)
<bialix> copy-paste error I guess
<smartgpx> Yes, except that the case 0f the PROJECT dir changed. no matter, we know what to do.
<bialix> all this cp -ar stuff is not very windows friendly, so I'm just ignore it
<smartgpx> bialix: so, are you working on that doc then? Agree with your comments about cp, but I can see it's difficult to make cli examples os-neutral
<bialix> smartgpx: no, I'm working on qbzr
<bialix> I'm not native English man, so working on English docs is not for me
<bialix> this was just "sigh" comment
<smartgpx> to save me a long Branch operation, is the source in lp:bzr ? (or lp:bzr-alldocs ?)
<smartgpx> OK - brain in gear, I can browse LP to find out before I Branch them! no reply needed.
<ibboT> I'm trying to do a bzr pull from my launchpad project, but it only gets a small way in the "pull phase" and then hangs
<ibboT> hmm it's finally completed after 10 mins
<_Andrew> Anyone know off the top of their heads where I install plugins on ubuntu to make them system wide
<_Andrew> /usr/share/pyshared/bzrlib/plugins ?
<beaumonta> thanks vila for the merge... but didn't you already provide an alternative solution? (i'm talking about my bzr-upload branch)
<vila> beaumonta: I think it was built on top of yours (or at least on top of your idea). I was just cleaning up the merge proposals queue and thought 'merged' was the closest status for yours
<vila> _Andrew: 'bzr plugins -v' should give your pointers
<beaumonta> vila: I see, so it's not a real code merge, ok, thanks for your consideration!
<vila> beaumonta: thanks for your contribution, without you the option would still be waiting to be implemented :-D
<beaumonta> vila: yup :)
<LeoNerd> Should I expect sshfs to get in the way of bzr at all? I have a local SVN checkout, and "bzr st" works fine on it using bzr-svn. I have an sshfs mount of a remote machine having checked out the same thing. That throws a wobbly about: bzr: ERROR: exceptions.TypeError: expected a character buffer object
<LeoNerd> Ahh.. It seems sshfs isn't the problem.. I can sshfs mount localhost in some crazy loopback setup, and bzr-svn works fine over that. I suspect maybe bzr-svn is confused by the remote checkout
<LeoNerd> And.. yes.. if I make my local desktop 'svn co' it again, then bzr is happy with it. I think I blame the remote svn
<jelmer> LeoNerd, can you paste a backtrace?
<LeoNerd> http://paste.leonerd.org.uk/?show=698
<jelmer> LeoNerd, hmm, that's odd - I didn't know repos could be None
<LeoNerd> Mmm?
<jelmer> can you add a line before that assertion in workingtree.py?
<jelmer> print self.entry.repos
<jelmer> I suspect that will print None
<LeoNerd> None indeed
<maxb> If 'repos' is repository root url gleaned from the subversion working copy, then it will be because ancient svn versions didn't record that information
<vila> bialix: ping
<vila> bialix: I'd like your input about win32utils.get_console_size(), there is a comment there about avoiding problem with redirecting output via pipe and using stderr instead. But what if stderr is redirected too ?
<bialix> vila: heya!
<bialix> vila: if stderr is also redirected then we fallback to default value
<bialix> I can test for you
<bialix> it was long time ago
<vila> oh, because the GetConsoleScreenBufferInfo fail ?
<bialix> what's your real question?
<vila> :-)
<bialix> IIRC -- yes
 * bialix looks at the code
<vila> We want to change the default width to None instead of 80 when we can't establish the terminal width
<vila> bah, don't worry, I can just pass None as the default value, no need to modify that function...
<bialix> cool :-D
<bialix> always happy to help
<bialix> :-D
<vila> thanks for being my teddy bear :)
<vila> i.e. the one listening to my baby cries :)
<bialix> never had teddy bear
<vila> I had a rabbit myself :)
<bialix> but one nice girl once upon ago call me "bear"
<bialix> despite my appearance
<bialix> :-D
<jam> morning all
<vila> morning jam !
<chx> morning ham! :p
<bialix> hi jam
<jam> morning chy
<jam> and vila and bialix
<vila> vilb and bialy ?
<vila> bialiy, sorry for the typo :D
<jam> well he was the only one to typo
<kfogel> jelmer: have you seen https://lists.ubuntu.com/archives/bazaar/2009q4/064932.html?  Apparently Norbert Tretkowski has uploaded a bzr 2.0.2 lenny backport to http://people.debian.org/~nobse/temp/bzr/.  He said he was going to upload it to backports.org, but I don't see it at http://packages.debian.org/lenny-backports/bzr.  Is this something you can do?  (It would help us for the Emacs switchover.)
<jelmer> kfogel: I am able to upload, but we should probably check with him
<kfogel> jelmer: I don't know him, and his email address doesn't appear to be in that mail, but do you know how to contact him?  I can try to track him down if not.
<jelmer> kfogel, his email address is nobse at debian.org
<jelmer> he is also here on IRC as nobse
<jelmer> If you haven't asked him about the backports yet, I'm happy to talk to him
<kfogel> jelmer: I haven't talked to him about it yet.  If you can coordinate with him, that'd be great.  As soon as it's on backports, we'll ask the savannah.gnu.org admins to install it, and there's some built-in delay there already (as they're volunteers).
<pickscrape> Hi, is anyone able to help me with a bundlebuggy (or possibly rio-related) problem?
<pickscrape> We've been using BB just fine for months. Today it is broken, in a very odd way.
<pickscrape> We are getting the following backtrace when viewing a merge request: http://pastebin.com/m85d2194
<pickscrape> Now, the request list pages currently work, but they didn't before I rejected the three requests that were submitted this morning. They also failed with similar backtraces.
<pickscrape> The only thing I can think of is that last night I did a merge with the upstream BB trunk. But all that did was bring in the lastest revision "Merge references fix"
<pickscrape> I have since reverted that change, but we still have a broken BB.
<pickscrape> bzr version on the server is 2.0.1
<pickscrape> Python 2.5.4
<jelmer> kfogel: I've pinged him in private but he doesn't appear to be around at the moment
<jelmer> kfogel: I'll try to remember to ask him about it again in the next few days
<kfogel> jelmer: thanks
<jelmer> kfogel: the package is already uploaded but waiting for manual approval because it introduces a new binary package - nobse is doing that now, so I suspect the package should be on backports.org in a day or so
<RenatoSilva> verterok: hi
<jelmer> kfogel, s/day/hour/
<kfogel> jelmer: excellent!  Thank you.  I'll keep checking.
<dOxxx> if I have an unversioned subdirectory containing unversioned files, in a branch working tree, 'bzr ls' should or should not list the unversioned files in the unversioned subdirectory?
<hazmat> is there a magic switch to enable post mortem debugging in bzr?
<jelmer> hazmat: set BZR_PDB=1 (as environment variable)
<jelmer> LeoNerd, any chance you can try again with bzr-svn trunk?
<hazmat> jelmer, thx
<LeoNerd> jelmer: Hmm... if I work out how to install that, rather than just using the debian package...
<jelmer> LeoNerd, bzr branch lp:bzr-svn ~/.bazaar/plugins/svn
<LeoNerd> OK.. it fails in a different way :)
<LeoNerd> TypeError: object of type 'NoneType' has no len()  at    File "/home/paul/.bazaar/plugins/svn/tree.py", line 385, in find_ids      relpath = urllib.unquote(entry.url[len(entry.repos):].strip("/"))
<jelmer> LeoNerd, please pull and try again
<jelmer> I've committed a fix for that particular issue
<LeoNerd> No revisions to pull.
<maxb> I would like to discover the history of discussions into URL formats for addressing colocated branches. Can anyone point me in the right direction?
<jelmer> LeoNerd, sorry, please try again
<jelmer> maxb, have you tried searching the mailing list archives for "colocated branches" ?
<jelmer> maxb: Also, see doc/developers/colocated-branches.txt
<jelmer> contains a link to the discussion on the list
<maxb> aha, thanks. lists.ubuntu.com isn't searchable, unfortunately
<LeoNerd> jelmer: OK... 'bzr st' now works.. :) claims my working tree is out of date, so I bzr up, which... segfaults. :)
<LeoNerd> But.. no great problem; I can svn up on the remote end... I mainly wanted bzr for the shelve ability
<jelmer> LeoNerd: probably a similar issue where we rely on .repos being non-None
<jelmer> or, in the C code - non-NULL
<LeoNerd> Yah..
<LeoNerd> It's possibly not that important to fix... the version of svn that created this checkout is quite old
<LeoNerd> svn, version 1.1.4 (r13838)   compiled May 10 2005, 13:50:02    it claims
<jelmer> LeoNerd, It would still be nice to fix - if you are familiar with gdb, any chance you can get a backtrace?
<LeoNerd> Hrm.... gdb claims /usr/bin/bzr is not an executable file format
<LeoNerd> Ahh.. do I have to  gdb python ?
<LeoNerd> Hrm.... I have a backtrace, but it's mostly Python internals...
<jelmer> that might still be helpful
<LeoNerd> http://paste.leonerd.org.uk/?show=699
<jelmer> ah, it's unfortunate you don't have debugging symbols for subvertpy
<LeoNerd> Hrm.. no debug package appears in debian
<beuno> abentley, hi, are you around?   do you have any insight on: http://paste.ubuntu.com/333305/
<dOxxx> beuno: looks like bug 273978
<ubottu> Launchpad bug 273978 in bzr "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978
<dOxxx> buuuut maybe not
<dOxxx> I remember seeing that error before though
<abentley> beuno: I haven't looked at that yet.
<beuno> dOxxx, I think that this bug may be in bzrtools instead of bzr
<dOxxx> beuno: gotcha.
<abentley> beuno: it looks like bug 352006
<ubottu> Launchpad bug 352006 in bzrtools ""bzr branch-history | more" fails with UnicodeEncodeError" [Undecided,New] https://launchpad.net/bugs/352006
<beuno> abentley, it does, thanks. the Emacs guys are hitting this bug
<abentley> beuno: I'm surprised, because even I don't use that command anymore.
<beuno> abentley, I don't even use emacs  :)
<beuno> I have no idea why they're using it
<abentley> beuno: I've never even shopped at a bazaar :-)
<beuno> heh, touche
<amanica> I'm having difficulty to branch from launchpad ATM eg. `bzr branch lp:bzr-explorer`  .  Is it just me ?
<LeoNerd> I've just managed to   bzr log10  it
<amanica> mm.. `bzr log lp:bzr-explorer` also fails for me:
<amanica> bzr: ERROR: exceptions.NotImplementedError: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented
<amanica> might be hiding the real error :(
<amanica> could log https://code.launchpad.net/~bzr-explorer-dev/bzr-explorer/trunk now.  i think for some reason lp:bzr-explorer resolved wrongly
<amanica> (or I just cant access it over bzr+ssh for some reason)
<dOxxx> jam: awesome! I only get 1 failure and 2 errors running the full selftest on win32 :)
<rubbs> Ben Finney wrote on the mailing list that he created a patch that removed trailing whitespace from the doc folder. He couldn't contribute because he hadn't signed the contributor agreement.
<rubbs> I created a branch that did the same thing
<rubbs> Is it even worth trying to get it merged in?
<rubbs> I mostly did it as an exersize to learn sed
<dOxxx> propose it, see what happens :)
<rubbs> dOxx: ok, I'll try it out.
<dOxxx> you know how to handle the merge proposal stuff?
<rubbs> yeah
<dOxxx> cool
<rubbs> I've gotten a few in before, but didn't know if this was even worth it.
<dOxxx> clean docs are good, imo :)
<rubbs> but I guess your point made sense... only one way to find out.
<rubbs> good point
<dOxxx> you separated the whitespace change from the VCS vs RCS change right?
<jam> dOxxx: what failures? I just ran once and didn't get any failures
<dOxxx> jam: http://pastebin.com/d5c922b00
<jam> dOxxx: so the 'diff' failure is because you don't have a diff.exe on your machine
<jam> cPickle.load is strange
<dOxxx> jam: I have some of the gnuwin32 stuff installed, I can install the diff too.
<jam> the ssh one, I also don't quite understand
<dOxxx> jam: installed gnuwin32 diff and bb.test_diff passes now
<jam> do you know what version of python you are running?
<jam> I'm wondering if you don't have the right lsprof libs installed
<dOxxx> jam: 2.6.4 ActiveState ActivePython
<dOxxx> 32-bit
<dOxxx> running on vista64 though
<dOxxx> where would I find the lsprof libs?
<jam> hmm.. I wonder if activpython versus stock python...
<jam> well, I would first run the test directly, to make sure it still fails
<dOxxx> I don't see lsprof in python\libs
<dOxxx> trying
<jam> lsprof became cProfile and started being bundled with python stdlib
<dOxxx> test_lsprof passed...
<jam> so, it seems like a spurious/race condition
<jam> possibly the output code isn't flushing?
<dOxxx> yeah
<rubbs> dOxxx: yes
<dOxxx> the ssh test still fails when run on its own though
<dOxxx> rubbs: go for it :)
<rubbs> dOxxx: cool thanks
<dOxxx> jam: selftest is sometimes hanging in test_breakin on win32
<jam> dOxxx: are you on a single cpu machine?
<dOxxx> jam: core i7, looks like 8 CPUs
<dOxxx> jam: using r4852 of bzr.dev
<lifeless> dOxxx: its 4 real, with hyperthreading
<dOxxx> lifeless: yes
<lifeless> jam: does gc in win32 python run threaded or something?
<dOxxx> s/looks like/appears to OS as/
<lifeless> :)
<dOxxx> I just pushed my first draft of .bzrmeta/ignore to lp:~doxxx/bzr/bzrmeta-ignore
<dOxxx> no backwards compatibility yet
<poolie> good morning
<dOxxx> hey poolie
<jam> lifeless: I don't think gc is threaded, but if you have del SFTPFile, it calls "CMD_CLOSE" in async mode
<jam> and *that* may not finish before the next command
<jam> however, I'm also seeing self.write_stream.close(); transport.rename() fail
<jam> and that is calling .close() synchronously
<lifeless> dOxxx: what does that branch change?
<dOxxx> lifeless: it changes all handling of .bzrignore to use .bzrmeta/ignore instead
<lifeless> that seems likely to cause headaches for folk on older versions; is it really worth changing?
<dOxxx> lifeless: it's speculative and I'm using it as an opportunity to learn more about the internals.
<lifeless> have you considered having .bzr/meta/ignore be a symlink to ../.bzrignore?
<dOxxx> lifeless: that would work in the absence of backwards compatibility as the branch currently stands
<asabil> side question, why .bzrmeta/ and not .bzr/meta ?
<dOxxx> because .bzr is not versioned
<lifeless> dOxxx: I'm not concerned about backwards compatability, rather forwards compatability.
<dOxxx> the ignore file must be versioned
<asabil> ah I see, ok thanks
<dOxxx> lifeless: could you describe a scenario?
<lifeless> dOxxx: user installs karmic. bzr branches, runs make, runs bzr st sees a tonne of files.
<lifeless> dOxxx: many users do not run recent releases - they are commonly 18 months behind
<dOxxx> lifeless: hmm...
<lifeless> dOxxx: versioned data structures are very very sticky
<poolie> doxxx: i think you need to read either of them
<poolie> (phone)
<lifeless> whether they are casually defined or more complexly defined
<lifeless> I don't have good answers for dealing with change to them, and that caused a lot of friction with tree filters
<dOxxx> so the ignore file handling should read and update .bzrignore if it finds it, otherwise create/read/update .bzrmeta/ignore?
<dOxxx> to be honest, I don't know how serious this whole .bzrmeta thing is
<lifeless> .bzrmeta is a place for plugins that /dont care/ about doing a really elegant job - somewhere where bzr core can just punt, and its up to the plugin authors to do well.
<lifeless> don't care is maybe harsh.
<lifeless> What I mean is, they want something simple, with known behaviours that we can offer all plugins.
<dOxxx> brb
<dOxxx> back
<dOxxx> so why would ian clatworthy want .bzrignore to migrate to .bzrmeta?
<dOxxx> or was it nmb?
<dOxxx> "For a present solution to the  versioned metadata situation, Bazaar core devs decided (?) to go with  files under the .bzrmeta directory.Â  This is certainly preferable to  .bzrignore, .bzrexternal, .bzrautomirror, .bzremail, ... all in the  project'sÂ  top level directory."
<lifeless> so, .bzrmeta is a new facility
<lifeless> that new versioned-as-files metadata can be put into
<dOxxx> so it would seem
<lifeless> and authors of existing versioned-as-files metadata can choose whether to migrate into it or not.
<dOxxx> yes
<lifeless> Theres a lot of history using .bzrignore, and tools that know about it; personally, I'd hesitate to migrate .bzrignore - seems high likelyhood of disturbing something, and low return.
<dOxxx> lifeless: yeah. it's been an interesting excursion though. :)
<apm12> In my repo history i have a commit in past (not last commint) which i want uncommit. So i want something like "bzr revert-past r1231" and get in my HEAD new commit (or just apply to WC) that destroy modifications of code done in r1231. Is it possible? Which plugin or command i can use for this?
<lifeless> apm12: bzr merge -r1231..1230 .
<apm12> thanks!
<dOxxx> how are symlinks treated when branching onto a win32 filesystem?
<lifeless> they are elided and the metadata kept in dirstate
<dOxxx> so the file represented by the symlink is not created?
<dOxxx> i.e. if there is a symlink from .bzrignore to .bzrmeta/ignore then it wouldn't be created?
<dOxxx> and .bzrignore would not exist in the working tree?
<lifeless> thats right
<dOxxx> bleh
<dOxxx> does ordering matter in .bzrignore?
<lifeless> no, we | the rules together.
<jam> lifeless, dOxxx: We crash when there are symlinks and we try to checkout
<jam> we don't silently elide them
<dOxxx> yikes
<jam> we *do* handle that for executable
<lifeless> oh, mea culpa
<lifeless> its X bit we do that fo ... beat me
<jam> well, I should say we don't exactly crash
<jam> we get to the point of creating one, see that we can't, and rollback the checkout
<dOxxx> oh ok
<lifeless> jam: you've seen the remote-submit for pqm-submit?
<jam> lifeless: I have, but I don't prefer it
<jam> I prefer to see what I'm submitting
<lifeless> hmm
<jam> especially since there is a race condition
<lifeless> if it showed a diff?
<jam> perhaps
<jam> however, when we have 20 doc updates
<jam> it is still nice to only wait for pqm 1 time :)
<lifeless> yes, I merge them together too :)
<jam> also, it gives me a chance to try "bzr merge ../bzr.dev"
<jam> and make sure there isn't a trivial conflict that needs to be sorted out
<jam> especial wrt NEWS
<jam> anyway, I'm off for tonight, have a good evening
<lifeless> gnight
<dOxxx> cheers jam
<dOxxx> lifeless: I updated my bzrmeta-ignore branch with backwards compatibility for .bzrignore
<dOxxx> still not sure how to handle forwards compatibility
<pickscrape> What's the easiest way to force bzr to use the python implementation of rio?
<lifeless> rm bzrlib/*.so
<lifeless> :P
<pickscrape> cool, thanks :)
<pickscrape> I'm having a problem with bundle buggy. It's trying to decode a merge directive and is complaining that something is not a "plain string"
<pickscrape> lifeless: is it safe to delete just _rio_pyx.so, or would others need to be removed too?
<lifeless> its safe to delete just the one
<pickscrape> cool.
<lifeless> however
<lifeless> sounds like you have a unicode string, but rio is a byte serialiser/deserialiser
<lifeless> so you should have an ascii string
<pickscrape> Yes, the python implementation complains about the same thing (though with a slightly different backtrace)
<pickscrape> I have absolutely no idea where this has come from. BB has been working fine for us for months, and then yesterday I restart it and suddenly all hell breaks loose :)
<pickscrape> The only clue that I have, is that if I reject all merge requests received since the restart, the merge request lists work, but viewing a request still doesn't.
<lifeless> have you upgraded any system stuff, such as python, or django or whatever it is that bb is built on?
<lifeless> or perhaps your sqlite dbapi etc?
<pickscrape> We're running on postgres, which has been stable since the last restart. It's turbogears-driven.
<pickscrape> I have upgraded sqlalchemy, and I've had to make one other compatibility fix to BB in order to support it. I suppose my biggest suspect is some other sqlalchemy incompatibility issues that I'll have to dig into tomorrow.
<pickscrape> The version that BB is writte for is gone from gentoo's portage though :(
<pickscrape> Is BB basically a dead project these days?
<pickscrape> I proposed a small branch for merging ages ago which just fixed a string escaping issue, and it hasn't been picked up.
<pickscrape> At this point I'm seriously considering trying to install launchpad and use that for both hosting and reviews :)
<pickscrape> Anyway, I need to go. Thanks for your help lifeless :)
#bzr 2009-12-03
<lifeless> pickscrape: I'm not aware of any BB maintainers, no.
<kfogel> lifeless: can I pick your brains for a sec about bzr+ssh and hooks?  about 5 min
<lifeless> kfogel: no.
<lifeless> kfogel: you can read my reply to beuc, then come and pick my brains after that.
<kfogel> lifeless: I did.
<lifeless> ok cool
<kfogel> lifeless: oh, wait -- you mean in the last half hour or so?
<lifeless> 120 seconds ago
<kfogel> lifeless: I was writing a reply, then wanted to confirm something... heh
<kfogel> lifeless: cool
<kfogel> lifeless: you may have made my whole reply unnecessary.  I'll go read now.
<lifeless> kfogel: bzr-hookless-email is totally different, btw.
<kfogel> lifeless: I know (I'm well-acquainted with it, and have a patch in it actually).  I think it is what Stefan is using for commit emails, but am not positive.
<kfogel> I'm pretty sure we're *not* using bzr-email.
<lifeless> well, you can't, until bzr-ssh is enabled.
<lifeless> at which point you probably should :P
<kfogel> lifeless: actually, I like Stefan's solution much better, because then mods to our commit email system do not have to block on savannah admins!
<lifeless> kfogel: I don't see the connection, but I don't care either.
<lifeless> whatever you like is what you should get
<kfogel> (my description of how bzr-hookless-email works to Sylvain is a bit too shorthand; unfortunately savannah tracker doesn't allow comment editing either :-(  )
<lifeless> neither does lp.
<lifeless> wikis they are not
<igc> morning
<a7p> hi everyone - is there a way to generate a revisionnumber into a file? I want it to get printed out each time the program is started.
<a7p> so the user can see which revision he is running.
<bob2> bzr version-info
<dOxxx_afk> http://bazaar-vcs.org/KeywordExpansion
<a7p> dOxxx: exactly what I'm looking for, thx
<phoenixz> I did a bzr tag --force.. ever since, every push and pull I get "conflicting tags: blah"... how can I fix this?
<spiv> push --overwrite
<spiv> Or pull --overwrite
<spiv> Depending on which tags you want to keep and which you want to overwrite :)
<jamesh> lifeless: the patch on the "disable pymalloc" bug does have a configure switch to enable it.  The issue about the tuple cache is certainly something that would be a useful extension, but the patch is useful on its own
<lifeless> jamesh: cool. I'm chatting to gutworth about it
<gutworth> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<gutworth> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<gutworth> ?
<gutworth> ah, launchpad is down
<lifeless> yes :(
<lifeless> we're doing a db schema change amongst other things
<lifeless> and zope is blowing up
<lifeless> I'm told we're rolling back and it will be back very soon
 * gutworth is so glad he's not in charge of administering large websites
<lifeless> somehow encodings.utf_8.codecs became None
<lifeless> not during vm shutdown either
<gutworth> that happens in our tests all the time, too
<lifeless> does it? thats very interesting
<lifeless> does anyone have any idea /how/ ?
<gutworth> you should ask __ap__ when he's up
<gutworth> I think he fixed it
<a7p> mmm ... ~/.bazaar/rules is written, but $Date$ does not get replaced upon a commit - do I miss something concerning keywords?
<lifeless>  shall
<a7p> selftest ran fine.
<gutworth> we're very proud of __ap__. This is his handywork http://python.org/dev/buildbot/stable/
<gutworth> lifeless: http://bugs.python.org/issue6551
<lifeless> thanks!
<a7p> is there any way to check if the rules file is applied?
<spiv> a7p: it should be if your working tree is in a new enough format, IIRC.
<a7p> *sigh*
<spiv> a7p: (2a, the default format in 2.0.0, is new enough)
<lifeless> a7p: what bzr version do you have?
<lifeless> a7p: what does 'bzr info' report for you?
<spiv> a7p: I don't think there's a command to find out what filters are active or applied to a particular file, although maybe there should be.
<a7p> pack-0.92 - I'm running 1.18
<spiv> 'bzr upgrade --1.14' would work for you I think.
<gutworth> yep you need a later version
<spiv> (Although I'd recommend upgrading to bzr 2.0.0 and using the current format when you can, as it is faster and smaller.)
<a7p> thx, - thanks I'll try that ... just have 1.18 installed since it's the default in macports
<poolie> mwhudson: the bugs attached to lp:ubiquity seem to imply we need to think a bit more about the user model too
<a7p> *sigh* - still does not work.
<poolie> a7p: what specifically is not working?
<poolie> you're not seeing the file being filtered?
<poolie> there were several bugs in 1.18 with filters not been applied enough
<poolie> sorry, but that's how it was
<poolie> several are fixed in 2.0.x
<a7p> poolie: i've just upgraded to 2.0.2
<a7p> http://paste.ubuntu.com/333592/
<a7p> rules is configured to [name *] keywords = on
<poolie> % bzr plugins
<a7p> to my understanding $Date$ should get the current date added upon commit
<a7p> git, hg, keywords, launchpad, net_credential_store, svn, xmloutput
<spiv> a7p: I think you can also do 'rm foo; bzr revert foo' to regenerate a file with the current filters.
<poolie> yes it'd be good to see if that  works
<a7p> ah, I should run the selftest with 2.0.2
<poolie> selftest is quite an internally-facing test
<poolie> it probably won't find anything related to bad installation
<a7p> okay - theres' something messed up - was fine with 1.18
<a7p> I'll remove the other plugins
<spiv> selftest is mainly a tool for developers rather than users
<poolie> james_w: i guess you're asleep?
<james_w> hi poolie
<james_w> guess again :-)
<poolie> hi
<poolie> blame canada? :)
<poolie> anyhow
<poolie> regarding the udd stuff
 * a7p is confused - just removed most plugins from ~/.bazaar/plugins, but they still appear upon bzr plugins
<poolie> james_w: i realize there is more to do than the two items i raised and the ones vincent added
<a7p> ah, sry, my wrong
<spiv> a7p: 'bzr plugins -v'
<poolie> i should have made it more clear that i'm just trying to work out what specifically to do in the medium term
<spiv> (that shows you where they seem to be installed)
<poolie> to get from a longish set of stories to what we do this week and next week
<james_w> poolie: yeah, I think I may have phrased my mail badly
<poolie> it happens :)
<a7p> ahhh ... *g*
<james_w> I felt I was missing a step, I saw "here's a bunch of things we could work on," then "here's what we are going to work on," and didn't feel I knew how the two were joined
<poolie> oh
<james_w> I appreciate I wasn't at the sprint
<a7p> $Date: (evaluation error) $  - it's a big step forward ;)
<poolie> well, it was kind of a straw man for you to object to
<poolie> if you were to file say 3 high priority bugs tagged udd we'd probably just do them
<poolie> i don't know if you feel ready or able to do that
<spiv> a7p: heh
<poolie> but we do need to cross that somehow
<james_w> poolie: I'm currently writing my second spec, which should distill out some of the other things that we would like
<james_w> I think it would be good to see how that tallies with the list that you had, and see what changed at UDS
<james_w> I'm concious of time passing, but the spec will be done tonight, and I'll fire off a mail to udd before bed
<james_w> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-distributed-development is one
<poolie> that's ok
<poolie> we have useful stuff to do
<poolie> i'm writing a mail about this at the moment
<james_w> see "Migration" for one set of things that I'm not entirely sure about
<poolie> i just feel a bit like the bzr team is doing business as usual on bzr
<james_w> yeah
<poolie> when we should be reorienting a bit more towards udd
<mwhudson> poolie: yeah
<a7p> grrr, I'm giving up for now - got to write some code for money.
<a7p> thanks for your help
<a7p> puh, just switched from bzr+ssh to sftp to avoid having to upgrade the servers bzr.
<james_w> poolie: do you think one mail with all the issues I want to discuss to udd is the best thing
<james_w> or start a thread per-issue?
 * Kamping_Kaiser shakes his head at bzr. 3 step upgrade is a bit silly
<james_w> ooh, thanks mwhudson
<mwhudson> james_w: i hope you're not in bristol
<james_w> nope :-)
<maxb> Is there any UI for "make this repository as small as possible", or must I manually rm the contents of obsolete_packs to achieve this?
<mwhudson> james_w: good
<mwhudson> james_w: and you're talking about the AttributeError thing?
<james_w> yeah
<james_w> though I like the cleanups anyway :-)
<mwhudson> james_w: ah, np :)
<bob2> maxb: it'll clear it out on the next pull or commit
<mwhudson> i was impressed there wasn't more flakes
<james_w> I use vim-pyflakes now
<poolie> maxb: there's a bug for an option to pack to rm them
<poolie> um
<lifeless> maxb: not really, why?
<poolie> james_w: whatever you think best
<Peng> bob2: No, it'll clear out on the next pack.
<Peng> (including auto-packs)
<bob2> oh
<maxb> It just feels like a UI wart
<maxb> and rm-ing things inside .bzr is scary-ish
<Peng> maxb: But...why would you want to?
<bob2> Peng: it can take up significant amounts of space
<lifeless> only if you run 'bzr pack' :)
<bob2> (I thought the next operation that altered the repo data cleared obsolete_packs)
<lifeless> generally it will be ~ 1% of the repo
<lifeless> bob2: the next that /deletes/ from the repo
<lifeless> packing involves deleting pack files
<maxb> james_w: I would like to do something about the copy-pasted code from "bzr import" (bzrtools) to "bzr import-dsc" (bzr-builddeb). I see two options: A) Push the changes into bzrtools, and depend on a *really* new bzrtools, or B) Separate out the code into a .py file which is deliberately maintained to be as close as possible to the bzrtools version, but sever the actual dependency. What do you think?
<james_w> maxb: I'd like to push the changes to bzrtools, so at least we could depend on it after a dwell period
<james_w> and because it's the right thing to do :-)
<james_w> I just haven't previously had time to separate out the changes and propose them back, sorry
<maxb> james_w: Do you think option B might make sense in the interim, to make it easier to see what we still need to push back?
<james_w> maxb: I would have no problem with doing that
<maxb> I'll do a MP
<dOxxx> good night all
<mwhudson> james_w: have you seen https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports ?
<james_w> I've heard about it
<james_w> haven't ever felt the need to use it though
<mwhudson> hm, i should merge trunk into it again it seems
<mwhudson> instead i'm going to go and see spamalot though :)
<james_w> enjoy
<poolie> spiv, hi?
<poolie> quick call?
<spiv> poolie: sure
<james_w> good night
<vila> hi all
<vila> james_w: wow, where are you ? Or should I say when ?
<RAOF> There's currently no way to embed a branch within a branch, is there (ie: foo/ being a branch, and branching bar into foo/bar)?
<Peng> RAOF: Well, bzr won't mind if you put "bar" in "foo", but they won't be linked together in any way like svn:external.
 * igc dinner
<bialix> hello
 * fullermd waves at bialix.
 * bialix warmly waves back
 * bialix hopes he learn this "waves" phrases correctly
<fullermd> Well, except for the 'warmly' part.  This time of year, I don't believe anything around you is warm   :p
<bialix> even if you in the building?
<vila> bialix: hey !
<bialix> heya vila!!!
<vila> fullermd: ha ha ! You didn't escape quickly enough today !
<bialix> got my mail?
<bialix> fullermd: vila: LOL
<vila> which one ? :) I just replied to the selftest related one
<bialix> about extra libs
<vila> not yet
<fullermd> Eep!  I mean, I'm not fullermd.  I just broke into his house, and am using his keyboard.  Yeah.  That's it.
<bialix> wanna chat?
<vila> I filed a bug about it this morning, let me find that back, but yes, a quick chat will be welcome, we can always update the bug with a summary of it
<bialix> link to a bug please?
<vila> fullermd: right, so get out of that house, quick ! You don't know what the guy will do if he finds you!!!!
<vila> fullermd: he's known to be a freaking lunatic, member of the NRA and very active there !
<vila> fullermd: and that's without mentioning his remotely controlled webcam, man, you're so already dead....
<fullermd> Webcam?!  Ack!
 * fullermd puts on pants real quick.
<vila> bialix: bug #491797
<ubottu> Launchpad bug 491797 in bzr-windows-installers "Allows bzr.exe to take additional plugins (and their required libraries) into account" [Undecided,New] https://launchpad.net/bugs/491797
<bialix> vila: just this morning I've thought about standard location for extra libs
<bialix> maybe bzr needs to use something like PythonXY/site-packages
<vila> bialix: aaah, execellent, I was afraid some technical reason was escaping me making it impossible !
<bialix> inside C:\Program Files\Bazaar
<vila> yup, exactly my thoughts
<vila> may be I expressed it too poorly in the bug report ?
<bialix> there will be several difficulties IMO, but nothing really critical
<vila> It's kind of related to that BZR_PLUGIN_PATH discussion we had some weeks ago
<bialix> sorry, I don't remember
<bialix> last 2 months I was overloaded on my job
<vila> plugins can be searched into 'core', 'user', 'site', I seem to remember 'site' didn't make sense for you in the bzr.exe context
<bialix> vila: perhaps
<bialix> what is user there?
<bialix> core means inside bzrlib/plugins/ ?
<bialix> I don't remember what is site
<bialix> silly me, forget everything :-(
<vila> 'core' is bzrlib/plugins, 'user' is ~/.bazaar/plugins and 'site' is ... well site-dependent obviously but that's the place where plugins are installed when you want all users to be able to access them
<vila> bialix: I think you forget it because you have no use for it yourself :)
<bialix> yep, I'm happy with BZR_PLUGIN_PATH
<bialix> for bzr.exe there is no use for core then
<bialix> because bzrlib/plugins resides inside library.zip
<bialix> I've explicilty extracted launchpad plugin from there
<bialix> so now 'site' for bzr.exe is C:\PF\Bazaar\plugins
<bialix> PF == Program Files (too much to type)
<bialix> and user in APPDATA\bazaar\2.0\plugins
<vila> hmm, great, so can you add c:\PF\Bazaar\lib to sys.path ?
<bialix> never really likes this 2.0
<bialix> it was not very good from jam side
<vila> and similarly APPDATA\bazaar\2.0\lib ?
<bialix> PF\Bazaar\lib should not be added
<vila> why ?
<bialix> because there all our standard c-extension lives
<bialix> wait a sec
<vila> so you mean it's already there and doesn't need to be added ?
<bialix> vila: here is PF\Bazaar
<bialix> http://pastebin.com/d6d2dc13c
<vila> what's in lib ?
<bialix> here is lib: http://pastebin.com/d2d2ef24d
<bialix> scary
<bialix> yes, lib is used for bundled libs for bzr.exe
<bialix> there is lib\library.zip where all python-only libs stored
<bialix> and too much of other c-extensions and dlls
<vila> excellent ! That's exactly where we *could* add more libs, except it will be far cleaner to have another one in sys.path
<bialix> I've explicitly move those libs from PF\Bazaar to PF\Bazaar\lib
<bialix> vila: we should not use lib
<bialix> it's for standard things
<vila> Yeah, so what ? If I want to kill my install who will forbid that ? :-) Kidding, that's why I say we should add one more
<vila> So APPDATA\bazaar\2.0\lib sounds perfect no ?
<vila> Ha no, that's 'user', where would be 'site' then ?
<vila> bialix: anyway, we are indeed back to that discussion, the needed concepts are 'core', 'user' and 'site' otherwise we're running into cycles
<vila> 'core' is protected (that's your arguments about putting nothing more there), so you have to provide 'site'
<vila> That could be PF\Bazaar\site-lib
<vila> or PF\Bazaar\site\{lib,plugins}
<vila> bialix: still there ?
<bialix> vila: bbiab
<vila> bialix: ok, no worries
<vila> fullermd: how can I use tmfs on freeBSD (i.e. in memory file system for /tmp) ?
<vila> fullermd: looks like I need to add that to the kernel ?
<vila> fullermd: I hardly believe it's not there by default >-/
<fullermd> Or load it as a module, I guess.  I've never actually used it myself.
<fullermd> I just use a md-backed regular FS for mine.
<vila> that's what I want: /tmp in memory, whatever the mean !
<vila> fullermd: how do you do that ?
<fullermd> See the tmpmfs flag (and probably tmpsize) for rc.conf.
<fullermd> (the default size is 20 megs, so that's probably a little tighter than you usually want in practice...
<vila> fullermd: so in defaults/rc.conf the doc for tmpmfs says: Set to YES to always create an mfs /tmp, NO to never
<vila> fullermd: and the default is AUTO.... color me confused :)
<vila> what does that mean exactly ?
<vila> df /tmp says 1M 512-blocks, so 512M, but that looks like real disk to me (as real as a VM can go that is...)
<vila> fullermd: anwyay, using tmpmfs="YES", tmpsize="256m" and rebooting, I now have a /dev/md0
<vila> fullermd: so last question: when doing df I now have:
<vila> /dev/ad0s1e              1015260     5848   928192     1%    /tmp
<vila> /dev/md0                  507356      300   466468     0%    /tmp
<vila> fullermd: could that be a problem ? Is the later mounted on top of the former ? Do the former act as an extension area for the former (ha ha, dream !) ?
<vila> OR should I just comment out the line in fstab for the former?
<fullermd> Yeah...   having two things mounted on the same point is usually not what you really want  :p
<vila> fullermd: ok, commented out for next reboot, df /tmp points to /dev/md0 for now, so I'm good :)
<poseidm> can I use bazaar also as a backup system for directories with binary files?
<spiv> poseidm: yes
<poseidm> do you use it for backup? or some other tool?
<bialix> vila: ping, I'm back
<vila> bialix: wow, that was a big biffy ;-)
<bialix> biffy?
<vila> bialix: what is the last message you read in the conversation this morning ?
<bialix> what means biffy?
<vila> bialix: bbiab means be back in a biffy, biffy being a very short time AIUI
<beuno> vila, spiffy?
<beuno> (hi!)
<vila> http://www.internetslang.com/BBIAB.asp says bit not biffy...
<bialix> bbiab means be back in a bit?
<vila> where did I get that then....
<bialix> yes, vila, my in a bit was a bit longer than biffy
<vila> anyway, glad you're back :)
<vila> bialix: what is the last message you read in the conversation this morning ?
<bialix> [2009-12-03 12:30:39] <vila> bialix: still there ?
<bialix> :-D
<bialix> I have log
<vila> hehe, so, how about PF\Bazaar\site\{lib,plugins} ? That seems to clearly defines the 'site' needed directories no ?
<bialix> vila: So APPDATA\bazaar\2.0\lib sounds perfect no ? -- no, it seems wrong
<bialix> esp on Vista where it could be roaming
<vila> yeah, yeah, keep reading :)
<bialix> ok
<bialix> so
<bialix> that's why I said at start of our chat that good name is needed
<bialix> maybe PF\Bazaar\python25-libs
<bialix> maybe
<bialix> any other variant is good, but having python version specified may help to avoid confusion
<bialix> if people start installing package for 2.6
<bialix> PF\Bazaar\lib -- is our core
<bialix> PF\Bazaar\plugins is our site
<bialix> I mean for bzr.exe
<vila> so, if you want to take that into account, the blessed names are:
<bialix> core is inside r/o blackbox, let me say that
<vila> <bialix> PF\Bazaar\lib -- is our core
<vila> <bialix> PF\Bazaar\plugins is our site
<bialix> beuno: what is spiffy?
<vila> meh, don't mix up core and site there, one is for libraries, the other for plugins, so both should be 'core'
<bialix> if you insist that bzrlib/plugins/* is core then I can say that PF\Bazaar\lib\library.zip -> bzrlib/plugins/* is the core
<vila> then you can have site\lib and site\plugins for 'site' and if needed lib\py25 lib\py26 but that would mean that bzr.exe exists for both 2.5 and 2.6, is that the case ?
<bialix> and hi beuno
<bialix> vila: no, bzr.exe bundled only one interpreter
<vila> bialix: I don''t understand the meaning of -> here
<beuno> bialix, http://www.urbandictionary.com/define.php?term=spiffy
<bialix> beuno, ah thx, it was spiffy
<vila> beuno: In fact I think I meant be back in a jiffy
<bialix> pfffffffffffffffffffffff
<beuno> vila, that's it! jiffy!  :)
<beuno> bialix, http://www.urbandictionary.com/define.php?term=jiffy
<beuno> :)
<bialix> vila: I've used -> to indicate it's inside zip archive
<vila> bialix: ha ! ok ! FUll agreement ! core is r/o blackbox-cant-be-modified
 * bialix shakes vila's hand, cool
<vila> but BZR_PLUGIN_PATH allows the user to put 'site'/'user' *before* 'core' if needed
 * vila re-reading plugin.py
<vila> bialix: can you look at plugin.py get_core_plugin_path() and get_site_plugin_path() too ?
<vila> I think we are pretty close so let's make these last steps
<bialix> vila: I'm not quite understand your remark about BZR_PLUGIN_PATH
<bialix> vila: bb in 15 minutes
<vila> bialix: forget it for a minute, just think that the default path is: ''user' 'core' 'site' and read the comment in get_standard_plugins_path()
<bialix> ok, will do, after short lunch
<vila> bialix: bon appetit !
<fullermd> Hm, lunch.  That's sounding like a goodish idea...
<rubbs> Morning
<bialix> fullermd: lunch for whimps?
 * bialix reading plugin.py
<bialix> vila: ok
<bialix> vila: get_core_plugin_path insist core on bzr.exe is PF\Bazaar\plugins
<bialix> that's fine
<vila> right
<bialix> user is APPDATA\bazaar\2.0\plugins
<bialix> no problem here
<vila> right
<bialix> site is still puzzling for me
<vila> let's leave aside for a minute
<bialix> ok
<bialix> so where we now? again
<vila> do you agree that bzr.exe can look at APPDATA\bazaar\2.0\lib for additional libraries ?
<bialix> it can but I think it's bad idea
<vila> why ?
<bialix> because it can be roaming
<vila> hmm, but in that case the plugins can be wrong too right ?
<vila> So it's the user responsability to be coherent between the plugins he install and the bzr.exe he install on his various hosts, right ?
<bialix> well
<bialix> honestly to say
<bialix> I'm hate APPDATA\bazaar\2.0 location
<vila> ok, for the sake of the discussion, let's call it USER\plugins then :)
<vila> Don't you feel better ?
<vila> do you agree that bzr.exe can look into USER\lib for additional libraries ?
<bialix> on my machine this is C:\Documents and Settings\myname\Application Data\bazaar\2.0\
<bialix> it's so boring to cd to this directory even via decent file mamanger
<bialix> so I'm keep all my plugins in C:\work\Bazaar\plugins and has specified BZR_PLUGIN_PATH
<bialix> how's your proposal will lokk given in mind my habit of BZR_PLUGIN_PATH?
<bialix> vila: ^
<bialix> what
<bialix> what's USER\lib
<bialix> ?
<vila> <bialix> I'm hate APPDATA\bazaar\2.0 location
<vila> <vila> ok, for the sake of the discussion, let's call it USER\plugins then :)
<vila> USER == APPDATA\bazaar\2.0
<bialix> why every user should have separate copy of third-party libs?
<bialix> why not PF\Bazaar\extra ?
<bialix> why not PF\Bazaar\extra-libs ?
<vila> because bzr.exe don't have a concept for 'site' which is where additional plugins and libraries can be installed in order to be shared between several users and several versions of bzr.exe
<vila> That's the whole point of the damn concept !
<bialix> another problem with APPDATA -- this folder is usually hidden
<bialix> so you can't get there on vanilla windows machine
<vila> Can we focus on solutions to already identified problems before raising new ones ?
<bialix> until you enable option to show hidden files in Explorer, or put the full path to address line
<bialix> let's try to invent site for bzr.exe then
<bialix> PF\Bazaar\site
<bialix> ok?
<vila> <vila> or PF\Bazaar\site\{lib,plugins}
<bialix> that's fine, though PF\Bazaar\site\plugins is useless
<vila> right, that was my last proposal this morning and that's what plugin.get_site_plugin_path() can return
<bialix> there is PF\Bazaar\plugins tight here
<bialix> s/tight/right/
<bialix> if you wish -- why not? but it seems useless
<vila> :-(
<bialix> we started from the question: where we would like to put extra 3rd party libs
<vila>  PF\Bazaar\plugins exists and is not empty ?
<vila> what's in there ?
<bialix> all plugins provided by installer
<bialix> lp, netrc, bzrtools, qbzr, svn, upload, xmloutput
<bialix> and explorer
<vila> right, so that's core
<bialix> yes
<vila> and you said you want to keep that read-only, ok, so we can't put anything there, ok ?
<bialix> vila: no I said this about PF\Bazaar\lib
<bialix> precisely about PF\B\lib\library.zip
<bialix> PF\B\plugins is user editable
<vila> Can't you see that's precisely why we can't add more libraries ?
<bialix> there is another std location on windows for all users if you wish site
<bialix> C:\Documents and Settings\All users\...
<bialix> there is also Application Data, etc
<bialix> [17:08]	<vila>	Can't you see that's precisely why we can't add more libraries ?  <--- I don't understand this question
<vila> We want to be able to add plugins that aren't known by bzr.exe and these plugins requires some libraries
<vila> they should go into XXX\plugins and the libraries into XXX\lib
<vila> Since you don't want to add libraries into PF\B\lib, we can't add plugins into PF\B\plugins
<bialix> your term "plugins that aren't known" makes me uncomfortable
<bialix> does that implied bzr.exe knows about some plugins? it's not true
<vila> <bialix> all plugins provided by installer
<vila> <bialix> lp, netrc, bzrtools, qbzr, svn, upload, xmloutput
<bialix> this is known by installer
<vila> are you making a disctinction between bzr.exe and the installer ??
<bialix> yes
<vila> I didn't
<bialix> it's up to you
<vila> s/bzr.exe/installre
<bialix> ok
<bialix> if you wish to install plugins to "plugins" and libraries to "lib" (or "libs"?) that's makes sense
<bialix> where I should install libraries if I'm using BZR_PLUGIN_PATH
<bialix> ?
<vila> I want names to be coherent between 'core', 'site' and 'user' so lib and plugins for each of them, do you agree ?
<bialix> vila: I don't understand why you want tie them together
<vila> For consistency, because I dislike:
<vila> <bialix> precisely about PF\B\lib\library.zip
<vila> <bialix> PF\B\plugins is user editable
<vila> I want to be able to install a plugin and its libs that will override the one provided by the installer
<bialix> you're late for 3 years
<vila> ok, too bad, bye
<bialix> we may talk about where to put extra libs
<bialix> regardless of plugins
<bialix> this is 2 loosely related things
<bialix> install things in PF\B\lib may be wrong idea because there is already too much things
<bialix> you need clean location to ensure user won't delete some important file
<bialix> I guess so
<bialix> ok, too bad, bye -- sorry for this
<bialix> vila: I'm really sorry
<kfogel> jelmer: no sign of bzr 2.0.2 at http://packages.debian.org/lenny-backports/bzr yet... Any ideas?
<jelmer> kfogel: Not sure why it's not listed there, but the archive appears to have it:
<jelmer> http://www.backports.org/debian/pool/main/b/bzr/
<kfogel> jelmer: thank you.
<kfogel> jelmer: you might know off the top of your head: savannah.gnu.org is currently running 1.16.1, and has been having some severe loggerhead crashing problems lately.  Is loggerhead with 2.0.2 stable?  That will be an additional motivation to upgrade, if so.
<jelmer> kfogel: I wouldn't know, sorry
<kfogel> jelmer: np
<kfogel> Does anyone here know if loggerhead is stable with Bazaar 2.0.2?  Latest release is "loggerhead-1.17" from August 2009... Does one have to run trunk code to work with bzrlib 2.0.2?
<P4C0> Hello, is it possible to revert the changes done in a branch? or should I just rm the branch and create it again?
<Pilky> P4C0: bzr revert
<rubbs> P4C0: bzr revert
<rubbs> Pilky: beat me
<Pilky> rubbs: w00t, what do I win?
<P4C0> Pilky, rubbs thanks, and if I don't want a branch anymore, can I just rm it?
<Pilky> P4C0: yep
<P4C0> Pilky: thanks
<rubbs> Pilky: brownie points. you get 5. If you get 1000, I'll send you some brownies ;)
<Pilky> P4CO: not sure what happens to any revisions just in that branch that are stored in the repo, you'd have to ask one of the bzr devs
<P4C0> ok, thanks
<rubbs> Pilky: P4C0: The revisions stay there
<rubbs> Pilky: P4C0: They just don't have any children
<rubbs> at least thats what it looks like when I did it.
<rubbs> I could be wrong
<Pilky> rubbs: yeah that's what I thought, I was just wondering if bzr did anything to clean them up
<rubbs> Pilky: I'm not 100% sure, I'm gonna do a quick test and check.
<Pilky> rubbs: if any command was to do it I'd have a guess at pack
<rubbs> Pilky: that would be my guess as well
<fullermd> It doesn't.
<fullermd> gc is discussed from time to time.  It hadn't topped anybody's todo yet.
<rubbs> Ah, that's what I thought, I just couldn't remember for sure
<hazmat> so i'm trying to push a branch upstream back to launchpad, but i get an odd error bzr: ERROR: RemoteRepository is not compatible with CHKInventoryRepository different rich-root support.. any ideas on how to resolve?
<fullermd> hazmat: That means your local repo is in the 2a format, while the LP is in an earlier format without RR support.
<fullermd> Basically, the options boil down to 'upgrade the LP branch' or 'redo local changes in a poor-root branch'.  RR revs can't be moved into a non-RR repo.
<hazmat> fullermd,  thanks for the info.. upgrading the lp branch isn't an option for me.. re redoing the local changes.. to get my local branch, i branched a co of a launchpad repo in a shared repo dir, what would i have to do differently to get the same repo format as launchpad.. also is there a way i can downgrade my existing repo to something compatible?
<fullermd> Well, to answer the last first, no; the poor-root -> rich-root transition is a trap door.  We've supported both back to 1.0 (and even further, sorta), and it was just time (or well past time) to pull the default switch.
<fullermd> When you branch into an existing repo, it will use that existing format.  So that's how you ended up in the situation; you had an existing 2a repo, so the 'branch' process upgraded the data as it came in.
<fullermd> So to get the same, you'd either (a) branch to a standalone location with no existing repo (which would preserve the source format), or (b) lookup the format manually first and make sure your repo can talk back to it.
<P4C0> is there a command to remove all the local files that are not under the repo control?
<Pilky> P4C0: bzr clean-tree I think
<Pilky> or something along those lines
<jelmer> bzr clean-tree- --unknown
<P4C0> thanks
<jelmer> --ignored for ignored files
<bialix> hello jam
<P4C0> hmm I just compile the code on my local branch but bzr clean-tree says there's nothing to clean
<Pilky> P4C0: are the compiled files ignored?
<P4C0> --ingored did it ;)
<P4C0> Pilky: seems so... bzr status doesn't say anything
<Pilky> yeah, by default it doesn't list the ignored files
<kfogel> Does anyone here know if loggerhead is stable with Bazaar 2.0.2?  Latest release is "loggerhead-1.17" from August 2009... Does one have to run trunk code to work with bzrlib 2.0.2?
<kfogel> rockstar: ^^
<rockstar> kfogel, I'm pretty sure it is.  I think our loggerhead instance might be running on 2.0.1 or 2.0.2 now.
<rockstar> kfogel, I can't imagine that part of the API has changed much.
<kfogel> rockstar: thanks.  The question is, are we running the last release of loggerhead, or trunk code?
<rockstar> kfogel, we're running a variant of trunk, but, like I said, I can't imagine there were that many changes.
<beuno> kfogel, latest release of LH, AFAIK
<beuno> and the latest LH works fine with the latest bzr
<kfogel> beuno, rockstar: thanks
<beuno> kfogel, I'd be happy to help out getting LH working in the emacs world
<beuno> (or adapt some things if needed, within reason)
<kfogel> beuno: they don't make it easy for knowledgeable volunteers to assist, but I keep offering our help; maybe they'll take us up on it.
<quicksilver> it seems that sometimes cd into a very old branch and bzr pull --overwrite is slow
<quicksilver> slower than rm -rf branch; pull fresh branch
<quicksilver> that seems counterintuitive?
<mwhudson> quicksilver: is there a format conversion going on?
<quicksilver> yes, I think so.
<quicksilver> actually pulling a fresh branch is slower than I remembered.
<quicksilver> 7 minutes so far and counting.
<lifeless> james_w: hi
<james_w> morning lifeless
<lifeless> james_w: can you explain where the concern about 'good bug reports' comes from, I think it may be impeding communication/'getting things done'.
<lifeless> james_w: also, how are you :)
<james_w> good thanks, how are you?
<lifeless> Good - back down to 91kg yesterday morning
<lifeless> the 90kg barrier is my nemesis
<james_w> you mean the udd thread "Bugs for daily build packages"
<james_w> ?
<lifeless> Not precisely ;). its turned up a few times; you mentioned in a bug I filed on -builder, I think, and then again in the thread about what stuff bzr folk are doing
<lifeless> I'd like to understand more about it, about what you mean, and so forth
<james_w> oh
<james_w> got it now
<james_w> so, my worry is that some things are too imprecise currently
<james_w> "<thing> could be better" type reports
<james_w> I could report that, and then use the bug report to discuss ways to tackle it
<james_w> but that probably isn't the best forum
<james_w> there's also a question of when the bug can be considered fixed
<james_w> with something like that, what does "better" mean
<james_w> I'm trying to find a bug I'm sure I remember where you were discussing whether having a bug "bzr <operation> is too slow" open was worthwhile, as my recollection is that you touched on similar issues there
<lifeless> yes
<lifeless> and those are good, valid concerns
<lifeless> OTOH bug reports are essentially just conversations; I agree that the list is ~ the best the forum to be discussing 'what should be done'
<lifeless> and I don't want you to tear through the specs and turn everything into bugs - I don't think thats efficient either.
<jam> morning lifeless
<jam> hi james_w
<lifeless> but I'd like to encourage you to file a bug for anything that is adding friction, or causing issues
<jam> what are you still doing up?
<lifeless> hi jam
<james_w> hi jam
<lifeless> even if its a big amorphous, its still data to the bzr devs
<jam> james_w: so one of the good things about filing separate bugs is that it allows you to split the discussion by thread, and have a way to make progress on part of it without all of it
<james_w> lifeless: I will file bugs in future where appropriate
<lifeless> in the performance case we knew it all :P
<jam> it also gives a checklist of "these are things to work on"
<jam> which can be done in mailing list threads, but it is a lot harder to get a summary and overview
<rubbs> so in this case what is the difference between a bug report and a blueprint? (sorry to just jump in here)
<james_w> rubbs: you could probably use either. Historically bzr hasn't used blueprints
<rubbs> james_w: ok, cool. I was just curious
<jam> rubbs: blueprints are very underdeveloped as a launchpad feature
<jam> they are meant to capture the concept of "feature development" separate from a "bugfix"
<yojimbo-san> I have a beginners question -- I've used lots of centralised VCS (e.g. svn) but not a DVCS; As a sysadmin, I have /etc under VCS on multiple servers, but I'd like to have one central place where I can (check out/see) all the machines configs with a single tool, such as Trac. I'm probably using the wrong terminology, but can I "join" multiple repositories together into one other one? (it can be read-only if that's easier) ... so from my Trac machine, I see one 
<rubbs> jam: that makes sense thank you
<rubbs> yojimbo-san: I think I understand your question but let me make sure: You wish to be able to keep multiple different configurations together in one central location so you can view them all. Is that correct?
<yojimbo-san> yes; just for viewing purposes. Each machine should be otherwise stand-alone (local repository) and independant
<yojimbo-san> But I'd like to see the version history for each file from the central place
<rubbs> I'm not an expert here, but maybe this would help. Instead of trying to pull from many to one, you could push from one to many. Here's what I mean:
<NfNitLoop> it's basically a centralized configuration, with a different repo for each machine.
<NfNitLoop> all with copies hosted on the 'trac' server.
<NfNitLoop> they can have a standalone branch/local-copy for faster/disconnected operation.
<rubbs> you could make a central location (shared repository) that has a main file. Then branch off a new branch for each configuration and then push them to the servers.
<yojimbo-san> So, if the central location sees a file as "/machine1/etc/hosts", how would machine1 see this as "/etc/hosts"? (Or should I cheat by symlinking /etc? :-) )
<yojimbo-san> Or is that not a relevant question with bzr?
<NfNitLoop> with bzr...
<NfNitLoop> you can put your branches anywhere.
<NfNitLoop> so on each host, I woulddo:
<NfNitLoop> cd /etc; bzr init .; bzr add files you want to track; bzr commit -m "Initial Checkin"
<NfNitLoop> then you can either do a 'bzr push' up to your server...
<NfNitLoop> or from your server do a "bzr pull"
<rubbs> so for example, say you have server1 and server2.
<NfNitLoop> actually, the advantage of doing a bzr pull from the server is that it'll update your working copy.
<NfNitLoop> so I'd recommend that.
<rubbs> you can make a change on server1 and then push it to server2
<rubbs> A better example might be that you have a central repository on server1 at /var/configfiles
<rubbs> then you can have branches on server2 and server3 at /etc
<rubbs> Then if you want to update server2 from server1's repo, you can do this from server2: cd /etc; bzr pull sftp://server1/var/configfiles;
<yojimbo-san> Ok, that gives me something to try ...
<rubbs> DVCS took me a while. The best way to learn is to just fool around with it until you get it.
<yojimbo-san> :-)
<rubbs> that and keep asking questions
<rubbs> ;)
<yojimbo-san> Are things like file owners/permissions tracked well?
<bob2> no
<rubbs> no
<yojimbo-san> so that makes pulling files dangerous ...
<bob2> use etckeeper
 * rubbs slaps head
<rubbs> I should have remembered that
<rubbs> etckeeper was designed for pretty much exactly what you are asking about
<yojimbo-san> bob2: does etckeeper track permissions? I thought it was just a handy wrapper around having VCS in the first place ...
<bob2> yes, no
<yojimbo-san> Mmm, I must go do some more reading then :-)
<yojimbo-san> So if I use etckeeper to create local bzr repositories, I then want some way of hooking them all back to my central Trac ...
<rubbs> there, I can not help, but I'm guessing it's possible
<yojimbo-san> probably, especially if I create the branch for each machine's etckeeper repository on the central place, push it out (empty) to the target machine, then initialise etckeeper to use it ... then push it back centrally ...
<yojimbo-san> Sounds like a bit of a juggling act, but I'll go figure something out. Thanks for your time, rubbs, bob2 NfNitLoop.
<rubbs> np
<NfNitLoop> yojimbo-san: It's only about 1 command more than working with centralized svn.
<NfNitLoop> if you're going to store them all on a central server anyway, you could get away with using svn.
<NfNitLoop> bzr just buys you the nice features of DSCM (and bzr itself)
<yojimbo-san> NfNitLoop: Well, as a non-coder, finding a decent opportunity to learn about bzr in a way that's different from simple svn isn't always easy :-) So having a target problem motivates me to actually learn stuff ...
<lifeless> james_w: actually, we used blueprints for a bit; they didn't fit all that well
 * igc breakfast
<poolie> james_w: I agree with you that "X could be better" or "something should be done" bugs are poor
<poolie> also that blueprints don't help much in our system
<poolie> perhaps they match UDS well
<lifeless> poolie: I prefer 'x could be better' to silence though, which is my point
<lifeless> one can iterate to improve the resolution
<mtaylor> lifeless: I just got another complaint from someone about error messages when branch formats don't match
<lifeless> mtaylor: yes
<mtaylor> lifeless: just thought I'd continue to be annoying about it :)
<lifeless> mtaylor: if they upgrade... :P
<mtaylor> lifeless: if they upgrade the error messages get better? :)
<mtaylor> lifeless: that's exciting!
<mvo> bazaar.launchpad.net give me connection refused errors, is that just me or is this a general problem?
<mvo> (on port 22)
<spiv> mvo: I think Launchpad is down for a code update atm?
<spiv> That's what /topic in #launchpad claims, at leastd.
<lifeless> mtaylor: if they upgrade, they have 2a and don't have trouble :P
<mtaylor> lifeless: :P
<mtaylor> lifeless: do you want me to actually file another bug about it though? or can I assume everyone is well aware...
<lifeless> mtaylor: its in the 'wishlist' pile at the moment; its something we'd take a patch to make better
<lifeless> (and there are bugs)
<lifeless> but its not something we're devoting time to
<mtaylor> lifeless: k. as long as it's in a pile somewhere. just didn't want to assume it was and be wrong
<lifeless> the pile grows... :P
<lifeless> mysql could file a ticket on it, if its plaguing you guys
<mtaylor> lifeless: oh, I don't know if it's plaguing mysql
<mvo> spiv: aha, ok, thanks! its time for bed for me anyway :)
 * mvo waves
<blueyed> I'm getting content conflicts, and I don't know how to resolve them: http://pastebin.com/m726a3dee
<blueyed> (answers.lp.net is down)
#bzr 2009-12-04
<amanica_> the one day of the month I try to push code to launchpad, its down :(
<jpds> amanica_: New code rollout.
<amanica_> jpds: yup, I know, but its going on longer than expected
<amanica_> and I want to push this stuff before I go to bed
<amanica_> not sure if I should wait..
<elmo> amanica_: you may want to go to bed and do it tomorrow
<amanica_> elmo: thanks
<asabil> amanica_, or sleep 3600 && bzr push
<amanica_> in a loop yeah :) cool idea
<amanica_> goodnight then. thanks for the advice
<poolie> jam, still around?
<poolie> i'm just wondering if for bug 491763, failure to rename, we should give a better message
<ubottu> Launchpad bug 491763 in bzr "Cannot update working tree" [Undecided,New] https://launchpad.net/bugs/491763
<poolie> there have been several like this
 * igc lunch
<jam> poolie: I certainly think something better than a traceback is warranted. Especially since it doesn't give the 'from_' or 'to' filenames (in this case 'to' is probably the most interesting)
<jam> actually, take that back, this is pre-delete, which should be where it moves files out of the wt
<jam> so from is more interesting.
<jam> anyway... the cases where we've run into this in the past are more Windows errors
<jam> I haven't specifically seen it on Apple before
<poolie> oh and i see it would be relevant to your ec2 failures too, perhaps
<poolie> i was thinking that osutils.rename should wrap it, and then we should test_source ban use of os.rename
<poolie> i've also wondered if we should have a weakref dict of all open files
<poolie> so we can dump it in a crash
<poolie> igc: alldocs updates failed because bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ian-clatworthy/bzr-explorer-website/trunk/".
<poolie> oh, duh, that would be because of lp outages
<jam> poolie: so I don't think this failure is anything like what I'm seeing on EC2 or Windows. Because it is on Apple, you can't (afaik) lock a file such that you can't rename over the top of it.
<jam> (my guess is that the dir is readonly.)
<poolie> it's only similar to the others in that not seeing which filename caused the rename failure is annoying
<jam> ah, sure
<jam> that is definitely true
<jam> poolie: I'm going to go away for a bit but it would be nice to chat about bug #40412 a little bit when we get a chance
<ubottu> Launchpad bug 40412 in bzr "show-base for weave merge" [High,Confirmed] https://launchpad.net/bugs/40412
<jam> I think I have something that works
<jam> but I have to consider how to handle some lca cases, and I'd like someone to sound the idea off of
<jam> the code is here while LP is down: http://bzr.arbash-meinel.com/branches/bzr/lps/2.0-40412-show-base-weave/
<poolie> ok
<poolie> i'll be here at least the next 4 hours
<poolie> modulo lunch
<jam> poolie: I'm back sooner than I expected :)
<jam> so the brief summary
<jam> I'm trying to drop a .BASE file on disk
<jam> based on the merge plan
<jam> so entries that are "new-a" are omitted, but "killed-a" are considered to be part of BASE, etc.
<jam> The current issue is essentially whether we want base = UNION(bases) or base = INTERSECTION(bases)
<marcos> hello all, question: when i try to branch docky, it shows this error: bzr: ERROR: Invalid url supplied to transport: "lp:docky": OOPS-1434EC412.  any ideas?
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1434EC412
<marcos> huh?
<RAOF> marcos: I'd guess that's fallout from launchpad's current unworkingness.
<jam> marcos: lp is currently undergoing maintenance. That may not be the problem, but it is likely to be
<marcos> okay, fair enough. wasn't sure but I suspected that
<jam> poolie: ping me when you are around
<marcos> RAOF: jam: thanks
<lifeless> marcos: you can't use lp: atm
<igc> lp is not a drug. I can live without it. really. Just keep telling myself that and ...
<fullermd> It's not really a drug unless all the cool kids are doing it.
<poolie> hi jam
<poolie> igc, i know, you don't missi it till you're gone
<poolie> marcos: see http://identi.ca/launchpadstatus
* poolie changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Helping with patches: poolie | http://identi.ca/launchpadstatus
<igc> poolie: just did - last update was 2 hours ago
<poolie> well, and see #launchpad-code for more details i guess
<poolie> jam, that plan makes sense to me
<poolie> i would say probably you want the union of bases
<jam> poolie: so I originally also thought union, but I'm wondering about the consequences
<jam> namely, consider the "criss-cross merge swapped resolution" case
<poolie> i think we need some kind of warning that this file isn't guaranteed to mean anything :)
<jam> where both sides add a line
<jam> then both sides merge the other
<jam> and change the order of the result
<jam> (so XY => XaY => XabY, XY => XbY => XbaY)
<jam> if you take the union
<jam> you get
<jam> XbabY
<jam> if you take intersection you get
<jam> XaY
<jam> if you do diff 3 with the two tips,
<jam> union gives you XaY
<jam> intersection gives you XbabY
<jam> poolie: does that make sense? Or do i need to explain further?
<poolie> yes, i think i know the case
<jam> the issue is if BASE has it, then it looks like it should be removed in target
<jam> if BASE doesn't then it looks to be added
<jam> And it seems that having the target add lines is "safer" than having it delete lines
<poolie> but you wouldn't want to add both
<poolie> ah, probably true
<poolie> so in this case we have the two sides being
<poolie> XabY and XbaY?
<jam> poolie: right
<jam> and I don't have a great way to say "add just one"
<jam> merge --weave implicitly picks one
<jam> merge --lca conflicts
<jam> on both
<poolie> you could almost add another option, or maybe a debug option, to control this
<poolie> and just let them try it
<poolie> istm it's going to depend a bit on just what operations they do
<poolie> whether they're doing a three-way diff against base, or a two-way diff, or just looking at the basis regions within the conflict markers
<jam> right
<jam> this is only for a .base to use in a 3-way app
<jam> well... primarily for that
<poolie> so i'd probably just pick one, document it, and let them try it
 * poolie thinks aloud: do we still want some bzr branches statically hosted on escudero?
<poolie> like a mirror of trunk from launchpad
 * lifeless doesn't care
<jam> it certainly seems like launchpad has been down for a lot longer than the 90 minutes claimed in the status update
<jam> given that amanica was commenting on it 4 hours ago...
<mwhudson> jam: yes
<meoblast001> oh no
<meoblast001> i'm drawing blanks, how do you set what branch version to use in init?
<lifeless> meoblast001: version? do you mean format?
<meoblast001> ah, yes
<meoblast001> thanks
<poolie> launchpad should be ok again now
<_diablo> poolie: it's working for me
<igc> bbiab
<igc> enjoy your break lifeless
<poolie> vila: hi?
<vila> poolie: hey !
<vila> hi all
<poolie> hi there
<poolie> spiv, what's the invocation of pqm-submit to make it work directly from launchpad?
<igc1> hi vila
<vila> poolie: can we try to chat a bit before you EOD if only for patch pilot sync ?
<poolie> yes, sure
<poolie> here or on the phone?
<vila> let's try phone ! # ending with 8840 ?
<poolie> yes, but 1m first
<poolie> ok, now?
<vila> yup
<igc> night all - have a good weekend
<igc> poolie: fyi, I've reviewed and approved Marius's log patch to fix that bug for MySQL.
<poolie> thanks igc
<poolie> have a good weekend too
<spiv> poolie: --ignore-local, you need to pass the public location and submit loctaion on the cmd line, and you need to have set pqm_email (IIRC) in your locations.conf -- it's looked up on the submit location
<poolie> i failed
<spiv> poolie: so I hvae [http://bazaar.launchpad.net/*/~bzr/] there IIRC
<poolie> vila, https://bugs.edge.launchpad.net/launchpad-code/+bug/492145
<ubottu> Ubuntu bug 492145 in launchpad-code "email about updated mp diffs includes obsolete/misleading cover letter" [Undecided,New]
<bialix> hi
<_Andrew> Is there a way to remove a revision that's waiting to be merged and then pull that revision from another branch again?
<_Andrew> because bzr merge is crashing for me
<_Andrew> ..and I think if I pull this revision again it will work
<gioele> what is the revision spec alias for "the point where I branched off the parent branch"?
<gioele> so that I can do "bzr diff --old when-i-branched:"
<Peng> gioele: ancestor:, I think?
 * wgrant uses -rancestor:../trunk
 * AfC uses
<AfC> $ bzr gdiff -r ancestor:../mainline
<AfC> [or,
<AfC> $ bzr gdiff -r ancestor:/home/andrew/src/java-gnome/mainline
<AfC> if I'm somewhere else; for reasons I don't quite understand, Bazaar doesn't interpret ~ so
<AfC> $ bzr gdiff -r ancestor:~/src/java-gnome/mainline
<AfC> doesn't work]
<AfC> gioele: note no `--old` in all that
<AfC> Hm
<gioele> thank you Peng, wgrant, AfC
<gioele> bzr diff -r ancestor: is enough (I branched from mainline)
<gioele> aliased to "bzr basediff"
<marek> hi, can you help me with this case? i have a server with repo, and some desktops connetced to the same LAN for developers, they also have repos on their machines. One of them just branched first revision from server, and changed some files, then he commited locally and merged with server repo. now he wants to push from his machine to server and he sees a "diverged" problem, how can i deal with it?
<Peng> marek: He did commit after merging, right?
<Peng> marek: Or perhaps there's another new revision on the server, and he'll have to merge+commit again?
<Peng> marek: Usually people keep a mirror of the upstream branch, and do their work in feature branches, merging the feature branch into the trunk and pushing that. Just FYI.
<marek> ok so i will try merge and then commit and then push?
<Peng> marek: You have to commit after merging . . .
<marek> ok, that was it thx
<marek> i just had to resolve conflicts
<marek> and than push worked
<marek> ok but stil lnot everything is ok
<marek> so:
<marek> on that machine with problems, there is revision 3, and i can see all files from server repo and from that developer
<marek> i did push
<marek> and than on server i did update, and i saw info about rev 3
<marek> but on server i cannot see files added by that developer
<marek> :(
<marek> when i merged to my repo
<marek> from server
<marek> and than status i can see:
<marek> pending merge tips
<marek> and commit from that developer
<bialix> marek: you should run `bzr update` on server after you push there
<marek> i did
<marek> "tree is up to date"
<bialix> run `bzr log -l1` on server and on client
<bialix> and compare output
<marek> on my client, or on developers client?
<marek> on mine i can see:
<marek> revno 5
<marek> and on server revno 3
<bialix> on the client you did push
<marek> on client: http://pastebin.com/m51448bcb
<bialix> check the URL you and other dev used
<bialix> specify explicit URL if you in doubts
<marek> that one from server
<marek> http://pastebin.com/m58d7979c
<bialix> so they seems identical?
<bialix> so what's the problem?
<marek> dev has a folder on his machine
<marek> that is not visible on server
<bialix> check that dev actually added this folder with `bzr add`
<bialix> you can run bzr log -v to see all changed files
<bialix> for each revision
<bialix> or better use qlog
<bialix> `bzr st` also shows you unknown (not added yet) items
<bialix> also, you may want to use `bzr commit --strict`
<bialix> this commit refuse to work if there is unknown files in the tree
<bialix> marek: are you unsing only command-line or some GUI client?
<marek> cli
<marek> ok i found something
<marek> on logs i cannot see that files are added
<marek> and st shows me status "unknown"
<bialix> so they are not added
<bialix> bingo!
<marek> one more comit?
<marek> no
<bialix> bzr add && bzr commit
<marek> hmm, whenever i add some files on local repo, do i have to bzr add?
<bialix> yes
<marek> ahh so that part i missed :)
<bialix> marek, if I understand correctly you started using bzr just recently; you may try Bazaar Explorer GUI, it's very good and provides you useful hints about what's going on and what to do nextr
<bialix> really
<marek> i will,
<marek> and it is first project with bazar
<marek> but i have another problem
<marek> diverged branches while pushing :(
<bialix> or you can just read tutorials and user guide, of course ;-)
<bialix> diverged branches is not problem
<bialix> I teach you
<bialix> it's very easy
<bialix> do you read in Russian?
<bialix> I have blog
<marek> no
<bialix> ok
<bialix> nm
<bialix> you should use branch on the server as authoritative one
<marek> ok
<bialix> for local work it's better to create shared repo (bzr init-repo)
<bialix> then get the copy of server trunk branch (bzr branch server/trunk local/repo/trunk)
<bialix> for each new feature you made new local branch from trunk mirror
<bialix> bzr branch trunk new-feature
<bialix> then cd new-feature
<bialix> hack hack hack
<bialix> bzr ci
<bialix> ok, you ready to push your changes to trunk
<bialix> you going to mirror of trunk
<bialix> doing pull from server: bzr pull
<bialix> no you merge your new-feature branch to this mirro:
<bialix> bzr merge ../new-feature
<bialix> check the result
<bialix> resolve conflicts
<bialix> commit the result
<bialix> now you push to the server from this trunk mirror
<bialix> bzr push
<bialix> voila! no conflicts!
<bialix> I made some typos
<bialix> sorry
<bialix> marek: is it makes sense for you?
<marek> it is hard :)
<marek> but it surely has
<bialix> the main point: you need separate mirror of trunk
<bialix> on each dev machine
<marek> you just gave me a sugestion how it should look? or how can i deal with my current problem?
<bialix> I've tried you explain how to work with bzr as DVCS
<bialix> I'm not quite sure what is your current problem
<bialix> there is no problem
<bialix> maybe some misunderstanding
<marek> problably, so you are talking about this? http://doc.bazaar-vcs.org/bzr.2.0/en/tutorials/centralized_workflow.html
<bialix> no
<bialix> centalized workflow uses checkouts instead of just branches
<bialix> but you could use it, if you wish
<bialix> I mean this: http://doc.bazaar-vcs.org/bzr.2.0/en/tutorials/tutorial.html
<bialix> but it does not explain what I've just explained to you
<bialix> marek: this one I suppose http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/distributed_intro.html
<bialix> marek: or even better this: http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/organizing_branches.html
<marek> ok i will use it
<rubbs> marek: If you read the documentation and find something confusing, please submit a bug, and tag it with 'doc'
<rubbs> marek: that way the bzr-doc team can try to improve it.
<marek> ok
<rubbs> thanks!
<rubbs> I'm getting an error when I try to pull from bzr.dev.
<rubbs> http://pastebin.com/f37871e00
<rubbs> the basic error is : bzr: ERROR: exceptions.TypeError: Expected a plain str for value not: <type 'unicode'>
<bialix> this very bad
<bialix> file a bug
<bialix> jam: ^
<rubbs> Ok will do
<sjamaan> How does bzr determine the 'default stacking branch'? Is that automatically the one you initially branched from?
<jam> bialix, rubbs: It looks like a bug in bzr-search
<jam> sjamaan: It is set in a config file by launchpad based on the 'development focus'
<jam> when you push to launchpad, bzr reads that file and sets up a stacked branch
<jam> you can set that sort of thing up locally as well
<jam> otherwise if you do "bzr branch --stacked" then it is implicitly stacked on the source branch
<bialix> ÑÑ Ð¾ÑÑ!
<bialix> hi jam!
<jam> hi bialix
<sjamaan> jam: thanks
<rubbs> jam: thanks, I'll dissable that plugin. I submitted a bug already, should I re-target it?
<jam> rubbs: yes
<rubbs> jam: will do thanks
<mgedmin> dear lazyweb, does anybody remember the shell one-liner to add bazaar PPA's GPG key to the apt keyring (in jaunty)?
<mgedmin> found it: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECE2800BACF028B31EE3657CD702BF6B8C6C1EFD
<mgedmin> thanks for the patience
 * gour is happy to see igc here hoping his health is better
<gour> two questions: is bzr-git in a better shape than bzr-hg (when there will be push) and when is emacs going to (finally) switch to bzr?
<jelmer> gour: bzr-git doesn't support push, only dpush
<gour> jelmer: i'm not (yet) familiar with dpush...but accordingto roadmap i see 'push' is planned...my use case is simple...don't want to dive into git's (over)complexities and would rather stay with simple & powerful dvcs-es liek bzr (& darcs)
<jelmer> gour: Uhm, which roadmap is that? I'm the primary author of bzr-git and don't remember one..
<gour> jelmer: http://bazaar-vcs.org/BzrForeignBranches/Git - it says push to git. is it dpush?
<jelmer> ah
<jelmer> that's the long term roadmap, won't happen soon
<jelmer> use dpush in the meantime
<jelmer> the problem with push is that we can't stow extra data anywhere in git
<gour> huh...better not to speak too much about git ;)
<gour> jelmer: you're pushing bzr-hg as well..
<gour> how it plays with 1.4?
<jelmer> bzr-hg trunk works with hg 1.4
<gour> ohh, that's good. i wanted to do darcs <---> hg, but hg's fast-import are not really functional
<jelmer> gour: Ah, heh
<gour> what about emacs conversion? they're planning it for quite some time?
<bialix> gour: last time kfogel said it happens in next 2 weeks
<bialix> it will happens
<gour> finally to end this saga :-)
<bialix> jam: ping
<jam> bialix: ?
<bialix> if I want to get path in tests to compare
<bialix> how can I make it canonical to avoid temp dir prefix?
<bialix> just s.replace(osutils.getcwd(), '') is enough?
<bialix> this is for TestCaseInTempDir
<bialix> or maybe there is something more handy?
<bialix> jam: I want to suppress temp dir prefix from the output of pinfo command in the tests
<bialix> can you suggest something?
<jam> pinfo?
<jam> you could use path.endswith() or assertEndswith()
<bialix> pinfo from scmproj
<bialix> it's like usual bzr info
<jam> I think your replace line would probably work, though there are potential problems with platforms, etc.
<bialix> but for projects
<bialix> what kind of problems?
<bialix> I can try it on Linux, on Windows osutils.getcwd() returns the path without trailing slash, so I need to add it manually
<jam> I believe there are some silly things that happen on Mac with /tmp
<jam> something like getting remapped to /private/tmp depending on whether normpath was called or not.
<jam> bialix: it also depends whether pinfo puts out the local path, or puts out a url
<jam> if it does a url, then you have to worry about url escaping, etc.
<bialix> it puts absolute path
<bialix> no, sorry
<bialix> it using
<bialix> urlutils.unescape_for_display(t.base, 'utf-8')  where t is transport
<bialix> but all this run for local objects
<bialix> so if looks like absolute path
<bialix> so it looks like absolute path
<cr3> I'm attempting to upgrade a branch on launchpad to --rich-root-pack and I get: bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/15/d7/backup.bzr'
<cr3> I'm trying to use hitchhiker and rmtree backup.bzr, but it seems to be taking a very long time
<cr3> man, if I thought rmtree was long, the upgrade is even longer. however, everything seems to be running fine so far
<distatica> When I create a project offline, and add a file, make a commit, and then push sftp://host/code/project (where project is a non-existent directory) the .bzr folder gets pushed fine, but the files are not there. I am trying to set this up for redmine though.. and it finds "The entry or revision was not found in the repository" how can I send the files too?
<distatica> create the project and bzr init on the server, and then push to that folder?
<amanica> distatica: it creates a treeless branch by default
<amanica> distatica: the bzr-upload plugin could help you. also see: http://bazaar-vcs.org/BazaarUploadForWebDev
<distatica> hmm.. I would want the full revision history though, wouldn't i? For redmine
<distatica> I have to run unfortunately to a job, thanks amanica I will read more about this when I get back.
<amanica> distatica: I've never used redmine
<gmpff> Hi.
<igc> amanica: your logging patch has been approved and sent to pqm. Many thanks!
<amanica> igc: thank you!
<amanica> igc: thinking about how the graghs work for log, made my head hurt. its the hardest I had to think in years. My brain is getting lazy :)
<igc> amanica: :-)
#bzr 2009-12-05
<neoTheCat> good evening EST
<neoTheCat> if i want to run bzr on multiple of my own machines, can i run whoami with the same name and email address on each machine?
<maxb> Yes you can, and moreover, you should. (Unless you actually wish to present multiple identities to the world)
<neoTheCat> maxb: cool, thanks.  i did not know if they would mess up anything when i work on one machine, and then i synch up with another one of my machines.
<neoTheCat> is peer-to-peer a bad idea if you are doing it with more than one person?
<neoTheCat> partner-workflow?
<neoTheCat> i followed the recipes on the bzr documentation page.  i set up the "bzr init-repo bzrrepo" on both machines, then bzr-init for my project dir.  when i try to get the branch, i am getting the "ERROR: not a branch" error.
<Peng> neoTheCat: "get"? Like, remotely? You know bzr+ssh:// and sftp:// paths are relative to the root, right?
<neoTheCat> Peng: thanks.  i assumed because using the sftp command by itself brought me to the users home dir, that bzr, using the same protocol would do the same.
<neoTheCat> which is why i  should RTF much closer... :)
<neoTheCat> s/RTF/RTFM/
<Peng> neoTheCat: You can use bzr+ssh://user@bzr.example.com/~/some_path_relative_to_the_home_dir
<Peng> neoTheCat: (same on sftp)
<neoTheCat> thank you
<gour> morning
<gour> i see there is only bzr-2.1 avaialble as pip and i wonder if it is safe-enough to be installed on my webfaction 'server' ?
<Peng> gour: Probably. bzr.dev *usually* works.
<Peng> gour: I mean, _I_ run it, but my server is down half the time anyway, so reliability is not that important. ;-)
<gour> Peng: i installed it. it is not so critical to pull from git repo from time to time with bzr-git
<shyam_k> /me just starting with using revision conrol systems
<shyam_k>  
 * shyam_k just starting with version control systems.
<shyam_k> my current needs are very simple.
<shyam_k> can't i use bazaar as an intelligent history enabled auto-save system for my local files too?
<shyam_k> that is just for personal use.
<gour> shyam_k: sure you can do
<shyam_k> gour: oh good.. thanks.
<shyam_k> am currently reading through the different options.. i like it emacs ish.. won't mind a learning curve, but want it to be powerful:)
<shyam_k> anyone using bzr with emacs? i just started with a local bzr repository and i would like to make it automatically commit every few minutes just like emacs makes the auto-save .. how to go for that?
<luks> that doesn't seem like a good idea
<shyam_k> hmm.. ok. what about integrating emacs' auto-save with bazaar? letting emacs do a commit on the bazaar to save the auto save file
<shyam_k> hasn't it been a need already?
<Peng> How would auto-commit generate decent commit messages?
<shyam_k> it can be some constant stuff.. what i want is to protect data..
<shyam_k> luks: why is it a bad idea?
<Raim> hi
<Raim> how can I use 'bzr send' to submit a patch to another developer if the public branch is temporarily offline?
<Raim> bzr send insists on connection to the server, but I just want to get a bundle of revisions and send them to someone
<bpierre> hi
<mac_v> hi... is there a wiki for the bzr gtk?
<mac_v> or tutorial ?
<mac_v> nvm , found it :)
<neoTheCat> hello. i have some basic newbie questions.  i am very confused on the difference between checkout and branch commands for getting a new project locally.  what is the difference?
<fullermd> Checkout gives you a [new] working tree to work on an existing branch.  Branch gives you a new independent branch.
<neoTheCat> fullermd: thanks.  simple enough.
<fullermd> Simple is my speciality   :)
<fullermd> ...  OK, that's a lie.  But I like to think it.
<neoTheCat> good.  you will be my best friend for a while then :)
<neoTheCat> so, if i setup a central repository, and i have two people (actually, just me on two different machines), and i just do checkouts and commits, i will handle conflicts manually, like in cvs or svn?
<fullermd> Yeah.  You'll have to 'update' before you can commit when you're out of date, etc.
<neoTheCat> thanks.  and one more question, and i think you have gotten me further in these few minutes, then by reading the docs.
<fullermd> The biggest difference is that 'checkout' by default creates what we call a "heavy" checkout, which means it still copies down a whole copy of the history (like branch does), as a local cache.
<fullermd> Which means you can do things like 'log' and 'diff' without having to hit the network.
<neoTheCat> i created the "peer-to-peer" setup.  i created a repository on "Machine A", and then on Machine B, did a "bzr branch sftp://...".  but when i commit on Machine B, it stills tries to hit Machine A.
<fullermd> That probably means you really ended up with a checkout, not a branch (either by running 'checkout' originally, or by doing something with 'bind' or maybe 'reconfigure' later)
<fullermd> See what 'info' has to say about the branch on B.
<neoTheCat> you know, i was playing around, and i could have done a checkout by accident.
<neoTheCat> yup, i did a checkout.
<neoTheCat> well, i am done with all my questions, and i am very much looking forward to removing subversion and switching to bzr
<fullermd> Note that, where possible, you probably want to use bzr+ssh rather than sftp.  It'll be a lot faster, especially at incremental stuff, as things get bigger.
<fullermd> If you have a real shell and bzr in the path on the far side, it should Just Work.
<neoTheCat> i am just happy to able to use real tags, not branches=tags )
<neoTheCat> )
<mac_v> hmm , how do i launch bzr-gtk?
<Noldorin> hi. what's the standard html page used for public http repos that shows instructions?
<Noldorin> anyone?
<Noldorin> >	hi. what's the standard html page used for public http repos that shows instructions?
<lifeless> I don't think anyone understands the question
<Noldorin> lifeless: there's some sort of standard page that people put on their http sites
<Noldorin> in the dirs from which bzr repos are served
<Noldorin> i've seen it before
<Noldorin> but not sure where to get it
<Peng> Noldorin: You mean like on http://bzr.mattnordhoff.com/loggerhead/?
<Noldorin> Peng: not quite. it's just a simple page that says "this is a bzr repo", writes the url, and gives some instructions how to pull the repo
<Peng> Noldorin: Unless you mean like the "To get this branch" box on e.g. http://bzr.mattnordhoff.com/loggerhead/loggerhead/cheezum/changes, I dunno, sorry.
<Noldorin> lifeless, Peng: ah, i guess i mean something like http://blueprintgames.com/developers/alex/bzr/cocoa-extractor/
<Peng> Noldorin: Ah. Um. I don't recall ever seeing that before. Might be custom.
<Peng> Noldorin: It's just one HTML page.
<Noldorin> Peng: yeah, that was my point exactly lol :P
<Noldorin> well, you could be right
<Noldorin> i was told it was standard though...
<Peng> Oh?
<Noldorin> heh, is there anything better you know of?
<Noldorin> (short of loggerhead, since that doesn't work on VPSs)
<Noldorin> i mean, yeah, it's not much. but it's better than a 404 :)
<maxb> <Noldorin> (short of loggerhead, since that doesn't work on VPSs)
<maxb> uh, why not?
<lifeless> maxb: windows IIS VPSs
 * maxb runs away
<Noldorin> hehe
<Noldorin> lifeless, maxb: i don't think it would work on linux apache VPSs either
<Noldorin> since it needs to be run as a separate server
<Noldorin> which is a bit of a shame
<Noldorin> because it's a nice interface...
<Noldorin> but its usage is vastly restricted
<lifeless> mod_wsgi
<Noldorin> lifeless: well i should in theory be able to use it on IIS with isapi-wsgi
<Noldorin> but there's no instructions :()
<mneptok> IIS?
 * mneptok checks the calendar
<mneptok> OK, it *is* 2009.
<NeverGone> hello
<NeverGone> one question?
<gutworth> maybe two
<Peng> Noldorin: What kind of *nix VPS prevents you from running mod_proxy?
<Peng> Noldorin: The issue is RAM...
<Peng> NeverGone: That was your one question.
<Peng> (Is that still funny? Was it ever?)
<NeverGone> When I'm in a subdirectory of a branch (repo/foo/bar), how can I create a new branch directly?
<Peng> NeverGone: What do you mean?
<Noldorin> Peng: the problem is running the server in the first place, as i see it
<Peng> Noldorin: In what way?
<Noldorin> Peng: you need the command line, as far as i know
<Peng> Soo?
<Noldorin> you can't run it if you don't have it
<Peng> There's a *nix VPS without command line access?
<Noldorin> just about every one i've used :P
<Noldorin> haha
<maxb> Buy a better VPS
<maxb> If you don't get root, it's not worth your money
 * Peng is writing this from a CLI IRC client, on a *nix VPS, next to the Loggerhead tab.
<Noldorin> ok, so this is my fault. i don't actually mean a VPS it seems
<Noldorin> just a normal shared server
<Peng> Ah.
<Noldorin> yeah, sorry about that
<Peng> ...I still have shell access to my shared servers (kind of, at least).
<Noldorin> from a shared server...
<Noldorin> i think i'm out of look
<Noldorin> luck*
<Peng> You could probably work something out with the FastCGI, SCGI and AJP support that was recently added.
<Noldorin> possibly
<Noldorin> but i think it would be asking for much pain on a windows iis7 shared server
<Noldorin> i have isapi-wsgi installed...so in theory, i should be able to run it
<Noldorin> but i don't have the foggiest where to start
<Noldorin> would be great if there were some instructions for loggerhead on iis :)
<Noldorin> i found an online memo from over a year ago saying there were plans...
<Noldorin> seems nothing has materialised though
<Peng> I'm even more sleepy now than I was last time you were discussing IIS. :P
<Noldorin> Peng: :P
<zsquareplusc> is it possible to "pull" again when branched from a svn repo?  that is, i have a branched from a svn repo, this worked, but bzr pull says "not a branch" so i dont know how to follow the svn server for updates
<Noldorin> not sure how i got back onto this track lol
<Noldorin> i meant to abandon it a week ago
<Noldorin> was tempted to port loggerhead to asp.net if anything :P
<Noldorin> but that's almost as crazy an idea
<Noldorin> so meh
<Noldorin> i'm off now anyway
<Noldorin> thanks anyway
<Noldorin> bb
<Peng> zsquareplusc: Something is wrong if it's saying "Not a branch".
<zsquareplusc> well it probably looks for a bzr repo, but its an svn server
<Peng> zsquareplusc: Yes, but if you branched, you have a bzr branch.
<Peng> zsquareplusc: Wait wait. I misunderstood.
<Peng> zsquareplusc: I thought you meant it was saying your local branch was not a branch, not the remote URL.
<zsquareplusc> yes thats right. bzr branch from a svn repo creates a bzr brnach with the full history
<Peng> I should log off of IRC when I'm this tired.
<zsquareplusc> i was able to make local changes in bzr and i was able to push to the svn server.
<zsquareplusc> but now the svn servers has new revisions and i'd like to upgrade my bzr branch with these
#bzr 2009-12-06
<nono0> I'm getting this error Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<nono0> on my server
<nono0> when I push a project from my devmachine to the server
<nono0> server is older ubuntu or debian
<nono0> How can I push a project in lower bazaar format?
<nono0> anybody here?
<nono0> bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<maxb> nono0: Well the obvious question... are you using bzr 1.6 or better
<nono0> i installed via backports
<Peng> nono0: That's not an answer.
<nono0> the newest
<nono0> thanxs for helping
<Mannan> Hi, I have a bazaar v2.0.0 running on ubuntu server(8.10) and i am trying to checkout bazaar from external network(outside) using the following command.
<Mannan> bzr co bzr+ssh://username@domainname/repository-path project-name
<Mannan> after connecting, it is hanging at the middle stage and appearing like[############/ ] 119KB 31KB/s Fetching revisions: Inserting stream
<Mannan> I have ufw firewall running on my ubuntu server and allowed SSH,HTTP,HTTPS ports....I am able to do checkout internally, but, if i try checkout from external it gets hanging..is any default bazaar port there?...Do i need to allow any other ports add into my ufw firewall...
<Mannan> is any body there reply.....
<fullermd> Well, I'm not really here, I'm running out the door.
<fullermd> But the ssh port is all bzr+ssh needs.  Are you sure it's hung, and not just working hard at something?
<fullermd> That's a common symptom if it's trying to convert revs to a different format on the fly; e.g., if you init-repo'd (and created a 2a repo) locally, and are branching into it from a branch that's in an older format.
<fullermd> If that's the case, try checking it out outside a repo.
 * fullermd scoots.
<Mannan> s..its getting hang at the middle
<Mannan> but, if i turn off ufw , then, i am able to chekout externally
<Mannan> but, how its working internally
<Mannan> even if i turn on ufw firewall
<Mannan> r u there fullermd?
* poolie changed the topic of #bzr to: Bazaar version control  | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | Helping with patches: vila
#bzr 2010-12-06
<bignose> I have a Bazaar checkout from a Git repository
<bignose> and then a Bazaar branch from that.
<bignose> but the branch fails to âdiffâ or most other commands:
<bignose> $ bzr diff
<bignose> === modified file 'po4a/po/devscripts.pot'
<bignose> bzr: ERROR: Revision {('po4a/po/devscripts.pot', 'git-v1:343d00558577b9bc12c381850cdb804658547bb8')} not present in "CHKInventoryRepository('file:///home/bignose/Projects/debian/devscripts/.bzr/repository/')".
<bignose> the traceback from the log file is at <URL:http://pastebin.ca/2011597>
<spiv> bignose: possibly the same as https://bugs.launchpad.net/bzr-git/+bug/649531
<ubot5`> Ubuntu bug 649531 in Bazaar Git Plugin "mesa incremental import fails with bzrlib.errors.RevisionNotPresent" [Medium,Triaged]
<spiv> bignose: probably needs jelmer to diagnose it
<spiv> If it's an import originally from an older bzr/bzr-git, then *maybe* making a fresh import would help.
<bignose> spiv: how about if I just upgraded the repository from rich-root-pack to 2a format?
<bignose> it's a shared repository. should it be enough to blow away the checkout and get it again, or will I need to trash the whole repository?
<spiv> The whole repository, it's a problem in the repository, not the checkout.
<spiv> Upgrading shouldn't resolve the problem, upgrading can't fill in the missing data.
<spiv> It just copies the records from the old format into the new format.
<bignose> okay, thanks. I'll try it.
<spiv> If you do make a new import, I'd definitely suggest making it in 2a format though :)
<spiv> My guess is its a bzr-git bug.
<bignose> yes, my Bazaar is new enough to make 2a format by default :-)
<bignose> the repository is a couple of years old though.
<bignose> s/is/was/  blown it away now and starting afresh.
<bignose> spiv: fixed, thank you. whatever the problem was in the old repository, it's gone now.
<spiv> Glad I could help.
<glyph> spiv: My blog post got absolutely no reaction!  I guess the problem is not as common as I thought :-)
<spiv> glyph: That seems about right to me :)
<vila> hi all !
<vila> spiv: did your patch about the uninitialized https socket got merged upstream ?
<poolie> hi vila
<vila> poolie: hey !
<vila> poolie: did you get any news from Gary ?
<poolie> not recently
<vila> I noticed that we have ~35 New bugs in the 'bzr (Ubuntu)' project, I haven't checked which ones are really packaging ones but I think we should have a look there (I think there is still no way to just re-affect them to 'bzr' itself).
<poolie> correct, you can't mark them against only upstream :/
<vila> I mailed him last week but got no reply :-/
<spiv> vila: I don't even remember that patch...
<poolie> you can make them either invalid or just leave them open and then close when they're finished
<spiv> vila: oh, yes I do
<vila> spiv: the one that takes care.. :)
<vila> poolie: I meant, bugs that are not targeted at 'bzr' itself and as such unknown to us
<spiv> vila: and it was merged upstream, and the patch added to the ubuntu package too
<vila> spiv: really ? Great ! Which python version ?
<poolie> vila, i know, i'm just talking about the options after we look at them
<poolie> i thought i was subscribed to ubuntu/bzr
<poolie> we could probably do with a poll every so often to clean them out
<poolie> my laptop filesystems died again on the weekend :/
<poolie> i think the SSD is dying
<spiv> vila: 2.7 I believe.  http://bugs.python.org/issue9729
<vila> I still encounter it at least on jaunty and osx recently and wanted to work  around it (it occurs during client shutdown so we can catch the TypeError exception without too much risk)
<vila> spiv: thanks
<vila> poolie: urgh, that sucks
<vila> poolie: how old is it ? Do you have /tmp or swap on it ?
<poolie> it's about 18m old
<poolie> i did have a swap partition, because otherwise there is too much of a cliff when you run out of ram
<vila> weird, mine is far older than that and I had /tmp on it for months before realizing it
<poolie> but i had /tmp in a tmpfs, and atimes turned off etc
<poolie> it's still showing 97% erase life left
<poolie> however, reading the error logs give a checksum error, which some people think means the controller is failing
<vila> ouch
<poolie> so, i'm going to try to return it under warranty, and if they won't swap it i'll stick with the magnetic disk
<poolie> that originally came in my laptop
<vila> 97% erase like left ? Where do you get that ?
<poolie> 'smartctl -A /dev/sda' shows (at least on this drive) that, amongst other things
<vila> I don't even this command :-/
<vila> Oh, from the smart data ?
<vila> ha yes, endurance remaining: N/A, I guess mine is too old to even implement that...
<vila> in fact, everything is N/A, all I have is: 'Disk is healthy'... I'm glad I asked...
<vila> :)
<vila> having another look at these 'bzr (ubuntu)' bugs: 35 New, 70 Open...
<vila> I am subscribed though as many of them rings a bell, it's just that I forget about them because I never see them again when going to lp...
<lifeless> vila: does the link in the UI help ?
<vila> lifeless: which one ?
<vila> lifeless: 'also affects project' ?
<vila> my problem here is that I didn't realize these bugs were existing as I always look at the 'bzr' bugs on lp, never at the 'bzr (Ubuntu)' ones, so they are abandoned
<vila> that's not as bad as I thought, though, many of them are targeted at both
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.copingeling aboutm/ | Patch pilot: vila | 2.3b4 is frozen, installers build time ! (rm vila)
<lifeless> vila: vila the link at the top of https://bugs.launchpad.net/bzr
<lifeless> "Ubuntu also tracks bugs for packages derived from this project: bzr in ubuntu."
<vila> ooooh, shiny, yup, exactly, thanks
<sobersabre> hi. I have bzr repository of version 2a on machine A
<sobersabre> and I have a machine B with older version of bzr installed.
<sobersabre> should I expect any problem by pulling the machine A's repo to machine B ?
<sobersabre> would bzr manage to do the conversion from 2a to 1* ?
<bob2> how old is it?
<sobersabre> bob2: let's speak in bzr versions.
<bob2> so 'absurdly'? :)
<sobersabre> the 2a one has version of bzr  2.3b1
<sobersabre> the older has bzr v 1.5-1.1
<spiv> sobersabre: bzr can convert from 2a to some older formats, the oldest compatible one is rich-root-pack which was introduced in bzr 1.0.
 * sobersabre has 'absurdly' missed the humor. would still like an explanation.
<mwhudson_> that's pretty old
<spiv> Obviously you need to use a bzr new enough to read 2a to do the conversion :)
<sobersabre> so, shall I maybe install a backport of 2.x for lenny ? is there one ?
<sobersabre> spiv: maybe you're so close to 2a, it is obvious for you. but it is sure not obvious for me.
<sobersabre> I mean internal repo structure is one thing, and pulling it via an API is another... which is obvious for me.
<spiv> Basically "bzr init-repo --format=rich-root-pack repo-for-bzr-1.0; bzr branch your-repo/foo repo-for-bzr-1.0/foo"
<sobersabre> and incidentally both API and the repo structure can collide. only incidentally..
<spiv> sobersabre: I don't quite follow you.
<sobersabre> I mean the bzr operation doesn't have to expose repository structure AS IS to the bzr puller.
<sobersabre> and API can be transparent to the internal structure.
<sobersabre> so this would allow interoperability between various versions of bzr pullers.
<spiv> sobersabre: I'd expect e.g. MS Word 2010 to be able to read MS Word 2010 format docs, and save them as MS Word 2007 format.  But I wouldn't expect MS Word 2007 to be able to do that.
<sobersabre> still not with me ?
<sobersabre> spiv: you are the one who started with "obvious"ities. :)
<sobersabre> I gave you mine.... ... ...
<sobersabre> anyway.. thanks, It's good I asked.
<spiv> I don't know what you mean when you say "bzr operation" and "bzr puller", especially when you talk about them as separate things.
<vila> sobersabre: in theory yes, in practice no, if you try to pull from a branch/repository in an unknown (to your local bzr) format, bzr shold tell you (the format string includes the minimal bzr version needed)
<vila> sobersabre: i.e. : Bazaar repository format 2a (needs bzr 1.16 or later)
<sobersabre> spiv: I must explain: let's call the machine I'm pulling from "S" (source), and the machine I'm pulling to "D" (destination).
<sobersabre> if S has bzr 2.3 and D has bzr 1.5, we have "a situation".
<sobersabre> unless user specifies instruction to his bzr to do something special.
<sobersabre> instead it would be transparent to develop a "sharing API", i.e. something with no regards to repository structure, but rather to files, revisions, comments, without the bits of which storage, which fs is used, etc.
<sobersabre> and it would render bzr to be less cumbersome for its users.
<sobersabre> look at me - I'm spending about an hour or two to make sure I manage to pull :) maybe I should've pulled with error already....
<vila> sobersabre: this works as long as both bzrs know enough about the format used... and that's what bzr does
<spiv> sobersabre: well, use an older format that both bzr versions have in common.
<spiv> sobersabre: in this case rich-root-pack.
<vila> sobersabre: for new formats, old bzrs should give the right messages, if not that's a bug... hopefully fixed in newer versions :-P
<spiv> sobersabre: there are more complex possiblities, like using export/import tools.
<vila> sobersabre: if I read http://packages.debian.org/search?keywords=bzr correctly, lenny-backports should give you 2.0.3 which is good enough to handle 2a
<vila> sobersabre: I'm not a debian expert by far though :)
<vila> sobersabre: we try to preserve backward compatibility as much as we can, but we also want to make bzr better, so far all formats ever used by bzr can still be read by the current bzr. We only remove support for some development formats recently but these ones were highly publicized as being supported for a short period of time and the migration to the supported formats as always been implemented. Just mentioning that we *do* care about compa
<vila> tibility and interoperability.
<vila> that sentence was too long :)
<fullermd> It didn't have any good tpyos in it either.  Two strikes.
<vila> :)
<sobersabre> guys, thanks, I'm just a bit trolling. don't take it too seriously. I'm not a seasoned bzr user. still picking up it's bzr-speak.
<vila> sobersabre: no problem :) Self-proclaimed trolls are ok ;) As long as we can help you find your way, feel free to ask !
<mgolisch> does bzr support kerberos authentication?
<jelmer> mgolisch: only over ftp
<mgolisch> too bad
<jelmer> actually, http might work too
 * jelmer recalls working on it but isn't sure whether it actually landed
<mgolisch> basicaly id like to host stuff in a bzr repo, provide some shiny webinterface for browsing the branches/projects and somehow enable sso authentication
<mgolisch> so youd not have to type a password all the time
<mgolisch> managing ssh keys seems like a pain in the butt
<vila> mgolisch: ssh agents *are* the best sso engine I know of ;) You should try them IMHO
<mgolisch> that still requires generating ssh keys
<mgolisch> and to deploy them to the users
<vila> But they allow defining a single user on the server reducing the maintenance to a single file there (containing the allowed ssh keys)
<mgolisch> how would i differenciate between them then?
<vila> by their ssh key ?
<mgolisch> oh yeah
<mgolisch> whatever guess thats what ill do then
<vila> ftp is not the best protocol for bzr as far as performances are concerned too, using a smart server scales far better
<vila> mgolisch: you can have a look into the crontrib directory for bzr_access and bzr_ssh_path_delimiter for various approaches at finer grained control access too
<mgolisch> is there some easy way to predefine the host it tries to connect to?
<vila> you mean in a centralized workflow ?
<mgolisch> or defining somekind of shorthand/shortcut notation like with launchpad?
<vila> yes you can, the simplest being via the bookmarks plugin (lp:bzr-bookmarks)
<mgolisch> there will only be used that one server anyways, its for inhouse development of apps and scripts and whatnot
<mgolisch> so id would be easier of the users would not have to type the full repository url all the time
<vila> you can also have a look at the launchpad plugin itself (in bzrlib/plugins) for a more sophisticated approach, that's where the lp:, ubuntu: and debian: shortcuts are handled (in lp_directory.py specifically)
<mgolisch> cool ill look into that
<vila> mgolisch: but note that they need to type the full URL only once, bzr will remember it from there
<mgolisch> thx alot
<vila> well, once for branch/chekout/push/merge, i.e. once for every operation that will need to use the same URL repeatedly (look for the --remember parameter in the commands)
<vila> the first command use remembers the URL provided so you don't have to specify it for further incantations
<vila> mgolisch: 'bzr info' will summarize the urls already known in a given branch
<piranha> hi. Is it possible to downgrade 2.0 format to 0.92 format?
<piranha> I thought about exporting patches as text and then applying it to newly created repository, but I can't find how to create text patches...
<spiv> piranha: no, although you can downgrade to rich-root-pack, which works with bzr 1.0
<piranha> hm, ok, I'll try
<piranha> eh
<piranha> spiv: this doesn't work, my server wants 0.92 :(
<spiv> piranha: if you want to export/import, there's the fastimport plugin, but it will generate a new, unrelated revision history you can't merge from, etc.
<piranha> I don't care about merging for this repository, so ok, I'll try it
<piranha> thanks
<spiv> 0.92 is over 3 years old.
<piranha> I know
<piranha> I can't do anything about it :(
<spiv> That's a shame.  The 2a format is much smaller and faster :(
<piranha> heh, python-fastimport is registered on PyPI, but that's not possible to install it from there. That's dumb :\
<jelmer> piranha: the python-fastimport is not the fastimport plugin for bzr
<piranha> I know, but it is required by bzr-fastimport
<jelmer> right
<piranha> yahoo
<piranha> it worked
<piranha> spiv: thank you
<mgolisch> is there some way to get information about repositories on a dumb server?
<Peng> mgolisch: "bzr info" can take a remote location.
<mgolisch> like i know the base path is /bzr/ can i have a list of all directories found under that? or maybe even which of those are actual bzr repositories?
<Peng> mgolisch: If the dumb server supports directory listings (HTTP may not, since they're unstandardized pages), you can use the "bzr branches" command from the bzrtools plugin. If you want to find all .bzr directories or all repositories, it's simple enough to do via bzrlib in the python prompt.
<Peng> (Usual disclaimer: This is all six-month-old information. I haven't been paying attention recently.)
<mgolisch> thx
<mgolisch> thanks that bzr branches thing seems to do what i wanted
<mgolisch> thx alot
<mgolisch> wow theres a custom_url_schemes plugin
<mgolisch> that looks like exactly what i was looking for
<mgolisch> to get rid of those endlessly long sftp urls
<awilkins> Can you do the opposite of `bzr revert --forget-merges` ; ie, revert all the changes back to the HEAD of the merge-target without forgetting the merge status?
<Peng> awilkins: bzr revert .
<awilkins> Aha
<awilkins> Did the merge in git - bless it, one tree is the same as another to it, even if the user deleted all the files then put them back again
<Peng> Blasphemer. :P
<awilkins> Doesn't go over so well in Bazaar though - "AAARGHH, EVERYTHING is a merge conflict!!!11""
<mgolisch> sweet that custom_url_schemes thing seems to work
<mgolisch> now iam all set
<mgolisch> :)
<jam> morning all
<Peng> Good morning. :)
<jelmer> hi jam
<vila> morning jam !
<dobey> hi all
<mwhudson> hello dobey
<dobey> any idea why ssh would be held open when doing a bzrlib.branch.Branch.open() on a lightweight checkout?
<lifeless> opening a working tree opens its branch and repository objects
<lifeless> by design
<lifeless> a lightweight co is a working tree and remote branch and repo
<mkanat> dobey: There was a thread about it on the mailing list a little while back.
<poolie> hi mkanat
<poolie> hi jam?
<jam> hi poolie
<mkanat> Hey poolie. :-)
<poolie> hi there
<dobey> i mean, why it would get held open after the python script that imports bzrlib exits (causing a hang due to waitpid somewhere in bzrlib)
<jam> dobey: IIRC, paramiko uses background threads, there was also a recent bug about sftp connections not getting close
<jam> closed
<jam> dobey: bug #659590
<ubot5`> Launchpad bug 659590 in Bazaar 2.3 "dput sftp upload hangs after all files successfully uploaded" [Critical,Confirmed] https://launchpad.net/bugs/659590
<mkanat> poolie: I'm totally waiting on MPs, at the moment.
<mkanat> poolie: That is, on reviews.
<poolie> mkanat: oops, i'll try to unblock you, and i hope spiv can help too
<spiv> Good morning.
 * poolie moves it to the top of my list
<spiv> I can take a look too.
<mwhudson> huh, i can't approve https://code.edge.launchpad.net/~mkanat/loggerhead/launchpad/+merge/42338
<dobey> jam: interesting. thanks
<mkanat> There are two MPs I have up--one for loggerhead and one for the launchpad branch of loggerhead.
<poolie> mwhudson: me either; i guess only ~launchpad-pqm can approve them?
<poolie> (the rules here are a bit opaque)
<mwhudson> yeah, maybe the review team needs setting on the target branch?
<mwhudson> of course, launchpad code hackers can twiddle all of these things
<poolie> how?
<jam> phenominal cosmic powers
<jam> Would be my guess
<dobey> jam: hrmm, that fix doesn't seem to work for where i'm seeing the problem; but adding proc.terminate before proc.wait in the funcs list in _close_ssh_proc() does
<jam> dobey: that would indicate that the ssh session itself is expecting something to happen
<jam> killing it isn't the nicest thing, though I don't know *what* it is waiting for
<dobey> yeah me either
<spiv> dobey: hmm, I would have thought that closing stdin/stdout to the ssh process would be enough to encourage it to close cleanly.
<spiv> OpenSSH?
<jam> os.kill(SIGINT) would be nicer
<dobey> yes openssh
<jam> hey spiv
<jam> I was wondering if you'd get a chance to look at https://code.launchpad.net/~jameinel/bzr/2.3-commit-to-stacked/+merge/42698
<spiv> jam: I glanced at it very quickly last night :)
<spiv> jam: It's smaller than I thought it would be!
<jam> yeah, same here
<jam> basically, we already had "fill in parent inventories" verb because of stacking
<jam> just needed to use it at the right time
<lifeless> \o/
<spiv> I vaguely recall thinking that would be a cheap way to fix that bug, then hitting some problem that stopped me from doing it.
<lifeless> hey
<dobey> spiv: any ideas why ssh would be waiting for something?
<lifeless> poolie: I have a wishlist for bzr
<jam> and the verb already handled stuff like needing chk entries, etc
<lifeless> dobey: do you have connection pooling on ?
<spiv> lifeless: oh, ew, good point :/
<jam> spiv: chained fallbacks are potentially a problem, so far it is working, but it feels like it shouldn't
<jam> so I'm investigating
<lifeless> dobey: a 'master connection' that is created implicitly blocks until all other connections have closed.
<jam> a bit hard to set up proper Remote objects in the test suite
<lifeless> dobey: terminating that connection hard will break all other connections (which will be through other processes)
<lifeless> poolie: I would deeply deeply deeply love to be able to show the content of a shelf
<dobey> lifeless: not as far as i know
<spiv> lifeless: I am really looking forward to OpenSSH 5.6's ControlPersist feature.
<spiv> jam: yeah, I can imagine.
<dobey> lifeless: but i presume not, unless it's a default
<spiv> dobey: it's not a default
<jam> spiv: urljoin(base, '../new') seems to work, since it forces the target to be on the remote url. But then you have to manually create a local lightweight checkout so you can commit, etc.
<lifeless> dobey: grep ControlMaster in ~/.ssh/config
<dobey> lifeless: it's not on
<lifeless> kk
<mwhudson> lifeless: unshelve --preview?
<dobey> does bzr dump ssh stdout/stderr to log/stderr?
<mwhudson> stderr, yes
<mwhudson> ssh stdout is the communication channel bzr is actually using
<mwhudson> i guess it's not so much that it dumps stderr either, it just doesn't do anything wrt stderr so it ends up on the terminal
<poolie> lifeless: 'unshelve --preview'+
<poolie> ?
<lifeless> ah
<lifeless> I miss the old ui
<spiv> Hmm.  I wonder if having a live stderr fd is enough to keep the ssh subprocess alive sometimes.
<lifeless> it had a query interface that felt more consistent
<lifeless> shelve --list + unshelve --preview feels odd
<spiv> I guess we really should try calling proc.terminate before proc.wait :/
<poolie> spiv: if the other end didn't close it, maybe
<mgz> proc.terminate is pretty rude on windows (and doesn't exist till 2.6 or something)
<spiv> mgz: yeah
<jam> spiv: problem is that proc.terminate() is SIGKILL as I understand it
<spiv> jam: no, it's SIGTERM on posix
<spiv> jam: but TerminateProcess on Win32, which is more like kill.
<poolie> lifeless: what's "the old ui"?
<spiv> I think it's reasonable to resort to SIGTERM after closing the fds we control
<jam> well, we are less likely to actually have a real spawned process on Win32, as well. so maybe .terminate is ok. Though IIRC, it is not available in py2.4
<lifeless> poolie: it was a subcommand ui rather than flags to make things behave differently
<jam> I think that is 2.5 or even 2.6
<spiv> Hmm, /topic looks a bit mangled
<spiv> jam: yes, 2.6 only
<dobey> hrmm, i added ssh -v; but nothing especially useful that i see, outside of it just being extremely slow
<mgz> jam has me on ignore!
<jam> mgz: well, not explicitly
<mgz> :P
<lifeless> poolie: bzr shelve/unshelve/shelf list/shelf show/shelf delete IIRC
<spiv> dobey: which server are you connected to?  Launchpad?
<dobey> yes
<spiv> Very odd then.
<lifeless> going direct or through an ssh proxy
<dobey> and by slow i mean "the ssh -v output is probably just off because it was 50 seconds until i killed the process"
<dobey> direct
<dobey> ie, only the screwy connection seems slow
<dobey> normal "bzr nick" is fast
<dobey> well as fast as doing anything with ssh -v is i guess
<spiv> dobey: I can't quite explain what's causing you to see this issue (when no-one else has reported it), but I think the proc.terminate workaround is probably a good idea for bzr (when running in a Python that supports it).  Please file a bug.
<jam> spiv: why for the RemoteRepositoryFormat-default permutation, is the remote repo a KnitPack6 format, and not a 2a format?
<lifeless> spiv: lsof might tell us
<lifeless> dobey: are you on natty?
<lifeless> spiv: also possibly an openssh change
<spiv> jam: for no good reason, probably
<dobey> lifeless: yes
<dobey> lifeless: but also seeing the same issue on lucid
<spiv> jam: possibly at the time it was hard to spell "default format" in that bit of the scenario-building code?
<spiv> jam: there's a bit too many parts of the test suite that explicitly select old formats that should probably use 2a :/
<jam> spiv: the scenario code that I can see just does "RemoteRepositoryFormat()"
<dobey> hrmm, i don't see 2.2.1 packaged for lucid anywhere. is it going to be in backports at all?
<spiv> jam: perhaps it's due to the test and not the scenario then?
<spiv> dobey: ppa:bzr/archive
<jam> spiv: thanks. per_repository_reference the permutation forces RepositoryFormatKnit6
<spiv> jam: ah!
<jam> per_repository just uses the default
<spiv> jam: that would be one of the "too many parts of the test suite"  :)
<jam> _reference customizeses it, presumably because originally we needed to
<spiv> jam: right
<jam> and if you just remove that, it breaks
<jam> self._ensure_real fails because self._custom_format is None, and repository.network_format_registry has no default key
<spiv> dobey: I think for lucid we intend to keep putting updates to bzr 2.1.x in lucid-updates.  I'm not sure if anyone is doing anything with putting bzr in the backports repository specifically, PPAs are a bit more flexible.
<spiv> jam: RemoteRepositoryFormat does need an explicit format set, IIRC.  It's not normally instantiated without there being an associated remote repo.
<dobey> ok
<jam> spiv: sure, but when *creating* one...
<spiv> jam: when creating a repo the client knows what it is creating...
<jam> spiv: the point of per-repository tests is to test against something which is remote. But it doesn't know what it is creating
<jam> at least, I can't find where in bzrlib/tests/per_repository/__init__.py it is setting the format
<jam> it is obvious in per_repository_reference/__init__.py where _custom_format is getting set
<spiv> jam: you mean it fails in external_reference_test_scenarios where it tests supports_external_lookups?
<spiv> jam: the difference is that per_repository scenario setup, unlike per_repository_reference, never interrogates the format instances about their capabilities
<spiv> jam: and you can't interrogate a RemoteRepositoryFormat with no network_name and no remote repo about its capabilities, because there's no remote repository to have or not have those capabilities.
<jam> spiv: then how does it call "initialize()" on them?
<jam> so, I'm still not sure how it knows about external, but otherwise I see your point
<jam> sorry, I don't know how it initializes
<jam> but I can see how calling 'support_external_lookups' would fail without a custom format
<dobey> spiv: https://bugs.launchpad.net/bzr/+bug/686224
<ubot5`> Ubuntu bug 686224 in Bazaar "Call proc.terminate before proc.wait when possible" [Undecided,New]
<spiv> dobey: thanks
<spiv> jam: because RemoteBzrDirFormat's initialize and RemoteRepositoryFormat's initialize do have default formats
<dobey> thank you for helping me figure out most of the problem at least :)
<spiv> (RemoteBzrDirFormat appears to hardcode BzrDirMetaFormat1, RemoteRepositoryFormat grabs the default format from the bzrdir format_registry)
<jam> spiv: so what you're saying is that while initialize() will fall back to bzrdir.format_registry.get(), ensure_real() will not
<spiv> jam: yes, and I think it's correct that ensure_real will not
<jam> anyway, I can find another thing to do here, thanks for the tip
<jam> anyway, the tests pass
<jam> just need to make sure I'm testing enough :)
<spiv> ensure_real should certainly fail if there's no real object!
<fullermd> Unless you mistype it as "ensur_real" maybe   :>
<spiv> fullermd: actually the method is â_ensure_realâ :P
<fullermd> Is it a virtual method?  :p
<mgz> it's an imaginary method.
<fullermd> That sounds pretty complex.
#bzr 2010-12-07
<mkanat> poolie: Hey there. Did you want to talk about loggerhead now? I'm available.
<poolie> mkanat: hi, i'm back
<poolie> btw i'll be offline tomorrow, and possibly not on irc friday
<poolie> i mean thursday
<poolie> australian time
<mkanat> Okay.
<poolie> <mkanat> Ah, well, removing the revision data by default from the file inventory.
<poolie> what does that mean?
<mkanat> poolie: So, one thing that I have pending is the raw view.
<mkanat> poolie: That's something that will probably benefit LP, somewhat.
<mkanat> poolie: Ah, when browsing a branch using /files, it shows you the revision and last-modified date of every file.
<mkanat> poolie: I believe (although I'd have to check) that we're generating that data from the branch history cache.
<poolie> the raw view would be nice
<mkanat> poolie: If we don't have to use a branch history cache at all on the most common page views, we should be able to get an impressive performance and scalability improvement.
<poolie> right
<poolie> it's kind of useful, but not necessarily worth it
<poolie> could we put make that configured off, rather than just deleted?
<mkanat> poolie: Yeah, I'd put a link on the page to show the info.
<j^> hi, wiki.bazaar.canonical.com/MacOSXDownloads points to a wrong place fort the 2.2.2 stable download
<mkanat> poolie: So people who wanted to browse with it could, but wouldn't get it by default.
<mkanat> poolie: It'd be "show revisions and timestamps" as a nav button.
<mkanat> poolie: Then after that I think there may be additional optimizations I can do on the View controller.
<mkanat> poolie: And with all of those things, I think that would be the ideal project size for this retainer.
<mkanat> poolie: I can see all of those going into LP.
<poolie> i agree, i think they're really useful and just a good size
<mkanat> poolie: Okay, great. So the first thing I'd need is a review on the MP for the raw view.
<mkanat> poolie: BTW, I don't know if you saw my comments here or in the bug, but the raw view renders in about 0.05 seconds.
<mkanat> poolie: So it's not bzr that's slow.
<poolie> i hadn't seen it
<poolie> that is interesting
<mkanat> poolie: Yeah, I didn't email you about my work on the raw controller, because I figured you would have noticed due to the review request.
 * mwhudson wants revert -i
<james_w> mwhudson, shelve --destroy IIRC
<mwhudson> james_w: huh!
<mwhudson> ta
<mwhudson> james_w: i'm writing some crazy matchers for linaro-image-tools btw :)
<james_w> nice
<mwhudson> you say that before you've seen them
<mwhudson> :-)
<poolie> that'd be nice
<mkanat> poolie: This is the MP I'm blocked on right now: https://code.launchpad.net/~mkanat/loggerhead/raw-controller/+merge/42675
<poolie> thanks mkanat, i'll look now
<spiv> poolie: then I'll look at reviewing any loggerhead bits mkanat has that still needs reviewing
<poolie> ok
<poolie> i was going to pass through that, then restore /home onto my laptop again :/
<poolie> spiv i don't see any other fresh lh mps
<poolie> there are stale ones but i think that should wait til someone wants to handle this in batch
<poolie> if you have anything to add on xss prevention please do
<spiv> Hmm, we have a test that verifies that bzrdir.sprout(url) will copy all revisions in the source repository, even if most of them aren't referred to by the branch at that bzrdir.
<lifeless> spiv: no
<lifeless> spiv: thats the branchless case
<spiv> lifeless: no, there is a source branch in this case
<lifeless> hmm
<spiv> (at 0/null:!)
<lifeless> 'odd' :)
<spiv> test_sprout_bzrdir_repository_branch_only_source_under_shared
<spiv> Yes, I think it's probably a behaviour to change, but it seems intentional :/
<lifeless> what did my commit message say ? :)
<lifeless> gotta run
<spiv> lifeless: see you, try not to think about work :P
<vila> hi all !
<vila> spiv: wow, thanks for mentioning that bug #637821 has been back ported to maverick, I was chasing my tail trying to reproduce it :-}
<ubot5> Launchpad bug 637821 in python2.6 (Ubuntu) "Unconnected SSLSocket.{send,recv} raises TypeError: 'member_descriptor' object is not callable" [Undecided,Fix released] https://launchpad.net/bugs/637821
<echo-area> http://savannah.gnu.org/maintenance/UsingBzr   <--  Is the initial import method in multi-branch v2.1 wrong?  I think the first command should be bzr init-repository bzr+ssh://YOU@bzr.sv.gnu.org/YOUR_PROJECT
<vila> echo-area: instead of testyten ? Yes, that looks like a typo
<vila> echo-area: If you're able to update this page, it would be nice to mention that the 'bzr new' command is from the bzr-explorer plugin, not part of bzr core itself
<poolie> hi vila, bye vila
<echo-area> vila: Unfortunately I can't update that page.  Btw, is bzrtool in bzr core?
<vila> echo-area: no, it's a plugin too
<vila> poolie: hi there poolie :)
<vila> Did I just repeat myself or did I just repeat myself ?
<echo-area> vila: Is there a command in core that behaves the same way as the branches command in bzrtools?
<fullermd> vila: Yes.  I mean no.
<vila> echo-area: wow, the tricky ones now.... I don't think so, but there are discussions about providing the same sort of facility in core, no ETA for this though
<echo-area> vila: Oh I see.  Thanks for the info :)
 * vila starts reviewing fullermd's upgrade mp
<vila> fullermd: This doesn't take stacked-on branches into account right /
<vila> ?
<fullermd> In what way?
<fullermd> I guess you mean branches in the repo that are also stacked on something elsewhere?  No, I don't think it takes any cognizance of that.
<vila> No, I meant stacked branches that suddenly are unusable because their stacked-on repo has been upgraded
<vila> fullermd: let me find the relevant bubg
<fullermd> Oh.  Well, there's not much we can do about that one way or another, since who knows what might be out there.
<vila> I don't mean upgrading them automatically but provide a way to upgrade them knowing that they are in a broken (but identifiable) state
<vila> bug #682719
<ubot5> Launchpad bug 682719 in Bazaar "bzr upgrade should accept a --stacked-on parameter" [High,Confirmed] https://launchpad.net/bugs/682719
<fullermd> No, I don't expect this touches it one way or another.
<vila> fullermd: thanks, I thought so but wanted confirmation
<fullermd> Wouldn't you want reconfigure --stacked-on?
<fullermd> (or some alteration thereof.  Though, what with Launchpad Black Magic(tm) being involved, who knows...)
<vila> fullermd: haha, wanting to re-introduce leaks you are ! from bzrlib.transport import get_transport is evil ! (There is a workaround in place against it though, mgz, look at that ;)
<fullermd> You give me way more "knowing how anything works" credit than is deserved   :p
<vila> fullermd: hmm, and I suspect reconfigure would blow up encountering a broken branch, but that's worth checking
<fullermd> All I did was merge it up to date with bzr.dev changes and try filing off one or two corners seemingly unaddressed from poolie's review.
<vila> fullermd: hehe, no, my secret plot is to drag you into writing failing tests using our new shiny facility ;-P
<fullermd> Oh, you want to make things BREAK!  I can do that!
<vila> . o O (Pfew, here I was pesting against myself about leaking secret plots... It turns out it could be good idea finally ;)
<mgz> what a shame, I missed all the australians.
<vila> mgz: no worries ;)
<spiv> Hmm, I only have 2000 lines of diff in the review queue.  Still not beating garyvdm...
<jelmer> :_)
<lamalex> Hi, I'm trying to set up tarmac to run in a chroot and I'm getting bzrlib.errors.SSHVendorNotFound: Don't know how to handle SSH connections. Please set BZR_SSH environment variable.
<lamalex> What do I set that env var to, or is there a better fix
<lamalex> that var doesn't seem to be set outside of the chroot either, but bzr works fine
<vila> lamalex: hmm, this probably means you neither paramiko nor openssh available in the chroot ?
<vila> s/you neither/you have neither/
<lamalex> vila, ah! yeah probabl
<vila> maxb: looks like python-testtools is now in main for natty, it's only 0.9.2 but that should be enough for bug #659590 no ?
<ubot5> Launchpad bug 659590 in Bazaar 2.3 "dput sftp upload hangs after all files successfully uploaded" [Critical,Confirmed] https://launchpad.net/bugs/659590
<maxb> vila: erh, no
<maxb> Because 2.3b4 requires 0.9.5, no?
<maxb> !info python-testtools unstable
<vila> rhaaa, grrr, damn
<vila> right, so how do we get there ?
<ubot5> python-testtools (source: python-testtools): Extensions to the Python unittest library. In component main, is optional. Version 0.9.4-1 (unstable), package size 52 kB, installed size 320 kB
<maxb> We need to ask lifeless to do ASAP the python-testtools update in sid he has indicated he will do
<vila> ha right 0.9.*4* is available (bzr-2.2.2 requires 0.9.*2*), my bad
<maxb> then we get 2.3b4 into sid
<maxb> and get both of them synced into natty
<vila> maxb: right
<maxb> and then we finally get on with a 2.2.2 SRU
<maxb> see this is why I like PPAs :-)
<vila> indeed :-}
<mgz> I don't see why testtools 0.9.5 is a requirement for a 2.2.2 release, but maybe my drop was at a bad moment for the context
<vila> 0.9.2 only is required for 2.2.2 but 0.9.5 is required for 2.3b4
<mgz> but why is 2.3b4 anything to do with 2.2.2?
<vila> wow, I stopped my matching at the first nick letter and wondered why maxb was repeating himself :)
<maxb> mgz: Because Ubuntu SRU policy says you need to fix a bug in natty before you SRU it to older releases
<vila> mgz: sooo, SRU requires that the bug is fixed ... He's so quick :)
<mgz> okay. yeay for policies.
<maxb> Fundamentally, what we're seeing here is yet more friction from the SRU process really not being intended to be driven by upstream releases
<vila> maxb: will you upgrade the beta ppa for 2.3b4 anyway ?
<vila> spiv: lp:~spiv/bzr/fetch-integration not proposed but still a pre-requisite ?
<spiv> vila: yes, it is just a merge of two prerequisites.
<spiv> vila: no interesting conflict resolution or anything :)
<vila> oh, lp:~spiv/bzr/sprout-does-not-reopen-repo  and lp:~spiv/bzr/fetch-spec-everything-not-in-other ?
<spiv> Yes, as the MP says :P
<vila> ha, sorry :( Was just checking thoroughly
<vila> trying to see in which order they should be reviewed
<spiv> vila: currently the order they have been submitted should work well :)
<vila> yeah, but the +activereviews order is different :-/
<vila> hence my confusion
<spiv> Oh?  On my +activereviews page my branches waiting to be reviewed are in the order I submitted them, at least atm.
<vila> got it
 * spiv -> zzz
<vila> lp:~spiv/bzr/fetch-spec-everything-not-in-other is targeted at jam instead of bzr-code hence it appears last to me in the 'Other reviews I am not actively reviewing'
<spiv> vila: oh!
<spiv> I'll fix that, *then* zzz
<vila> . o O (There should be a way to make him do even more while he sleeps....)
<spiv> vila: thanks for spotting that, I should file a bug on how resubmit works.
<spiv> But, not while I sleep :)
<dlee> Am I supposed to be able to use bzr join to pull a hitherto-unrelated tree into another tree?  I read bzr help join, but I thought I could do this anyway.  I get the error saying the two trees have the same root.
<vila> dlee: I think you need the tree to be inside the targeted one
<dlee> Oh, I previously moved the source tree there, something like mv ~/bzr/srctree ~/bzr/desttree, so now it's ~/bzr/desttree/srctree.
<dlee> My command, from ~/bzr/desttree, would be bzr join srctree
<vila> yes, and this fails ?
<dlee> yes
<dlee> bzr 2.2.0
<vila> bzr info ? (repo format in particular)
<vila> of both
<dlee> I had to do bzr upgrade in the dest, and I even tried upgrading the source also, no change.  (This project  started two years ago in a non-richroot format)
<vila> meh, and bzr doesn't tell you it needs richroot ?
<dlee> Both currently say format 2a (standalone because I unbound them before starting all this).
<vila> :(
<dlee> It did say that so I did bzr upgrade.  Hmm... did it upgrade to the wrong format?
<vila> 'bzr info' will tell you
<dlee> The relevant bzr info line says exactly   Standalone tree (format: 2a)
 * vila scratches head, the exact message is 'Trees have the same root' ?
<dlee> Yes.  And I believe the format I had before the bzr upgrade was pack-0.92
<dlee> Exact message for bzr join srctree:  bzr: ERROR: Cannot join srctree.  Trees have the same root
<vila> and the only occurrence of this message is after 'if other_tree.get_root_id() == self.get_root_id()'
<vila> and you're sure 'bzr info' in srctree also says 2a ?
<dlee> It does now, though I tried first while srctree was pack 0.92
<dlee> Exact command sequence was bzr join srctree (in desttree) (fail), bzr upgrade (dest), bzr join srctree (fail with same-root message), cd srctree, bzr upgrade, cd .., bzr join srctree (fail with same root).
<vila> could add a 'import pdb; import.set_trace()' after this test and pastebin the root ids ? It's in  bzrlib.workingtree.py search for 'def subsume'
<vila> s/could add/could you add/
<dlee> I'll keep that suggestion for reference and do it when I get a chance.  I'm on the clock for a project now, was just trying to reorganize three subprojects that turned out to relate more closely than expected into one tree.
<vila> dlee: ok,sorry about that :-/
<dlee> This means what I'm trying is supposed to work though, which is nice to know. :)
<dlee> Oh np and thanks very much for your time and assistance.
<vila> dlee: np, thanks for updaing gentoo to 2.2.2 ;)
<dlee> Lol if that's a suggestion I get it, but if not... different dlee?
<vila> ha, may be then :)
<dlee> Doug Lee here, blind developer of assistive technology stuff mostly.
<vila> oh, not it was fauli, why did I associate you with gentoo... aren't you involved there ?
<dlee> I know someone from there (Deedra - someone you know?), but not really otherwise.
<dlee> I used to hang out in the Freenode channel #wopn years ago.
<vila> no, I think it's related to bzr... sorry for the confusion
<dlee> np but thanks all the same :)
<vila> :D
<dlee> vila: URL for preferred paste manager here?
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<mgz> babune having a history page each node of the test tree is pretty neat.
<mgz> bzr having so many random failures on windows is less so...
<dejj> I had a brilliant idea this morning
<jelmer> hi dejj
<dejj> I thought I could use bzr to keep track of a large archive of my photographs
<dejj> hi
<dejj> large, like 1 gb
<jelmer> dejj: bzr doesn't do very well with large files at the moment, though there have been a lot of requests to improve that
<dejj> it would work nicely, if there was some repository format that only keeps track of, say a checksum instead the whole file
<dejj> is there something like that?
<jelmer> dejj: Then where would it get the file?
<dejj> there would be only the file. most operations like revert and even commit wouldn't work. however...
<dejj> since I keep another branch on an external harddisk, I could push and pull to/from there
<dejj> does this make any sense to you?
<jelmer> dejj: that sounds like what rsync does
<dejj> ^.^
<dejj> I should probably look this up now
<dejj> is there a TortoiseRsync?
<jelmer> not as far as I know, but I'm not really involved in rsync development
<dejj> shouldn't it be possible to have a bzr-rsync repository format?
<jelmer> dejj: I don't think that would help much. rsync is a tool for syncing files efficiently.
<jelmer> it doesn't help when dealing with those large files inside of bzr, and that's where the real problem is at the moment
<dejj> it's functionality would be almost trivial. it would simply transmit the whole file if it was changed
<dejj> for me, the archive is 1gb, but each file is about only 5mb
<dejj> (though the limitation you mentioned would be trouble if I had the brilliant idea to also sync my movies)
<dejj> is there some place where I can find out about repository format development?
<jelmer> dejj: if the files themselves are pretty small (e.g. 5 Mb) then the current formats should work fine.
<jelmer> dejj: Implementing a new repository format is non-trivial, see bzrlib.repository and bzrlib.versionedfiles
<dejj> it seems so. maybe I can start with some existing format and slash out most functionality
<fabio_kreusch> Hi there, I'm using bzr thought Apache + mod_python, but it is reaaaaaally slow
<fabio_kreusch> any thoughts?
<dejj> I just need it to not keep any revisions, including the current. some sort of even lightweighter-lightweight
<vila> fabio_kreusch: try using bzr+ssh to ensure that bzr is indeed the culprit
<vila> fabio_kreusch: and make sure you're using the 2a format too
<fabio_kreusch> my bzr server resides on a windows server =\
<fabio_kreusch> before switching to apache + mod_python, I was using the bzr server, which was ok
<vila> fabio_kreusch: well, so you did the experiment before :) Why do you blame bzr then ?
<fabio_kreusch> I had to switch to apache + mod_python because it was the only way I found to integrate with active directory
<fabio_kreusch> I'm not blaming bzr, I'm just trying to know if someone else has seen this before
<vila> fabio_kreusch: oooh, my bad, I misinterpreted 'is' :-/
<mgz> ...as I've recorrected myself on bug 686611 twice now I'm probably honour bound to fix it too.
<ubot5> Launchpad bug 686611 in Bazaar "`bzr add file1 file2` in non-ascii folder fails, but `bzr add file1` works" [Low,Confirmed] https://launchpad.net/bugs/686611
<vila> fabio_kreusch: from the top of my head, I would say you want to get in touch with awilkins
<vila> fabio_kreusch: also he doesn't seem to be online , so may be trying the mailing list will get you a broader feedback
<vila> mgz: I was wrong when I said I was right, but right when I said I was wrong ?
<mgz> that's about it.
<mgz> was green mac buildbots too?
<mgz> s/was/want/
<fabio_kreusch> vila: thanks!
<mgz> vila: what in practice does your mac do if you do `open('\xe4','w')`?
<vila> it opens a file named a with a weird accent
<vila> that emacs lists as %E4 as does the finder
<mgz> if you then do `os.listdir()` what do you get?
<mgz> okay, so it is a semi-reversible mangling.
<vila> 'locale' says LANG= LC_ALL= the rest is C
<vila> os.listdir says %E4 too
<mgz> great.
<vila> invalid NFD ?
<vila> mgz: note that my locale is unsual, let me try from a terminal
<mgz> if only pathconf actually covered all this stuff
<vila> ha different
<mgz> whaddya get instead?
<vila> open says '?' all the others agree on '%E4'
<Odd_Bloke> Hello all.  I've just tried to push a branch to LP and have hit http://paste.pocoo.org/show/301863/.  Any suggestions as to what's going on?
<mgz> that's fine, thanks vila.
<mgz> Odd_Bloke: upgrade your bzr version.
<vila> mgz: and the locale in the terminal is en_US.UTF-8
<vila> Odd_Bloke: aren't you running bzr behind an http server on windows ?
<vila> Odd_Bloke: known bug, fixed in recent versions, related to a proxy
<vila> Odd_Bloke: my question was unrelated to your problem by the way
<vila> mgz: thanks for the review !
<exarkun> Anyone have any suggestions for http://buildbot.twistedmatrix.com/builders/openbsd-current-sparc64/builds/4/steps/bzr/logs/stdio ?
<mgz> nothing I've seen, file a bug against bzr-svn exarkun.
<jelmer> hi exarkun
<exarkun> Hi jelmer
<exarkun> On a separate topic, as I was going to file a bug, I noticed on https://launchpad.net/bzr-svn that bzr-svn is licensed GPLv3?
<jelmer> exarkun: that should be GPLv2+
<exarkun> Makes a big difference, I hope you'll update the page soon :)
<mgz> svn is apache?
<jelmer> mgz: yeah
<mgz> might have to be v3 then?
<jelmer> exarkun: fixed
<mgz> depends how you use their code.
<jelmer> mgz: run-time link against it; bzr-svn itself doesn't include any svn code
<jelmer> exarkun: just curious, is there a particular issue with gplv3?
<jelmer> exarkun: any chance you can set BZR_PDB=1 and inspect the value of dirents ?
<exarkun> A few.  The one on which there is the least flexibility that some large companies with large legal teams have a policy forbidding the use of any GPLv3 software.
<jelmer> Apple :-/
<exarkun> what a lucky guess :)
<exarkun> I can ask the person whose host that is to try BZR_PDB=1, not sure if he's around right now though
<jelmer> exarkun: it's not reproducible locally?
<exarkun> no, nor on any of the other 5 - 8 machines that are running slaves for Twisted's buildbot
<jelmer> exarkun: I'm an upstream developer of Samba, and GPLv3 is apparently the reason they've stopped shipping newer versions of Samba.
<exarkun> This is the first OpenBSD machine
<jelmer> exarkun: ah. Is it running the Samba subversion version as the other hosts?
<exarkun> heh, samba. ;)  I'm not sure what version of svn it is running, I'll check on that too.
<jelmer> Urgh, the language center in my brain is thoroughly confused today. Sorry.
<jelmer> As you might've guessed I meant "same"
<exarkun> indeed :)
<lamalex> Can I commit just a chunk of a file vs. the whole fine
<lamalex> file
<lamalex> a la git commit --patch
<jelmer> lamalex: only by "bzr shelve"-ing the other changes first
<lamalex> jelmer, ok
<jelmer> lamalex: I think there might also be some "git add -i" like stuff in bzr-interactive, but I'm not sure.
<jelmer> exarkun: it'd also be interesting to know which subvertpy is in use on that machine
<jelmer> exarkun: it seems to be a problem in a lower layer, as bzr-svn is requesting the 'kind' info of all entries but not receiving it
<exarkun> jelmer: I filed https://bugs.launchpad.net/bzr-svn/+bug/686663 and pointed the operator of the machine to it, so hopefully he'll add some more details.
<ubot5> Ubuntu bug 686663 in Bazaar Subversion Plugin "bzr: ERROR: exceptions.KeyError: 'kind'" [Undecided,New]
<jelmer> exarkun: thanks
<maxb> vila: to answer question about 2.3b4 in PPA from some time ago. Yes, I'll do that. I was confused by the topic here. To me, "frozen" implies revision decided upon but no tarballs yet
<jelmer> s/frozen/feature frozen/ ?
<vila> maxb: no, frozen here means the tarball is out, yup as jelmer said
<maxb> 2.3 can be feature frozen, 2.3b4 is rather more than just feature frozen :-)
<vila> not only feature frozen in fact, commit frozen
<lamalex> How do I revert the changes made by a single that is not necessarily HEAD
<mkanat> lamalex: Reverse that patch and do another commit?
<LeoNerd> merge -r10..9    will revert the change that went from 9 -> 10
<lamalex> really?
<lamalex> weird
<lamalex> what an odd syntax
<vila> lamalex: that's a cherrypick, see 'bzr help merge'
<lamalex> bzr: ERROR: Server sent an unexpected error: ('error', 'requested revno (670) is later than given known revno (652)')
<lamalex> ?
<lamalex> bzr revno says 674
<vila> what command did you type ?
<lamalex> bzr merge -r671..760
<lamalex> er
<lamalex> bzr merge -r671..670
<vila> Are you using an up-to-date checkout ?
<vila> bzr st /bzr info would help understand your setup
<vila> ~paste
<vila> !paste
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<lamalex> http://pastebin.com/uc2n52nS
<lamalex> vila, and my working tree is not changed so st gives nothing
<lamalex> but thanks for that shortcut
<vila> meh, where is a server involved there >-/
<lamalex> yeah
<lamalex> that's what I'm wondering
<lamalex> it should all be working locally
<vila> ha ! silly me ! 'bzr merge' use submit_branch by default
<vila> so add a final '.' to your command to tell bzr you're merging from your local branch
<lamalex> ahh
<lamalex> thank you :)
<lamalex> not a very nice error message there
<vila> lamalex: indeed, file a bug explaining how you went into it (including the submit_branch trick)
<lamalex> yah
<vila> lamalex: and don't forget about the submit_branch trick... I keep falling into this trap after years of use :)
<soren> How can I show the log entires for revisions that are part of a pending merge?
<soren> It's rather annoying. In Openstack, I've added a unit test that checks if everyone who has a commit anywhere in the revision history is listed in the authors file, but right now the revision has to be committed before the check sees it.
<soren> So someone new can get a commit in without adding themselves to Authors, but the following attempt to merge somthing will fail, because now the previously merged branch is part of the "bzr log" output and thus lists the new contributor who isn't in Authors.
<james_w> soren, you want "bzr log" to include those things, or you are happy with querying for them separately?
<soren> james_w: bzr log would be simplest, but whatever does the trick is fine.
<soren> Simplest to consume, that is.
<soren> I don't know about implementation.
<james_w> it's possible to do it with some combination of "bzr st --show-ids" and "bzr log" I think
<james_w> IIRC there's no revspec for the pending merge(s)
<soren> bzr st --show-ids doesn't show the id's of the merge reivsions.
<soren> It shows the id's of the changed files.
<james_w> oh, I was pretty sure it showed the merge tips too
<soren> Not even with -v, no.
<james_w> I'm not sure how to get them without bzrlib then
<soren> http://pastebin.com/XxDT3pkF
<james_w> jam, any ideas?
<jam> james_w, soren: well, you can do "bzr status -v" to get more details, but I don't believe we expose that well outside of bzrlib
<soren> jam: that pastebin above is from bzr st --show-ids -v
<soren> jam: So no.
<soren> What I do now is just call subprocess.Popen(["bzr", "log", "-n0"]) and parse the output.
<jam> soren: well, you can see that Ryan Lucio did all of those pending merges, but it would only give you one author, etc.
<soren> Maybe someday when I grow up, I'll use bzrlib, but this works for now.
<soren> jam: It just doesn't solve my problem at all.
<jam> tree = bzrlib.workingtree.WorkingTree.open('.'); tree.lock_read(); parents = tree.get_parent_ids(); g = tree.branch.repository.get_graph(); for p in parent_ids[1:]: rev_ids = g.find_unique_ancestry(p, [parent_ids[0]]); revs = tree.branch.repository.get_revisions(rev_ids); for r in revs: r.get_authors()
<jam> something like that in bzrlib
<jam> not super terse, but if you are writing a plugin, it works well in a function
<soren> Bloody hell. It works.
<soren> With a few adjustments, but wow.
<soren> That's awesome.
<soren> s/find_unique_ancestry/find_unique_ancestors/
<soren> and
<soren> s/get_authors/get_apparent_authors/
<soren> and
<soren> s/parent_ids/parents/
<soren> (Just in case someone stumbles on this in an irc log and can't get it to work)
<soren> jam: Awesome, thanks so much!
<soren> That's just what I needed.
<jam> soren: happy to help
<soren> Is there a simple change to make it include not just the pending merges, but the entire history?
<soren> If not, that's cool. I just have to check both, so if they could easily be collapsed into one, that'd be even better.
<soren> I already have working code for the existing history, so I'm really fine.
<jam> soren: what do you mean entire history? I think you might want g.iter_ancestry(parents) but I'm not positive
<soren> jam: What I do now is parse the output of "bzr log -n0".
<soren> jam: The stuff it tells me about is what I call "the entire history".
<jam> soren: graph.iter_ancestry() is probably what you want then. Check the output format (gives tuples of (rev, parent_ids)
<jam> but it will give you the entire ancestry
<jam> including the pending merges
<soren> Fantastic.
<jam> though eventually that's going to get pretty slow
<soren> jam: Sorry, I'm completely new to bzrlib. Roughtly where does g.iter_ancesty() go here: http://pastebin.com/U6d95PvY  ?
<soren> Line 6-ish? 8-ish?
<soren> 6-ish, /me thinks.
<jam> soren: http://pastebin.com/e0Cg9dWn
<jam> well, that should be rev_ids = ...
 * soren takes it for a spin
<soren> bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///home/soren/src/openstack/nova/.bzr/repository/') has no revision null:
<soren> Hm... The 1787th entry in rev_ids is 'null:'.
<soren> Filtering it in the list comprehension works.
<soren> jam: Is "null:" supposed to be there, or is that a symptom of something?
<jam> soren: 'null:' is the end
<jam> the root-of-all things
<soren> jam: Ok. I'll just filter it out.
<jam> it is bzrlib.revision.NULL_REVISION
<cody-somerville> Would folks recommend bzr-pipeline or bzr-looms for managing patches against an upstream source?
<soren> jam: This is really great stuff. Thanks a lot!
<jelmer_> cody-somerville: I personally prefer bzr-pipelines because they don't require a custom branch format, but I must say I don't have a lot of experience with bzr-loom.
<mwhudson> jelmer_: hi, do you read private messages? :)
<jelmer_> mwhudson, hey
<mwhudson> jelmer_: i was going to say, thanks for packaging pydoctor
<jelmer_> mwhudson: yes, but that's my client at home.. I'm out at the moment :-)
<mwhudson> jelmer_: and also, do you have any opinion on https://code.launchpad.net/~wes-turner/pydoctor/setuptools/+merge/35221 ?
<mwhudson> jelmer_: aaa
<jelmer_> mwhudson: np, this will hopefuly make some Samba developers very happy :-)
<mwhudson> jelmer_: i don't have any real opinion on setuptools, being able to pip install would be nice i guess, but would it affect your packaging?
<jelmer_> mwhudson: it would I have to add another build dependency, but that's not a problem
<exarkun> make it optional please
<jelmer_> mwhudson, alternatively it could perhaps fall back to distutils?
<mwhudson> exarkun, jelmer_: okay
<bitmonk> howdy folks.  at http://wiki.bazaar.canonical.com/ForeignBranches/Subversion#mac-os-x it says there are dmg of bzr-svn, but I only see them up to 0.4.15.. has that been abandoned?
<jelmer> bitmonk: bzr-svn is included in the main dmg these days
<bitmonk> ah, sweet.
<bitmonk> thanks. :)
 * maxb thinks we should stop referencing specific versions of anything on the wiki :-)
<bitmonk> +1
<jelmer> maxb: yeah :-)
 * jelmer fixes the wiki
#bzr 2010-12-08
<achiang> hello, i'm reading the man page for bzr merge and find it a little confusing. let's say i have r1, r2, and r3. i want to revert r2, obviously keep r1, and am ambivalent about r3 (it can stay, i don't care). do i want bzr revert -r r2, or do i actually want merge . -r r2..r3 ?
<spiv> achiang: "revert" is a command to revert the working copy back to the a checked in version.
<spiv> achiang: to undo a committed change you need merge
<achiang> spiv: oh hm. sorry, i am using git terminology; i should have studied the bzr man page a little more
<spiv> achiang: specifically, to undo the changes in r2
<spiv> achiang: you'd do "bzr merge . -r 2..1"
<spiv> achiang: note the backward revision range, because you want to reverse the change :)
<achiang> spiv: hm, what happens to r3 in that case?
<spiv> Nothing.
<spiv> It's a cherrypick.
<achiang> ok. i'll try that
<spiv> It doesn't add a pending merge to the working copy, it is like a more convenient and robust version of generating a diff of that revision and applying it backwards.
<achiang> ok, i just did that, and here is some sample output: http://pastebin.ubuntu.com/540859/
<achiang> why does the merge message tell me that debian/changelog was modified, but bzr status does not?
<fullermd> You missed the '.' in the merge command line.  You want to 'merge' from the local branch, not the parent.
<achiang> ugh
<fullermd> (it MAY be the same rev of course, if both branches are up-to-date identical)
<fullermd> The merge message probably means whatever that rev range is made a change to the chanelog, but the end result was the same as what you already have.
<achiang> oh, ok. i can buy that explanation
<achiang> thanks spiv and fullermd
<achiang> btw, i know you must hate comparisons to git, but this is one operation i find to be much more conceptually straightforward in git. i just did a quick google of 'svn revert' and realize bzr has similar behavior, but perhaps our man page could be improved?
<maxb> achiang: Educate us, how does this work in git? :-)
<achiang> specifically, in the 'bzr merge' page, the line that says, "To merge the changes introduced by 82, without previous changes:"; might be nicer to say, "To drop the changes introduced by 82..."
<achiang> maxb: git revert <revspec>
<fullermd> maxb: 'git revert X' ~= 'bzr merge -rX..last:X . ; bzr ci'
<maxb> hmm
<achiang> maxb: git reset is the equivalent of bzr revert
<fullermd> git reset is sometimes bzr reset, and sometimes uncommit, and sometimes pull --overwrite.
<achiang> and again, i know the primary use case is probably svn users, so i'm not trying to point fingers or anything...
<achiang> but i did try to read the merge man page after someone pointed me at it, and i don't think i would have figured out how to actually drop my change without asking
<fullermd> achiang: That example line isn't talking about reversing changes, it's talking about a cherrypick merge.
<achiang> hm, perhaps i'm just especially dense. :-/
<fullermd> It's about "get the changes from just rev 82 of the other branch", not "reverse rev 82 of this branch"
<spiv> There have been some small tweaks to the merge help text in trunk.
<achiang> perhaps an example for "reversing changes" would be helpful then?
<fullermd> The 'revert' help actually mentions using merge for reversing stuff.
<achiang> fullermd: i dunno... i read that help and scratched my head for a while before asking here.
<fullermd> Second paragraph of the description.  At least in 2.2 and .dev; I don't have anything earlier right at hand, but I don't think it's all that new.
<achiang> right, i'm saying i stared at that 2nd paragraph and it didn't make any sense to me.
<achiang> and it's backwards from what spiv just advised me on
<achiang> modulo the fact that i forgot to include "." (my own fault)
<fullermd> No, it's the same, it's just using negative revnos rather than positive.
<achiang> wow.
<achiang> i had no clue
<spiv> I wonder if that example would be clearer if it didn't use negative revnos (even though saying "undo the 2nd last commit" is probably a pretty common use case).
<fullermd> I think of it as a good example of the meta- of the online help that makes me grumpy  :p
<fullermd> It's sorta quick-ref, except when it's sorta comprehensive-ref, except when it's sorta command-centric-tutorial, except when it's sorta general-tutorial, except when it's sorta buncha-examples, except...
<achiang> i mean, you could even keep the negative revnos, but just change the wording
<achiang> "For example, "merge . --revision -2..-3" will remove the changes introduced by second to last commit (-2), without affecting the changes introduced by the last commit (-1)"
<achiang> or something similar
<fullermd> We should use the word 'reverse' there.  'remove' implies the rev is gone, which isn't the case, and 'revert' creates confusion with the revert command.
<spiv> achiang: i.e. just be explicit about the meaning of -2 and -1?  Seems reasonable to me.
<fullermd> Or we could just add a 'reverse' command.  That would be a nice thin layer on merge...
<achiang> spiv: yes. i didn't realize those were negative revnos -- i just thought it was some weird convention passed to --revision
<spiv> achiang, fullermd: those tweaks sound good to me.  I'll make them now.
<achiang> spiv: thanks!
<spiv> fullermd: hmm, actually, I'm ambivalent about the using "reverse"
<fullermd> I'd half suggest using '-r' instead of '--revision' too.  On the one hand, being explicit and spelt-out is nice, but on the other, who ever actually types --revision?
<maxb> vila: 2.3b4 now uploaded to bzr-beta-ppa/maverick. I have a feeling it's going to fail the testsuite though, based on local experimentation
<spiv> fullermd: I think it may be as harmful as it is helpful to have yet another term for that added to the text.  Not sure.
<fullermd> Well, I don't necessarily mean a formal Term, just the choice of verb.  You could call it "constructing the complement", but I'm not sure that would be helpful either  ;)
<spiv> fullermd: sure.  My concern is basically that we should try to use as few different words for the same thing as possible, to avoid confusing new users that don't know all the nuances yet.
<fullermd> Oh, yes.  But I think using 'remove' or 'revert' or the like is worse, because it implies incorrect things.  You're not _removing_ anything, you're creating a new thing on top that's an undo.
<fullermd> But I'm half feverish at the moment, so I could be talking in Chinchilla or something for all I know...
<achiang> there you go... "to undo..."
<spiv> achiang, fullermd: https://code.launchpad.net/~spiv/bzr/tweak-revert-help/+merge/43036
<sqwishy> When people make pushes to my branch, file permissions seem to get modified under the .bzr directory so that files are owned by whoever made the push. Is that normal or is my configuration wonky?
<jmarsden> I just encountered a bzr crash, I reported it as bug #687266.  Anything else I can usefully do, or can anyone advise how to work around this? Running bzr 2.1.1-1 on Ubuntu 10.04.1
<ubot5> Error: Could not parse data returned by Launchpad: 687266 (https://launchpad.net/bugs/687266)
<spiv> jmarsden: install the bzr-loom plugin
<spiv> The error ought to be clearer, and say something like "Unrecognised branch format: 'Bazaar-NG Loom branch format 6\n'
<spiv> " though.
<jmarsden> spiv: OK, will do, but why is a plugin needed just to branch something from LP?  Is this a new requirement?
<jmarsden> Seems to have worked, thanks.  I'll update the bug report with this workaround.
<spiv> jmarsden: that branch has been created in the loom format
<spiv> So you'd have to ask the branch owner why they chose to do that.  (Although it is a pretty common plugin, I like it!)
<spiv> It's not a general requirement for branching from Launchpad.
<spiv> Just for branches in that format :)
<jmarsden> Ah, OK.  Good :)
<spiv> Kind of like how you can't branch from an SVN branch without the bzr-svn plugin ;)
<spiv> (Although of course LP doesn't host SVN natively)
<jmarsden> Well, sure... but crashing because the plugin is not there does not seem like reasonable error handling (or reasonable UI)
<spiv> Agreed, and I just updated the bug to say so :)
<jmarsden> I should have refreshed my lp page before adding a comment :)  OK, thanks.
<vila> grr why did libssl requires a reboot when upgraded oh why ?
<vila> mgz: You're reading above my shoulder again... Thanks for fixing the last remaining failures on OSX-10.5 :D
<vila> maxb: thanks for updating the beta ppa ! I don't get what you meant by 'fail the testsuite' though ?
* mthaddon changed the topic of #bzr to: Launchpad down/read-only from 10:00-11:30UTC for a code update | Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.copingeling aboutm/ | Patch pilot: vila | 2.3b4 is frozen, installers build time ! (rm vila)
<vila> fullermd: ping
<vila> sheesh, is he *sleeping* ? :D
<fullermd> No, just sick.
<jelmer> g'morning vila, fullermd!
<vila> jelmer: hey !
<vila> fullermd: oooh, may be you should... sleep then ? ;)
<fullermd> I'd love too.  I've tried on and off for the last 18 hours   :|
<vila> urgh, bad bad bad
<vila> booo for lp going offline ! Yeah for timely notices on my last page refresh !!!
<jelmer> :)
<maxb> vila: 2.3b4 is in PPA for maverick I'll do the other series today. it surprised me by passing tests
<vila> maxb: great !
<maxb> bash_completion tests must be being upset by my local environment
<vila> maxb: But I still don't get why you're surprised... haaaa
<vila> maxb: I almost never see them fail on babune, so yeah, you may want to investigate locally
<maxb> on the plus side, the ppa is now running all tests, not just --no-plugins
<vila> maxb: wow, that's... a very good news :)
<vila> http://babune.ladeuil.net:24842/job/selftest-osx-10.5/ BLUE !
<vila> mgz: kudos !
<mgz> yeay, a blue mac. now, why is 10.6 weird...
<spiv> A blue mac?  Aren't those like 15 years old? :P
<fullermd> That's why it took so long to get through the tests   :p
<vila> mgz: so, the doc_generate ones are due to a version too recent (I think)
<vila> the bzr_connect_to_bzr_ssh, well, I've stopped complaining about this test :(
<mgz> the bp.launchpad ones also look like some kind of installation issue
<vila> yeah probably, I should look into it and update the osx-installers requirements if that's the case
<mgz> so, six failures from setup things, and one from ssh hating us.
<vila> in the later case, it may well be an out of date paramiko (which is weird since we embed a patched one in the osx installer, but may be we don't patch the installed one)
<vila> which in turn would mean *I* patched the 10.5 installed one... I just love untracked admin tweaks...
<fullermd> You should get some kinda version control system to keep track of that stuff.
<vila> good idea !
<vila> The admins need to be lectured to use it though, which is the hardest part ;)
<fullermd> So mass executions it is, then.  I'll warm up my lawnmower.
<vila> weird, it seems launchpadlib is installed on 10.6 but not 10.5, so failing to import it on 10.5 masks the lazr.uri import error :)
<mgz> that sounds fine, not having it means some things don't run.
<mgz> but... launchpadlib should depend on lazr shouldn't it?
<vila> hrm, no I think the problem is that 10.5 has apython-2.6 installed on top of the system provided 2.5 and the later is used to build installers but the former is used to run the tests
<vila> that's *wrong*
<fullermd> It's not wrong, it's *agile*!
<vila> it should use the system-provided one or we're not tested what we should be testing %-)
<vila> s/tested/testing/
<vila> damn admins again
<vila> mgz: launchpadlib shouldn't assume that it has been correctly packaged
<mgz> hmmp...
<vila> hmm, I kind of require that babune slaves have bzr installed (if only for bootstrapping), so this issue is naughty: the launchpadlib shipped in the osx installers lacks lazr.uri (all of lazr in fact), so making the tests succeed requires: a valid setup, requiring a valid launchpadlib packaged in the installed bzr...
<mgz> hm. can you not unselect launchpadlib on install?
<mgz> something to work out with the mac installers at any rate
<vila> sounds like the fastest workaround, and I should discuss with doxxx why it included an incomplete launchpadlib there (which also requires a bunch of other stuff including simplejson, httplib2, oauth and whatnot)
<vila> lunch time here, bbl
<mgz> and I needed to leave ten mins ago.
<echo-area> I'm not sure this: Does bzrtools add color support for bzr shelve?
<echo-area> For I see colorful diffs after I installed bzrtools yesterday.
<vila> mgz: even simpler is to make the tests check for the required module: https://code.launchpad.net/~vila/bzr/687315-lazr-uri/+merge/43079
<vila> mgz: the ssh error on 10.6 is probably the paramiko bug involving ipv6 (it seems there is *no* way to disable v6 on lo0...)
<vila> mgz: so the alternative is to carry spiv's patch for paramiko in the OSX installers...
<mgz> I'm not convinced about the launchpadlib dependency thing, it's a deliberate pain to install because of that, if the mac installers work around and break it somehow, I think it's their bug.
<mgz> However, carrying a patched paramiko I thought they did already, and will become increasingly nessersary.
<vila> mgz: who is 'their' ?
<mgz> the mac installer.
<vila> mgz: yes, paramiko was patched but for the rng warning, not the ipv6 family (bug #579530)
<ubot5> Launchpad bug 579530 in Bazaar "paramiko does not try all available address families" [Medium,Confirmed] https://launchpad.net/bugs/579530
<vila> mgz: and the fix would be ?
<mgz> okay, that one should just be added to the bundle as well.
<vila> mgz: carrying more dependencies that are useless there ?
<mgz> ^personally, I'd remove launchpadlib, the windows installers don't include it because it's a pain in the bum.
<vila> mgz: I'm adding the paramiko patch right now
<mgz> people who want to use lp-propose can install seperately.
<mgz> otherwise, the dependencies need to be correctly bundled.
<vila> mgz: are you sure it's only for lp-propose ?
<mgz> and perhaps a couple of other neat little launchpad plugins commands one of the ABs added.
<mgz> aaron?
<mgz> you certainly don't need it to do basic lp interactions.
<vila> rhaaa doxxx where are you ? :D
<vila> and garyvdm... :-/
<hazmat> is there any way to have bzr pipeline commands execute a hook prior to moving to the prev/next pipe, i'd like to cleanup cached pyc files, as they cause spurious conflicts when stepping through the pipeline
<maxb> hazmat: erm, why would you have .pyc files under version control? Or do I misunderstand what you mean by conflict?
<hazmat> maxb, there not under version control, but if i have them in a directory added in one pipe, and switch to one where the directory doesn't exist, bzr complains that it can remove the directories because their not empty (due to the pyc files), and i have manually resolve the conflict
<hazmat> s/there/their
<maxb> ah, I see
<exarkun> hazmat: s/their/they're/ first ;)
<hazmat> exarkun, indeed :-)
<exarkun> I think I've had a similar problem with looms.  I haven't used pipelines yet.
<maxb> Hmm, so really you need a pre_merge hook
<maxb> I think the only thing you could do *right now* would be to wrap the switch-pipe command.
<maxb> A more general solution would be to put a pre_merge hook into bzr core, and then hook that
<hazmat> maxb, thanks, i think for now, i'll just hook,  PipelineManager.store_uncommitted to cleanup pyc files, its not elegant but it should solve the problem for me. a pre-merge hook looks like it would nicely as well.
<rjek> Hi.  Is there web-based branch viewer like Loggerhead or bzrweb that won't make me miserable trying to read Python backtraces while trying to work out why they don't work?
<Meths> launchpad does well at hiding traces and just telling you it doesn't work when it doesn't work. ;P
<vila> hazmat: you want to try bzr.transform.orphan_policy=move
<vila> hazmat: this requires bzr-2.3b2
<hazmat> vila, interesting that would work as well
<vila> hazmat: .pyc files are the primary target...
<achiang> hello, i have a question regarding bzr bound branches -- i can't actually tell if i want one or not. i'm trying to work with the desktop team's libgtk2.0 branch, so what i've done so far is: bzr branch lp:~desktop-team/gtk/ubuntu ; bzr branch -r <lucid revspec> ubuntu lucid
<achiang> that 2nd step created a bound branch for me (which i didn't realize until later)
<achiang> ok, so i go into lucid, make a trivial change to debian/changelog, and then try a debcommit
<achiang> now it complains about it being a bound branch
<achiang> i go to the wiki and read about bound branches
<achiang> and i can see that i can unbind my lucid branch
<achiang> but... honestly, i don't know what the right thing to do here is
<achiang> the idea is that i want to backport commits from the upstream 'ubuntu' branch back to this new 'lucid' branch that i created
<vila> achiang: the second step didn't create a bound branch, you probably did something else to get it bound
<vila> achiang: just 'bzr unbind' it until you need it to be bound
<achiang> vila: oops, you're right -- i did a bzr checkout, not bzr branch
<vila> achiang: *if* you ever need it to be bound
<vila> achiang: ha, then 'bzr help reconfigure', I think you want 'bzr reconfigure --tree'
<achiang> i'm just going to use the bzr branch command
<vila> achiang: and 'bzr info' before/after to better understand where you are
<vila> oh, if you can restart, then that's better
<achiang> yes, like i said, i'm just playing around right now and have only made a single trivial change
<achiang> vila: thanks for the help
<vila> achiang: happy to help (TM)
<knittl> why is log on a subdirectory slow as hell?
<jubei__> is there a way to use a specific ssh key that is not ~/.ssh/id_dsa with bazaar ?
<bob2> yes, configure it in ~/.ssh/config
<rjek> Hi.  Is there web-based branch viewer like Loggerhead or bzrweb that won't make me miserable trying to read Python backtraces while trying to work out why they don't work?
<rjek> bzrweb works to the extent that it can list the branches correctly, but then I get a meaningless backtrace from it when you try to visit a branch through it.
<rjek> And loggerhead appears to have no documentation for setting it up at all, but you do get a meaningless (to me) backtrace if you try to run the enticingly-named "setup.py"
<mgz> okay, so bzrlib.osutils.normalizepath is: ancient, undocumented, untested, and cruft-ridden
<mgz> I'd love to just delete it, but this needs to land on all version 2.0 and up.
<al`> hi all
<al`> I seem to be unable to use plugins reliably
<al`> or, at least, I cannot make work fast-import at all
<al`> error is: "bzr: ERROR: Unable to import library "fastimport": No module named fastimport"
<al`> however, ${PYTHONPATH}/bzrlib/plugins definitively contains a directory named "fastimport"
<mgz> and `bzr plugins` lists it?
<spiv> al`: I think the bzr-fastimport plugin relies on a python library called 'fastimport'
<spiv> al`: so that may be what it is complaining about.
<al`> yes
<al`> modular crap
<al`> of course, FreeBSD does not package this thing
<al`> so I'll have to build it locally
<maxb> I don't think it contains any compiled code, so the build should be trivial
<al`> still
<maxb> still?
<al`> I should not have to get 15k different module to do what I'm doing
<al`> that should be all shipped with bazaar, with minimal external dependency
<al`> hopefully this will be my only contact with bazaar, ie. once this work, I'm going back to git
<spiv> I wonder what al` is doing.
<maxb> My guess is installing bzr & bzr-fastimport for a single operation, and getting unjustly annoyed about it
<maxb> erm, wtf, in the topic: "http://irclogs.ubuntu.copingeling aboutm/"
* maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is frozen, installers build time ! (rm vila)
<knittl> does bzr use hardlinks when creating a local clone?
<spiv> knittl: not by default, you can hardlink the files in the tree by passing the --hardlink option though
<spiv> If you want to save space, you probably want to use a shared repository.  And if you want to save time, a shared repository is probably the best answer there too.  We've found that hardlinking the files in the working tree (which has to check each file to see if it has been modified) tends to be slower than just extracting the files directly out of the repository.
<spiv> Shared repository + hardlinked working trees is the maximum space saving though, assuming you want to have multiple working trees on disk simultaneously, rather than one tree that you switch between your different branches.
#bzr 2010-12-09
<_habnabit> http://www.habnabit.org/bzr-graph3.png <- out of curiosity, why is it that most of the merged revisions are numbered 85.[1-5].X? Merging from trunk (which is what it's clustered around) doesn't seem to reset it.
<_habnabit> I'm unclear on how revision numbers are assigned from a merge.
<_habnabit> (My guess it it's using the earliest shared parent revision contained in the branch.)
<maxb> _habnabit: <mainline revno branched from>.<sequential numbering of branches off that mainline point>.<position on that branch>
<_habnabit> maxb, so the only way to reset the first number is to make a new branch?
<maxb> yes.... though it's just an arbitrary number, does it matter?
<_habnabit> I'm just curious.
<_habnabit> I don't care about it.
<lifeless> _habnabit: if you pull from trunk, it will reset all your local revnos to be identical to those in trunk
<_habnabit> Aha.
<lifeless> but you can only do that after trunk has merged from you
<_habnabit> Right.
<maxb> wtf, we have an intermittent test failure in bzr 2.3b4 in bzr-beta-ppa :-(
<spiv> maxb: :(
<maxb> list emailed
<maxb> I'm baffled
<jubei__> is there a way to check if there are changes to a repository before running bzr pull ?
<bob2> bzr missing
<jubei__> awesome, thanks
<rocky> is it possible to create branch X from a subdir in mybranc?  say mybranch has subdirs sd1 and sd2 and i want to produce a branch that only consists of sd1 stuff...
<bob2> you can branch, delete, move.  or there's the split stuff, but I don't know how usable that is atm
<spiv> maxb: replied; known issue, fixed upstream and workaround just landed in lp:bzr
<maxb> gosh
<maxb> how obscure
<spiv> maxb: on the plus side, it wasn't our fault ;)
<vila> hi all
<vila> poolie: hey ! the poolie_droid sounded like a definitive SSD failure :-}
<vila> maxb: fix landed, I filed bug #686008 as soon as I saw the daily builds failures, sorry I didn't think to warn you explicitly
<ubot5> Launchpad bug 686008 in Bazaar "TypeError: 'member_descriptor' object is not callable" [Medium,In progress] https://launchpad.net/bugs/686008
<vila> maxb: ... obscure it not fair for this, it's far worse than that (and my English is not good enough to find the fait word there ;)
<vila> s/fait/fair/
<vila> maxb: even knowing what was happening and why I couldn't write a *reliable* reproducing test :-/ See https://code.edge.launchpad.net/~vila/bzr/686008-spurious-https-failure/+merge/42969 for details
<vila> poolie: ping
<poolie> hi vila
<vila> poolie: was your _droid suffix related to your SSD issues ? :-}
<poolie> haha
<poolie> not right at the moment
<fullermd> vila: (brief moment of lucidity) I pulled in your changes and did somsethingorother yesterday.
<vila> fullermd: yup, I saw that ! Thanks ! Take care
 * fullermd tries to get another 2 hour block of sleep...
<ronny> hi
<ronny> where is bzrlib.bzrdir gone?
<vila> ronny: it seems to be present in all my bzr branches, may be you can be more specific ?
<ronny> vila: im testing agains what is pip/easy_install-able
<ronny> it recently broke
<ronny> its quite annoying that bzr breaks the anyvc builds every few weeks in such unexpected ways
<vila> I can understand your frustration but I still have no idea what failure you're talking about
<vila> bzrlib/bzrdir.py is quite a significant piece and it won't disappear without notice
<ronny> vila: the testing process currently download whatever bzr version is pip installable, and tests agaist that
<ronny> (there is no way to sanely link to older ones)
<vila> I have no idea what pip installable means but I can give you links for many bzr versions including the stable ones
<ronny> vila: its quite useless if pip install bzr==version does not work
<vila> ...
<vila> you're talking chinese as far as I'm concerned
<mgz> it's one of those setuptools based html scraping things.
<mgz> because installing stuff from random bits downloaded over http is always such a great idea.
<vila> ronny: are you telling that you don't have a bzrlib/bzrdir.py file ?
<vila> ronny: if that's the case, the way you acquire bzr is seriously broken
<vila> ronny: being the bzr release manager these days, I can assure you that *all* recently releases version *includes* this file
<ronny> hmm, it actually exists
<vila> ha, we're making progress
<ronny> vila: well, why the hell is NONE of them propperly availiable on pypi
<ronny> pretty much everything else i use just does that, and i can just get any version i want by package==version
<ronny> only bzr makes me work extra
<ronny> like always
<vila> may be we can focus on concrete problems and how to solve them rather than ranting ?
<ronny> ok, sorry
 * ronny finishes the local reproducing
<vila> what OS are you using ? I maintain quite a few flavours but *NONE* of them requires to use easy_install and I'm not familiar with how this works
<ronny> vila: im using tox to create virtualenvs with all requirements for the test runs
<ronny> its using pip to grab the requirements
<ronny> (and falls back to easy_install if necessary)
<vila> what is pip and what is tox ?
<vila> bah, nvm
<vila> where are you getting bzr and in which form ? tar.gz ? .deb ?
<ronny> tarball, installing it in a virtualenv after all
<vila> where is this tarball coming from ?
<vila> and what OS are you using (no, really) ?
<ronny> im on the latest ubuntu, the test box is on a gentoo, its all linux
<ronny> the thing pip currenly grabs is  bzr-2.3b4.tar.gz
<vila> so both of them provides stable releases AFAIK
<mgz> vila, as I was saying, it scrapes html, and has broken in the past from <https://launchpad.net/bzr/+download> changing format.
<vila> ronny: if you're using betas instead, then you are *expected* to encounter problems and give us feedback, that's the point of betas
<ronny> vila: well, the issue for me is simple - bzr cannot propperly be installed by the python package installer
<vila> ronny: this is as useful as bug reports saying: 'Does not work'
<mgz> it just gets the first likely link on that page.
<ronny> vila: i requested pushing all releases to pypi as well some times now
<vila> ronny: afaik the python installer is used in Ubuntu and there is even *daily* builds exercising it, so surely you encounter something more specifi
<vila> ronny: right, may be you teach us how to do that then
<ronny> vila: python package installers are pip and easy_install
<spiv> ronny: python package installers are "python setup.py install", really.
<vila> ronny: don't they rely on setup.py ?
<ronny> vila: yes, but they have to grab the package from soemwhere first
<ronny> and in bzr's case, the only link they ever can get is the latest tarball out
<spiv> Or did pip/easy_install get integrated into the standard Python distribution since I last checked?
<vila> ronny: is there a way to fix that on http://pypi.python.org/pypi/bzr ?
<ronny> the usual way is to just push the tarballs there
<spiv> (I agree it would be nice to work well with pip etc, though)
<ronny> usually people upload after a sdist
<vila> ronny: as far as I know, the instructions say: 'python setup.py register' which I did for 2.2.2
<mgz> I'm not even sure that's enough, because bzr has build dependencies that it doesn't declare using the setuptools machinary.
<ronny> vila: that only tells pypy there is a project with that version
<mgz> so virtualenv installs may break even if tarballs get uploaded.
<vila> ronny: that's why I mention it, what should be done is what I'm asking
<ronny> mgz: tarballs ship with c files, dont they?
<mgz> ah, so they do.
<ronny> vila: upload after sdist
<vila> upload
<vila> -bash: upload: command not found
<mgz> and I guess you don't care about running selftest.
<ronny> vila: its a distutils command
<vila> distutils upload
<vila> -bash: distutils: command not found
<mgz> as in setup.py vila.
<vila> python setup.py upload
<vila> running upload
<vila> error: No dist file created in earlier command
<mgz> +setuptools specifc.
<vila> and yes, I'm in the right directory from which 2.2.2 was released
<mgz> basically, the problem is we don't use setuptools.
<mgz> which I think isn't something we want to change.
<vila> ronny: here it goes ^
<ronny> vila: doesnt matter
<vila> ronny: if you care about it, a patch against bzr making your life easier will certainly be considered, failing that, may be you should think of a better way to select your bzr source
<ronny> vila: pip/easy_install force setuptools on any setup.py
<ronny> vila: just upload the dam tarballs to pypi
<ronny> pip/easy_install will do the rest
<vila> ronny: one last time: I don't know how to do that nor do I have the time to investigate, you obviously know better and are certainly in a better position to propose a patch which can be as little as explaining which commands need to be run when
<ronny> vila: python setup.py sdist upload
<spiv> ronny: i.e. a patch to our doc/developers/releasing.txt
<spiv> Anyway, this really doesn't sound like the cause of your bzrlib.bzrdir problem.
<spiv> Can you give more details about that?
<vila> ronny: done. test and feedback welcome and for an additional bonuses a merge proposal updating the document spiv mentioned above
<spiv> Because there's nothing about grabbing the 2.3b4 tarball rather than the 2.2.2 tarball that seems relevant to that.
<ronny> hmm, seems likepip still prefers the latest ones, but i think i can fix that
<mgz> I'm curious about that too spiv, but reckoned setuptools was just breaking something else.
<mgz> vila: I think one upshot of putting a tarball up there is breaking anyone on windows trying to easy_install bzr (if it worked before, that is)
<vila> hmm and this command doesn't seem to include the generated C files, so most likely the result will not be the expected one
<vila> nor the docs ones
<vila> ronny: and how do we remove this broken tarball now ?
<ronny> vila: pypi has a web ui for that
<vila> done
<mgz> I'm failing to find any documentation on how to actually interface with pypi to upload stuff we want from our build scripts.
<vila> the web page allowing removing the tarball seems to allow manual upload too
<ronny> mgz: distutils includes a uploader
<mgz> no, ronny, no, it doesn't.
<mgz> *setuptools* does.
<vila> ronny: which produces the bogus behaviour above
<mgz> which as vila just found, is broken.
<ronny> mgz: distutils includes one for sure, setuptools is not required
<mgz> hm, ported across in some version.
<ronny> starting with 2.5
<vila> ronny: I've update the Download URL at pypi, can you try again ?
<vila> s/update/updated/
<ronny> pip tries http://launchpad.net/bzr/2.2/2.2.2/+download/bzr-2.2.2.tar.gz, gets a http 404, then grabs the rest of the download list and grabs the latest one
<vila> it shouldn't get a 404 since that's the url *all* packagers are using
<ronny> it would be appreciated if the redirect target wouldnt trick browsers into display as text
<vila> https://edge.launchpad.net/bzr/+download clearly states that 662 people succeeded to download it with this link
<vila> ronny: file a bug
<vila> ronny: but try to focus on your actual problem, we've been at it for an hour now and you still haven't explained what the problem was about bzrlib.bzrdir
<ronny> it missing was in part caused by the venv getting messed up
<ronny> i did a messy fox for the build issue, to get it propper i need to kill the problems with grabing specific bzr versions as source tarballs
<vila> ronny: does this means updating the Download URL on pypi doesn't address your problem then ?
<vila> mgz: does the proper tarball on pypi address your concern about windows people ?
<ronny> it should, right now pip/easy_install still select thr wrong one for reasons unknown to me
<ronny> (weird stuff only happens for stuff thats not propperly uploaded to pypi)
<vila> ronny: we're back to 'does not work' being useless to make progress
<ronny> vila: im trying t figure why pip fails to take the download link into account, but i cant exactly give a detailed description i dont have
<vila> ronny: right, that's exactly my point: there is nothing we can't fix if we don't know what we do wrong
<ronny> vila: im working on the details, but the basics are your tarballs are at locations that are awfully inaccessible for pip/easy_install
<vila> s/awfully/standard http but/
<vila> ronny: why you insist on getting around packaged versions provided by the OSes you use while not wanting to use a source *branch* despite working with DVCS tools is a bit behind my understanding though...
<vila> But that probably explain why you're the first one to report such problems...
<vila> ronny: gentoo for example backported a patch from our trunk to the 2.2.2 stable branch which you will never get by working with tarballs
<vila> ronny: if you're using python-2.7 (targeted  by the backported patch) you're on your own
<vila> mgz: did I mention I uninstalled launchpadlib from the 10.6 babune slave ? Leading to 3 remaining failures
<ronny> vila: these day thats the common way to set up isolated python envs for test runs
<vila> ronny: GIGO (garbage in, garbage out), if your test inputs are wrong, so do your tests outputs
<vila> ronny: if you're interested about how bzr is tested: http://babune.ladeuil.net:24842/
<vila> this is a hudson setup that use the bzr trunk on various platforms
<ronny> time to drop the bzr variation of my CI i guess
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3b4 is officially out ! (rm vila)
<didrocks> hey
<didrocks> so, I'm trying to merge between two branches, I have conflicts. (a lot of them). When trying to bzr resolve --take-others --all, I get:
<didrocks> bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]
<jelmer> didrocks: hi
<jelmer> didrocks: I believe there's an open bug about that
<vila> didrocks: bzr version ?
<vila> jelmer: hey :)
<vila> jelmer: remind where I should check in debian to see if bzr-2.3b4 is there ?
<vila> s//me/ !
<jelmer> vila: Good arvo
<jelmer> vila: http://qa.debian.org/bzr
<jelmer> sorry, http://packages.qa.debian.org/bzr
<jelmer> I haven't packaged/uploaded b4 yet
<didrocks> vila: Bazaar (bzr) 2.3b3
<didrocks> jelmer: is it fixed in trunk? I can't do the unity release because of it right now
<vila> bug #646691
<ubot5> Launchpad bug 646691 in Mahara "Blog account settings still available when blog disabled" [Low,Confirmed] https://launchpad.net/bugs/646691
<vila> bug #646961
<ubot5> Launchpad bug 646961 in Bazaar 2.2 "resolve --take-other produces AttributeError" [High,Fix released] https://launchpad.net/bugs/646961
<didrocks> I found that weird, right :)
<vila> hmm
<didrocks> ok, fixed in trunk then
<vila> not sure it's the same one but...
<didrocks> oh right, doesn't seem
<vila> didrocks: where did you get your bzr ? ppa ?
<didrocks> vila: lp:~unity-team/nux/nux and lp:~unity-team/nux/packaging
<didrocks> vila: you can try without merge-upstream, just merge nux in packaging. We get a whole bunch of conflicts
<didrocks> (not sure why btwâ¦ It's just a one-line change in most of files)
<vila> didrocks: I meant where is your bzr-2.3b3 coming from ? source ? ppa ?
<didrocks> I assume there was something with merge-upstream and missing file in tarball
<didrocks> vila: oh, from natty
<vila> didrocks: #638451
<vila> bug #638451
<ubot5> Launchpad bug 638451 in Bazaar " bzr resolve --take-other bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)] " [High,Fix released] https://launchpad.net/bugs/638451
<vila> didrocks: more like it no ?
<didrocks> vila: exactly :) so I should definitively pull trunk
<didrocks> vila: do I have to mess up with PYTHON_LIBRARY path?
<vila> didrocks: feedback *highly* appreciated there
<vila> didrocks: not sure what you mean, but if you run the right *bzr* script, the right bzrlib should be selected (or file a bug)
<didrocks> vila: ok, let's see how it goes
<vila> didrocks: if you run from source, don't forget to run 'make' first
<vila> didrocks: note that you're using a quite recent addition there that will handle the *text* conflicts by *forcing* the OTHER version (with --take-other)
<vila> didrocks: i.e. all changes that could be otherwise merged cleanly are thrown away
<jelmer> didrocks: alternatively you can use the nightly builds
<vila> didrocks: make sure you read 'bzr help conflict-types' there
<vila> jelmer: I read the emails related to the failures, but not always the associated logs, is there a place which summarizes the status of the builds ?
<jelmer> vila: https://code.launchpad.net/~bzr/+recipes has a list of all the recipes, each recipe has an overview of the resulting builds
<vila> jelmer: ha, 2.3b4 not yet packaged, ok
<jelmer> vila: there's also https://code.launchpad.net/~bzr/+archive/daily/+packages
<vila> jelmer: thanks, I keep forgetting +packages
<vila> meh, didrocks, don't leave without feedback !!!
<vila> . o O (reboot did he ?)
<vila> jelmer: should https://code.launchpad.net/~bzr/+recipe/bzr-daily mention beta5 instead of beta4 ?
<jelmer> vila: no, as we're using "beta4+bzr" - note the + which means this version comes /after/ beta4
<vila> jelmer: %-} ooook
<jelmer> vila: Alternatively we could use beta5~bzr if we knew we were going to do a beta5
<jelmer> (~ sorts before empty string, + sorts after empty string)
<vila> right, so you did this change at freeze or at release time ?
<jelmer> vila: yep
<vila> a or b: yes... :D
<vila> any ?
<vila> yeah, any, sorry, thinking aloud ;D
<vila> haaa, he's back :D
<vila> didrocks: so ?
<didrocks> vila: sorry, seeems that I was disconnected :/
<didrocks> 16:25:42 didrocks | vila: are you sure it's taking the right bzrlib? like if I try ~/sandbox/bzr/bzr resolve --all --take-other (~/sandbox/bzr is where I branched bzr from)
<didrocks> 16:26:23 didrocks | oh right   bzrlib: /home/didrocks/sandbox/bzr/bzrlib
<didrocks> 16:26:32 didrocks | so okâ¦ it's not fixed :/
<didrocks> I have 2.3.0dev5 from --version
<vila> file a bug
<didrocks> vila: what do you need as needed info in addition to the branch and the error output?
<jelmer> vila: Sorry :-) I changed it after the release
<vila> didrocks: reproducing recipe
<didrocks> vila: can I workaround in some way (downgrade or such)? I think that I can't delay the unity release anymore :)
<vila> didrocks: try resolving in several steps
<didrocks> there are 50 conflictsâ¦ will write a shell script then
<vila> didrocks: meh, is that a private branch ?
<didrocks> vila: it's not, you can't check it out?
<vila> no, got not a branch
<didrocks> let me check, I maybe made a typo
<vila> s!/nux!/trunk! ?
<didrocks> vila: oh sorry, the trunk is at trunk, right
<didrocks> or lp:nux
<vila> yup, better
<didrocks> the packaging branch is good :)
<vila> ouch, 62 conflict
<vila> ouch, 62 conflicts
<didrocks> vila: yeah, I'm not sure why there are thereâ¦ upstream just changed the email in every files
<didrocks> vila: so I think something happened between bzr merge-upstream / the tarball / trunk
<didrocks> well, we try to ship every files in the tarball to avoid conflicts as we had at some point
<vila> no, there are a bunch of content conflicts which means different file-ids probably so parallel import ?
<didrocks> vila: weird, bzr merge-upstream did that?
<vila> no idea
<didrocks> like it added other file ids?
<didrocks> filed as bug #688101
<vila> didrocks: I'm digging the history of both branches
<ubot5> Launchpad bug 688101 in Bazaar "bzr: ERROR: Tree transform is malformed [('duplicate id', 'new-74', 'new-1')]" [Undecided,New] https://launchpad.net/bugs/688101
<didrocks> vila: thanks, it will be way easier for you I guess to find what happened than I ;)
<vila> didrocks: hopefully :-}
<didrocks> (I was the CSM administrator in my previous company, so I digged a lot in that to support developers, I don't want to do that anymore :p)
<vila> didrocks: so far the only suspicious bit is revno 138 (New upstream release _ cherry pick latest commit)
<vila> didrocks: di you change your workflow somehow between now and then ?
<didrocks> vila: I've already done that in the past for unity itself. I just bzr merge from trunk what's interested
<didrocks> so it should pick upstream file-id if there are new, isn't it?
<vila> didrocks:  if you started your packaging branch from trunk ,yes
<didrocks> vila: right, it is started from trunk
<vila> and that seems to be the case (revno 113)
<didrocks> that's all the benefit of merge-upstream and this workflow, cherry-picks :)
<didrocks> (no more debian/patches/â¦)
<didrocks> and it went well in the past in bamf/unity/deeâ¦ (I'm used to do that since May I would say)
<vila> right, so comparing the inventories on both tips, sounds fine, all common files have the same file-ids, but it seems the conflicting ones are new in trunk... weird
<didrocks> vila: not only the new ones (it can't add the directory it seems), but also ones where the email name was changed, isn't it?
<vila> didrocks: hmm, doing 'bzr qlog trunk packaging' shows that you *never* merged since 0.9.1
<vila> no wrong
<didrocks> vila: is that what bzr log trunk packaging tells me?
<didrocks> bzr: ERROR: Path "/home/didrocks/work/unity/nux/ubuntu" is not a child of path "/home/didrocks/work/unity/nux/nux"
<vila> of course you never merge packaging in trunk, you do the opposite, sorry
<didrocks> right :)
<vila> *q*log
<didrocks> didn't know that command, it's coming from which package/plugin?
<vila> qbzr
<didrocks> no gtk equivalent? ;)
<vila> best way to look at branch histories (especially to see how they interact)
<vila> bzr viz, but I don't remember if it accepts multiple branches
<didrocks> I've always used with once, let's see how it work with 2
<vila> well, yes it does, but it still lacks the ability to hide merges
<vila> a good chunk of the qlog backend is in a mp for bzr, once it lands, viz could reuse it
<didrocks> oh nice, yeah, it's easier to see the history this way
<vila> didrocks: eeerk, never ever use 'resolve --all' all this does is deleting the conflicts file
<vila> didrocks: on the other hand, I just did that and that may be shortcut you're after...
<didrocks> vila: well, I haven't done that. I just noticed it this time
<didrocks> vila: on bzr resolve --all --take-other should take all .OTHER, isn't it?
<vila> didrocks: no, that's a bug, --all and --take-other shouldn't be allowed together
<didrocks> vila: oh ok :)
<vila> didrocks: try 'bzr resolve --all' alone and look at the result but don't commit !
<fullermd> Yeah, 'resolve --all' is a "mark that things are done", "--take-whatever" is a "do things".  Kinda a wart that one command does both.
<didrocks> fullermd: oh right!
<didrocks> vila: yeah, confirmed
<vila> didrocks: if you're happy with the result: do 'bzr revert --forget-merges' and then and only then commit
<vila> didrocks: if you weren't in a hurry I won't recommend that *at all*
<vila> ha, bah, no good, bunch of .OTHER all over the place
<didrocks> vila: hum, so what should I use? bzr merge && bzr revert --forget-merges? but that will prevent me taking new upstream version, isn't it?
<vila> didrocks: no, that would be a huge cherry-pick
<vila> didrocks: but forget it, bad idea
<didrocks> vila: ok, I still have some time :)
<vila> jam: ping
<vila> jam: I don't have news from gary and we still haven't installers for bzr-2.2.2, can you help ?
<LeoNerd> bzr add   silently adds container directories. This is helpful.   bzr mv    doesn't add new path containers, gets upset. Possibly it should?
<LeoNerd> Well, not silently. Automatically.
<LeoNerd> Strikes me if 'add' does it, so should 'mv'
<fullermd> Devil's advocate: You call mv to move a file from one place to another; having it also add stuff is unexpected.
<LeoNerd> Devil's Counter-advocate; You call add to include one new file; having it also add other stuff is unexpected.
<vila> didrocks: ok, the problems started at revno 139 in trunk
<LeoNerd> Or make it non-default?  bzr mv --add-parents oldname newname
<vila> LeoNerd, fullermd: very good, put that in a bug !
<LeoNerd> Then people who want it can just alias
<didrocks> vila: looking
<fullermd> Perhaps, but it's at worst "do more than expected", not "do something else too".  I'd be shocked at 'add' moving stuff around; perhaps less so, but still somewhat, at 'mv' adding stuff.
<fullermd> We're not ready for a bug, we're still rehearsing!
<LeoNerd> Well.. currently it complains and dies
 * Torne is more surprised by mv failing just because he didn't add the directory
<didrocks> vila: weird, it's modified but the whole file content is removed and then added
<didrocks> vila: oh "fix end of line" -> \r\n -> \n ?
<vila> yeah, so the file-ids shouldn't be modified then
<didrocks> right
<Torne> fullermd: bzr add adds the parent directories because otherwise the operation would have to fail, and failing an operation with a perfectly logical intent would be silly. I don't think that mv is different just because "mv" and "add" are different commands.
<jam> hi vila, I might be able to dig something out, but I honestly haven't worked closely with Garyvdm on the last couple of builds
<vila> jam: :-/ do you know if he at least pushed its last related branches ?
<jam> he should have, but no, I don't know that for sure
<didrocks> vila: so, do you have any suggestion? I can drop the packaging branch and setup one againâ¦ but that will be a pity :/
<vila> didrocks: whatever works for you :-/ I'm still digging and won't have a fix shortly sry :-/
<didrocks> vila: ok, can you keep the branch somewhere? I'll surely --overwrite
<vila> didrocks: but my feeling is that the prolem is in merge not in resolve, the later being a symptom
<vila> didrocks: I have both branches there
<didrocks> vila: ok, I'll maybe scratch them then. Hope that the use case can be solvable for you :)
<vila> me too
<vila> didrocks: that's the first time you're using 'bzr resolve --take-other' right ?
<vila> didrocks: there seems to be mutiple bugs there when the same file is involved in several conflicts
<vila> didrocks: the workaround seem to be to resolve the conflicts manually
<didrocks> vila: I never used it before, right
<vila> didrocks: I'm halfway
<vila> didrocks: ha good, so I think it will not have give you the expected result
<vila> didrocks: is  NuxGraphics/GraphicsDisplayWin.h windows specific ?
<didrocks> vila: yeah, Nux is multi-plateform
<vila> didrocks: and you deleted it from the packaging branch. Using --take-other means take it again
<didrocks> vila: no, it was not disted in make dist tarball
<didrocks> vila: so bzr merge-upstream deleted it
<vila> didrocks: meh, I didn't use merge-upstream
<didrocks> vila: I mean, that's why some files were deleted there in some commits
<vila> didrocks: right, anyway, that's why you have Content Conflicts (one side deleted, the other modified)
<didrocks> vila: yes, just a pity there is no way to solve that in one command :)
<vila> didrocks: indeed
<vila> didrocks: but your specific use case here is tricky, you want a mix of --take-this and --take-other
<vila> well, not even, you don't want --take-other, you want to keep your deletions and cleanly merge the rest I think
<didrocks> vila: exactly :/ in any case, there are some workflow issues with merge-upstream for such cases
<didrocks> right
<vila> didrocks: any way, summary:
<vila> - thanks for the bug, I should fix it,
<vila> - --take-other is not what you want: you need to resolve them in smaller chunks but not at all once, one by one in the worst case
<vila> - merging more often will help, as usual :D
<didrocks> vila: I'm merging once a week :)
<didrocks> vila: but yeah, this use-case is an issue with merge-upstream workflow
<didrocks> at least, we know why there are conflicts, which is good
<vila> didrocks: well, more often can also mean merging less revisions (which is what I'm doing)
<vila> didrocks: I'm lost now, revno 144 produces 58 conflicts and I have no clue about how to resolve them
<didrocks> vila: right, but with 25 upstream branch without making a releaseâ¦ once a week is already a lot :)
<vila> didrocks: of course, that's a bug, I'm only talking about workarounds here, the last item had a smiley ;D
<didrocks> right :)
<vila> and when I say one.. probably several
<vila> didrocks: bactracking to your ', it was not disted in make dist tarball' where is this defined ?
<didrocks> vila: sorry, I'm currently on the unity release, hard to be responsive :)
<vila> didrocks: no worries, am I right if I guess from Mafile.am files ?
<didrocks> vila: this is definied in the dist target of all the Makefile.am
<didrocks> yeah
<didrocks> (there are multiple)
<vila> to yeah, this is taking shape, you're suddenly confronted with a bunch of conflicts (deleted/modified), so what you really want is some way to attach merge options to files or directories
<vila> and this became more obvious *because* a change was made to *all* files
<poolie> hi jam
<spiv> Good morning.
<poolie> hi spiv
#bzr 2010-12-10
<maxb> Ugh
<maxb> It seems that the most annoying part of producing packages for the bzr ppa is just wrestling the debian/changelog into sanity across five distroseries
<maxb> I really need to come up with a way to automate this
<poolie> hi maxb
<poolie> it is annoying
<poolie> a tool for it would be great
<maxb> There are several parts
<maxb> One part is the changelog merge hook needs to understand not to sort entries in version number order when ~foo suffixes are involved
<maxb> Another part is that when doing PPA builds, often the right way to merge an entry is to s/lucid/karmic/g the header line, rather than listing all versions involved
<poolie> mwhudson, spiv do you recall how to get pyflakes to work with lazy_import?
<mwhudson> poolie: install it from lp:~mwhudson/pyflakes/support-lazy_import
<poolie> or comment out the lazy import :)
<poolie> thanks though
<mwhudson> well that works too, but my version is a bit more automatic :)
<poolie> is that url right?
<poolie> and the related question is: is pyflakes still the best static checker?
<poolie> nm, found it: 'support-lazy-imports'
<mwhudson> ah oops
<mwhudson> it's still the best i know of
<mwhudson> pylint does more, but requires assloads of configuration to be useful and is slow
 * mwhudson attempts to merge trunk into his branch
<mwhudson> so...
<mwhudson> what do people use to handle difficult conflicts?
<mwhudson> (the problem i have here is that the merge has resulted in the conflicting sections being broken up in unhelpful ways)
<poolie> vimdiff or meld
<mwhudson> does anything know how to parse the conflict markers out of the file and start from there?
<spm> mwhudson: 'rm <file>'
<poolie> how do you mean?
<poolie> i think emacs has a mode that specially recognizes herringbones
<poolie> spiv, is https://bugs.launchpad.net/bzr/+bug/603395 now fixed?
<ubot5> Ubuntu bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propagate new tags" [High,In progress]
<poolie> can you please update it either way?
<mwhudson> i guess i'm not sure what i mean
<mwhudson> kdiff3 seems quite nice, if a bit obscure
<mwhudson> hm yes, pretty good
 * mwhudson pushes up his new branch
<spm> is there an easy way to discover which branch a certain chunk of text was added to a file? I have the text, would just like to track the context/when it was added as it looks... odd.
<spm> bah. try #2. not which branch, *when* a certain chunk of text.
<poolie> spm: two ways
<poolie> 'bzr log -p |less'
<poolie> then search
<poolie> or 'bzr grep  -r 1.. PATTERN'
<poolie> ah bug 388437 is the one about ascii in error messages
<ubot5> Launchpad bug 388437 in Bazaar "notbrancherror doesn't show cyrllic paths correctly" [Medium,Confirmed] https://launchpad.net/bugs/388437
<spm> kk, ta muchly.
<spiv> spm: or look at that the "bzr annotate" output (preferably with "bzr gannotate" or "bzr qannotate", depending on your GTK vs. Qt preference)
<spm> worked perfectly, with one rider. search from bottom up. the text was about every 3rd change recently. :-)
<spm> spiv: ah, k. I'll try that just to see. the problem - this is on prasÃ©, but I suppose I can branch locally. yay for VCS. :-)
<spm> yay for *D*VCS.
<poolie> oh, if it's still present that's a more obvious way to do it
<poolie> would appreciate your thoughts on https://bugs.launchpad.net/bzr/+bug/388437 too
<ubot5> Ubuntu bug 388437 in Bazaar "notbrancherror doesn't show non-ascii paths correctly" [Medium,In progress]
<spiv> Before I look at that bug my thought is "can __str__ return a unicode object?"
<spiv> mgz probably knows the esoteric ins and outs here.
<spiv> poolie: your comment on 388437 sounds ok to me
<spiv> poolie: if nothing else, I doubt your suggestions can be worse than the status quo ;)
<vila> hi all !
<spm> hey vila
<vila> spm: hey there !
<vila> spm: regarding your mail about lp/pqm, I only have one GPG key, but possible two emails attached to it differing only by '+lp' (the one I use most of the time) which is also the one I use for bzr, I should be able to use it right ?
<vila> s/possible//
<spm> mayeb....
<spm> pqm is *really* fussy over the order of keys in the key itself. so generally whichever is the default is the one you must use.
<vila> spm: right, so if it works for bzr, it should work for lp
<spm> try it and we'll find out :-)
<vila> hehe
<RenatoSilva> I have a single file from a given upstream version. I patched it and now I want to merge upstream changes. But it's a single file, and they don't even use Bazaar. Is it possible to somehow automate this?
<beuno> RenatoSilva, they don't use bzr, but you do?
<RenatoSilva> beuno: of course, I'm managing the patch with bazaar
 * beuno was just checking  :)
<RenatoSilva> ok
<jelmer> RenatoSilva: they're using a foreign VCS or something like that, or did you import a tarball manually?
 * beuno waves at jelmer 
<RenatoSilva> jelmer: it's just a single file
<jelmer> hey Martin
<jelmer> RenatoSilva: you could create a separate branch with their version of the file in it and then use "bzr merge" to pull in new changes
<RenatoSilva> jelmer: ok will try it
<RenatoSilva> jelmer: bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<jelmer> RenatoSilva: yeah, your original branch needs to derive from the upstream branch
<jelmer> sorry
<jelmer> RenatoSilva: yeah, your branch needs to derive from the upstream branch
<RenatoSilva> jelmer: bzr branch -r 1 mypatch temp; mv upstream-changes temp; cd temp; bzr commit -m "New upstream rev hg:123"; cd ../mypatch; bzr merge --preview ../temp
<RenatoSilva> jelmer: this seems to work
 * AfC wonders why people do merge --preview ... just merge and then commit or revert
<RenatoSilva> is there any way of qlog or qdiff ignoring whitespace?
<vila> jelmer, beuno: bzr-upload 1.0.0 has been officially released
<jelmer> vila: \o/ Congrats :-)
<vila> I'm all ears for feedback on my last tweaks and what is needed for this release to reach the distributions ;)
<jelmer> vila: Does it fix the test suite?
<vila> jelmer: I hope so, feedback welcome
<vila> jelmer: bug #671964 ?
<ubot5> Launchpad bug 671964 in bzr Upload plugin "test failures building in chroot" [Critical,Fix released] https://launchpad.net/bugs/671964
<vila> jelmer: I added a info.py file and according tweaks (by looking at bzr-svn and bzr-gtk), I probably broke something there or in the setup.py (I also added a MANIFEST.in)... Monkey see, monkey do. Monkey welcomes feedback to do better too ;)
<jelmer> vila: Cool
<beuno> vila, woooooooooooooooooooooooooooooooooooooooooooooooooo \o/
<beuno> pitty it's too early to drink
<vila> n'ver too 'rly
<beuno> vila, and we started this what... 3 years ago?
<beuno> maybe a but more?
<vila> beuno: the release doesn't include all the shimy features we've dreamed about, but at least it's out :)
<vila> beuno: OMG, I have no idea, too bad we didn't take notes or use a VCS :)
<beuno> vila, well, it was born during the bzr community sprint
<beuno> so we should be able figure out when that was
<vila> beuno: I remember precisely the restaurant we were in :)
<vila> first commit on 2008-03-07
<beuno> 2 years and 3/4  :)
<vila> I find it interesting that a VCS made this project possible, a few hours here and here stretched across ~3 years... and still a useful piece of code
<RenatoSilva> is there any tool for exporting an hg branch to bazaar?
<beuno> RenatoSilva, fast-import, I think
<RenatoSilva> http://wiki.bazaar.canonical.com/BzrFastImport, can't grok
<RenatoSilva> I just want something like bzr import --hg $hgbranch
<vila> RenatoSilva: bzr-hg ?
<RenatoSilva> vila: thanks
<RenatoSilva> Unable to load plugin u'hg'. It requested API version (2, 0, 0) of module <module 'bzrlib' from 'c:\Program Files\Bazaar\lib\library.zip\bzrlib\__init__.pyo'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1)
<vila> >-/
<RenatoSilva> also, "This plugin requires recent versions of Bazaar **and Mercurial** to be installed to work."
<vila> RenatoSilva: yeah, looks like it needs love
<vila> RenatoSilva: next bet would be to search in hg for a fast-export path then
<RenatoSilva> or use hg at all :P
<RenatoSilva> I was trying to avoid installing and touching hg
<vila> it's a bit surprising though, there are launchpad imports for hg branches, so there should be a version around that is at least compatible with bzr-2.2
<jelmer> RenatoSilva: that's not really possible
<jelmer> RenatoSilva: as far as I know hg itself is the only thing that can read mercurial repositories
<RenatoSilva> jelmer: so how about bzr-hg?
<jelmer> RenatoSilva: bzr-hg depends on mercurial itself
<RenatoSilva> vila: is that LP import accessible to regular users?
<jelmer> RenatoSilva: yes
<vila> AFAIK if the branch is public you can request its import. You may need the corresponding project created on lp first though (unless it already exists of course)
<RenatoSilva> no automated way?
<jelmer> RenatoSilva: the request handling is automated
<vila> RenatoSilva: ? Once the import is defined, it will run periodically
<RenatoSilva> will the imported branch keep in sync with external version?
<RenatoSilva> will new commits be automatically imported into the local bzr branch?
<RenatoSilva> what if there are conflicts?
<RenatoSilva> how do I request an import?
<jelmer> RenatoSilva: they won't automatically be imported into the local Bazaar branch, only to the branch on Launchpad
<jelmer> RenatoSilva: In theory new revisions will be pulled in automatically twice a day or so, but there have been some issues with the Mercurial imports
<jelmer> RenatoSilva: So I wouldn't rely on them beyond the initial import at the moment.
<RenatoSilva> by local I mean Launchpad
<jelmer> RenatoSilva: the launchpad branch would be owned by Launchpad, you can't change it (so there is no possibility of conflicts)
<RenatoSilva> I don't understand
<RenatoSilva> I can't change it?
<jelmer> RenatoSilva: no; it's a mirror of the remote mercurial repository
<RenatoSilva> but see, I want to maintain a patch to a project but without using hg
<jelmer> RenatoSilva: you can clone the import and make the changes in your clone
<RenatoSilva> jelmer: so the imported branch behaves like upstream was really using bzr, and I can't touch it as I'm not upstream dev. So I branch it and merge chnages normally, that's it?
<jelmer> RenatoSilva: yep
<RenatoSilva> ok trying right now, is this the right url, http://hg.guifications.org/purple-plugin-pack ?
<RenatoSilva> how to associate the mirrored branch with a given project? https://code.launchpad.net/~renatosilva/+junk/purple-plugin-pack
<RenatoSilva> "New code import created. The code import operators             have been notified and the request will be reviewed shortly."
<RenatoSilva> but you said it was automated :(
<beuno> RenatoSilva, I'll review it for you
<jelmer> beuno, RenatoSilva: it is
<jelmer> RenatoSilva: it's auto-approved
<RenatoSilva> so message needs to be updated
<RenatoSilva> or the operators are bots
<jelmer> RenatoSilva: there's a bug about that in launchpad-code
<RenatoSilva> ok
<RenatoSilva> it was said here that the imports happen once or twice a day but that there has been problems with hg, can I manually request an update?
<beuno> RenatoSilva, what's the branch's url?
<RenatoSilva> https://code.launchpad.net/~renatosilva/purple-plugin-pack/trunk
<RenatoSilva> beuno: ^^^
<beuno> http://launchpadlibrarian.net/60435984/renatosilva-purple-plugin-pack-trunk.log
<beuno> it failed to import
<beuno> jelmer, ^
<jelmer> looks like that host has broken 404 handling :-/
 * jelmer looks a bit further
<jelmer> RenatoSilva: sorry, got distracted by some failing tests.
<jelmer> RenatoSilva: https://bugs.launchpad.net/bzr-hg/+bug/670870 exists for this issue
<ubot5> Ubuntu bug 670870 in Bazaar Hg Plugin "bzr crashed with ValueError in convert_converted_from()" [High,Triaged]
<RenatoSilva> thanks, subscribed
<RenatoSilva> about manual import, there's a button "import now" :)
<RenatoSilva> :(
<jelmer> RenatoSilva: ?
 * RenatoSilva sad for the branch import not working
<jelmer> RenatoSilva: ah
<jelmer> RenatoSilva: It doesn't appear to be a hard issue to fix, I might have a look at doing so after work
<RenatoSilva> thanks jelmer
<fabio_kreusch> Hi there, I want to have subprojects inside a project, is that possible?
<RenatoSilva> fabio_kreusch: #launchpad ?
<RenatoSilva> fabio_kreusch: no, but you can request a project group
<fabio_kreusch> no, I mean, I have a bzr repository, and I want to have subrepositories inside that
<fabio_kreusch> these subrepositories would contain code shared by other projects
<beuno> fabio_kreusch, no, bzr doesn't support nested trees at the moment
<beuno> there is working going on to support it, but I don't know the state of it
<ankurd> a quick repo-organization question:
<ankurd> i hv a bzr project in a dir A. Now i want to create a project such that root is dir B and A is sub-dir of B.
<ankurd> So, do i create a new project? coz I want to maintin the old log.
<ankurd> or do I extend this project somehow
<abentley> So you want to have a new project B that contains your existing project, A?
<ankurd> no I want the same project A to contain A and B both
<abentley> How can A be a subdir of B and contain B?
<ankurd> i mean the project should now hv B as root dir
<abentley> B is the root dir, and contains A?
<ankurd> yeah
<abentley> That sounds like what I said before: a new project, B, that contains your existing project, A.  What am I not getting?
<ankurd> any ideas?
<abentley> ankurd, I don't understand what you want, so I don't know how to help you get it.
<ankurd> k lemme restate my problem
<abentley> You may have missed this: "That sounds like what I said before: a new project, B, that contains your existing project, A.  What am I not getting?"
<ankurd> i hv a project that has A as root dir
<ankurd> I want this project to hv B as root dir now
<ankurd> B is parent dir of A
<ankurd> is that clearer?
<abentley> ankurd, You can do "cd B; bzr init .; bzr join A."
<ankurd> ohh
<ankurd> cool. thnx.
<ankurd> i was looking for this join command
<abentley> ankurd, np.
<abentley> ankurd, You might need to do a commit in B before joining A.
<ankurd> oh
<ankurd> i dint do a commit.
<ankurd> and did join
<ankurd> now wat?
<abentley> ankurd, do a commit, and see if you get what you wanted.
<ankurd> k. i wil try
<ankurd> hey, i did what you said but now i have lost all logs from dir A
<ankurd> ?
<abentley> ankurd, does your last revision show as a merge?  If you do "log -n0", do you see all your old history?
<ankurd> bzr: ERROR: An inconsistent delta was supplied involving 'bzrm.bzrignore', 'bzrignore-20100601133919-09b2wh8pcslnnrih-1'
<ankurd> reason: working tree does not contain new entry
<ankurd> i get this error wen i try to commit after join
<abentley> ankurd, if you run "bzr status", it should show a pending merge.  Does it?
<ankurd> working tree is out of date, run 'bzr update'
<ankurd> renamed:
<ankurd>   / => bzrm/
<ankurd> i dont think this is a pending merge!?
<abentley> ankurd, bzrm is "A" in your description, right?  The project you wanted to be inside B?
<ankurd> yeah
<abentley> ankurd, please run "bzr revision-info --tree".
<ankurd> 0 legalos.lotr@gmail.com-20101210184654-5ry4l7wlfg90x8cu
<ankurd> this is the output
<ankurd> ?!?
<abentley> ankurd, right, great.
<lifeless> mgz: https://bugs.launchpad.net/testtools/+bug/688719 https://bugs.launchpad.net/testtools/+bug/688724
<ubot5> Ubuntu bug 688719 in testtools "MatchesException broken with Python 2.4" [Critical,Triaged]
<millun> hi
<millun> my repo is atm called "src". how can i change that? in bzr explorer
<ryanprior> I want to share some code with a friend who's on Windows. He's only a beginning programmer and I don't want to overwhelm him with instructions for pulling code from a repository. How easy is the setup procedure for bzr on Windows?
<ryanprior> (I'm on Ubuntu and bzr is, thankfully, easy as pie over here =D)
<mkanat> ryanprior: It's an installation package, on Windows.
<ryanprior> mkanat: does it manage all the dependencies for you, or will I have to walk him through dependency building?
<mkanat> ryanprior: It should handle everything.
<ryanprior> mkanat: thanks, we're going to give it a go.
<mkanat> ryanprior: Okay, cool.
<millun> my repo is atm called "src". how can i change that? in bzr explorer
<Peng> millun: As long as you don't break the structure, you can usually rename stuff to your heart's content through the OS's renaming tools.
<millun> ok
<ryanprior> I'm trying to share my code using "bzr push lp:~ryanprior/+junk/mycode" but I'm getting this error: bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<ryanprior> Google tells me that might be a Launchpad or bzr bug, but I'm still suspicious that I'm doing something wrong. Any ideas?
<mkanat> ryanprior: Did you log in with your LP id in bzr?
<ryanprior> I did "bzr launchpadlogin ryanprior" and it gave no output, so I assumed it worked.
<james_w> ryanprior, what does "ssh ryanprior@bazaar.launchpad.net" say?
<ryanprior> Permission denied (publickey). So I suppose I need to get my crypto in order somehow.
<mgz> lifeless: is that not just one aspect of bug 675327? the branch I proposed should fix it.
<ubot5> Launchpad bug 675327 in testtools "Raises/MatchesException regressions" [Critical,In progress] https://launchpad.net/bugs/675327
<mgz> spiv/poolie: yeah, storing the url on the exception then using a __unicode__ method would be best, but getting it all matched up to handle the issues poolie mentioned in the bug will be the fun bit.
<lifeless> mgz: perhaps it is
<lifeless> mgz: I've done an audit/fixup of the testtools bug db
<lifeless> mgz: in your mp, jml says there is more to go to be fixed
<mgz> I've just looked at my emails and seen it, going through now.
<mgz> there isn't in the branch, but I think trunk may have broken something else in the mean time
<mgz> I'll look into it now.
#bzr 2010-12-11
<mgz> al, there was a bug for that testtools StringIO thing, whoops.
<mgz> *ah
<jelmer> 'evening mgz
<mgz> hey jelmer!
<mgz> lifeless: an idle note, I see you're using 'Critical' to indicated "can't release next version without this" for bugs about test failures and things, but I think jml's way of setting a lower priority for Python 2.4/3 failures and adding the 'testtools next' milestone was actually a bit easier to understand.
<ryanprior> mkanat: my friend got bzr for Windows working really easily. I bet it could be somewhat more usable, as the interface wasn't obvious to somebody unfamiliar with bzr lingo (push, pull, launchpad, etc) but we worked through it in about 15 minutes. So give my thanks to the folks who got the Windows experience to this point. =D
<mkanat> ryanprior: Awesome! :-)
<lifeless> mgz: the milestone represents inventory; generally we put things on it *once* they are closed, not speculative. perhaps criticals deserve an exemption
<mgz> that's certainly true for bazaar, but the "next" thing for testtools was quite cute I think.
<mgz> none of the issues were big or sprawly enough to actually risk slipping, and it gets them on the release page.
<jml> mgz: thanks so much for all the fixes
<jml> mgz: sorry I can't stay around to debug the windows thing. I need sleep.
<mgz> ich auch.
<jml> well then, gute Nacht
<mgz> can probably just cheat on that test, but do bug me in the future if you want anything.
<lifeless> mgz: we've slipped 2 weeks already
<lifeless> mgz: so I disagree on that assessment
<mgz> not on specific bugs, rather the release as a whole from re-breaking things with new features.
 * maxb sends bzr-upload to bzr/proposed
<mathrick> hiya guys
<mathrick> does running bzr join result in something like svn externals yet?
<mathrick> or is that still on TODO?
<rjek> I use it to import svn-hosted stuff in my own project, and then merge in future versions.
<rjek> Or have done one, at least.
<mathrick> rjek: ah, so it can still pull things in even after merging in?
<mathrick> if so, that's enough for my needs
<damd> hi.  i'm having troubles branching my launchpad project.  i have set up my SSH key pair and i'm using pageant for my private key.
<damd> i get the old familiar: bzr: ERROR: Connection error: Unable to authenticate to SSH host as damd@bazaar.launchpad.net
<damd> any ideas?
<jelmer> damd: hi
<damd> hi
<jelmer> damd: did you read the FAQ, do you have the right ssh key registered on Launchpad as well?
<damd> yes, i've read every piece of information and documentation i've been able to find
<damd> and yes, i've registered the public key on launchpad
#bzr 2010-12-12
<mgz> hm, looking at this osutils path manip stuff makes me want to resurrect the old Just van Rossum plan for Path objects.
<mgz> if we have to make everyone use the osutils versions already we could at least provide an api that doesn't suck quite so much.
<poolie> hi all
<peitschie> hi poolie
<elmo> is it relatively easy to get the modification time of files that have changed (i.e. would appear in bzr st output) through bzrlib or should I just parse the output of bzr st?
<mwhudson> elmo: getting the mtime from a path is pretty easy
<mwhudson> i think getting the list of files that would appear in st might be a little annoying
<spiv> elmo: the_tree.get_file_mtime(file_id)
<poolie> hi peitschie, elmo, spiv, mwhudson
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | 2.3b4 is officially out ! (rm vila)
<spiv> poolie: if you can get the code out of the error class without regression performance then that would be nice
<poolie> i'd much rather regress the feature than the performance
<poolie> after all this isn't even something someone specifically asked for
<spiv> That's true.
<poolie> it was kind of inferred from "they wouldn't have got confused if ..."
<spiv> I think maybe it's occasionally come up in user support on IRC too, but only very occasionally.
<poolie> oh, seeing that reminded me of the url escaping thing too
<spiv> I'm personally pretty relaxed about it now that the open_repository call is confined to str(e).  So constructing and repr()ing the exception is simple and safe, and it's only when generating text for display to a user we do the extra work (although I can see an argument for making that be something other than str(e) to be more careful).
<spiv> But if you'd rather remove this marginal feature, that's fine with me too.
<poolie> i guess it's dropped down my priority list too now
<poolie> i would really rather not see code like that come in in future though
<poolie> i think exceptions really should be value objects, or very close to it
<poolie> (i realize it's a tradeoff)
<spiv> Perhaps if we had other exceptions that wanted to provide that sort of hint when displayed to a user we'd find a better a home for the hint-generation/error-formatting.
#bzr 2011-12-05
<wgz> apache's windows port is reasonable... though I wouldn't run an sshd on windows myself
<wgz> If you want to go that route, I can help you get bzr working over http
<wgz> otherwise you're probably best posting to the mailing list for advice
<Noldorin> wgz, sshwidnows (openssh for win) isn't very good?
<Noldorin> right
<Noldorin> i see
<wgz> feel free to try it, but I'd personally be very nervous about allowing that kind of access to my box
<Noldorin> wgz, just because you think windows ssh servers don't have very well-tested security?
<wgz> it's a big surface area, and not widely used, yes.
<Noldorin> wgz, it's a big surface area on unix too :P
<Noldorin> just better tested
<Noldorin> wgz, are there any guides out there for setting up bzr+ssh (openssh) on unix at least?
<jelmer> Noldorin: there is no setup required, just a ssh server (and having bzr installed) is sufficient
<Noldorin> jelmer, oh yes? bzr client knows exactly what to do itself when it encounters an ssh server?
<Noldorin> jelmer, recommend any windows ssh server btw?
<jelmer> Noldorin: right, it just asks the remote server to run "bzr serve", and that's sufficient
<wgz> Noldorin: an ssh client can get the server to run arbitrary commands, so it just asks the server run bzr
<jelmer> Noldorin: I don't have any experience with SSH servers on Windows, sorry
<Noldorin> jelmer, no prob. thanks for the tip anyway :-)
<Noldorin> wgz, sure, as long as bzr is set up to deal with the quirks of being on an ssh transport. which i guess it is :-)
<Amis> Hello o/
<Amis> Soo... I'm searching all over the net but not finding an answer for this (seems to be very common) question: how can I make my Bazaar remember FTP passwords? I'm using 2.3.1 Bazaar with 0.6.1 T. Bazaar
<Amis> I might also add I use Window
<Amis> s
<Amis> Uhh, net split
<Amis> So, I found this thing called "authentication.conf" that does what I need BUT it does not work with SFTP connections and I can't really wrap my head around it
<Amis> "password ignored in section [projectnamehere], use an ssh agent instead" is what it says. What's the point of ignoring the password in the conf then promting for it? I don't really get it.
<fullermd> I don't know the Windows side.  But with a lot of ssh programs, bzr _can't_ pass the password to ssh.
<fullermd> In that case, bzr isn't prompting for the password; ssh is.
<fullermd> But whether that's what's happening for you, I don't know.
<Amis> So there's an SSH client being used (since it can connect) but it bzr can't pass the password to that client?
<vila> hey guys !
<Amis> Okkey, I managed to set it up but it was hell of a struggle for someone without a linux machine at hand :/
<mgz> morning all
<vila> morning mgz
* vila changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
<mgz> vila: on the get_message_encoding branch,
<mgz> I'm a little torn on whether to add 'system' or not.
<vila> for someone unaware of the context, 'message' is ambiguous
<mgz> what we care about is system messages,
<mgz> but gettext looks at LC_MESSAGES as well sorta
<vila> right, but LC_ gives a hint there
<mgz> and on win, FormatMessage is a generic api too (though generally just used to interpret errnos)
<vila> what makes you remove the 'system' part ?
<mgz> because it's the encoding for any messages really, it's just we happen to only care about the system ones
<vila> what are the other kinds ?
<vila> of message that is
<vila> error messages as in: produced by the application as opposed to the underlying system ?
<mgz> the c locale is a global setting
<mgz> anything can look at it and use it.
<vila> right,
<vila> I think the trigger for my remark was the docstring mentioning system but since it's in osutils...
<vila> may be the context makes it clearer but your proposal doen't have any uses of the function (classical issue when splitting proposals to make them easier to review ;)
<mgz> basically what we need it for is to know how to interpret the strings that get put in OSError, IOError, and so on
<mgz> which is why 'system', but it doesn't preclude the use of the setting for other things
<vila> yeah, that's the part I can't see from the proposal probably. So, just land it ;)
<mgz> well, the one worry would be if plugin authors are tempted to use it for something not related to the C library at all
<mgz> like encoding strings they want to show the user with it, rather than looking at the stream.encoding or something
<vila> maybe you can better explain the intent in the docstring ?
<vila> mgz: urgh, mixed eols in test_win32utils.py
<vila> weirdly enough, lp didn't notice
<mgz> ...how did we manage that?
<vila> for we I don't know, for where it's only the recently added lines ;)
<vila> what is this '_func' attribute ?
<mgz> ^just added in my branch? can rewrite history to avoid that... but thought editor I used on win was smart enough not to do that...
<vila> yup
<mgz> _func is something I'm trying out as a way of writing ctypes code
<vila> no need to rewrite history, just fix it ;)
<mgz> there are bunch of annoying issues with ctypes wrappers, that make it close to impossible to write good code with them
<mgz> firstly, if you don't define the params, you risk breaking on bad arguments in really bad ways
<mgz> secondly, you need to lazily load functions if you want to import the module on a platform without that library
<mgz> thirdly, the basic wrapper is a horrible class with a useless docstring
<mgz> fourthly, to test your wrapper properly you need to cover the error cases, which isn't always easy to get from the underlying library
<mgz> so, this way does the definition inside a normal function with a docstring, on an attribute that can be overriden for tests
<mgz> it's similar to having a named global in the module that partners the function, but more systematic
<mgz> works out at a lot of boilerplate though
<vila> but you can define this attribute as a real method and get the same benefits AFAICS
<mgz> how do you mean?
<vila> _get_env_var_w = ctypes.WINFUNCTYPE(DWORD, LPCWSTR, LPWSTR, DWORD)(88	+ ("GetEnvironmentVariableW", ctypes.windll.kernel32))
<vila> and still override that in tests
<mgz> as a module global?
<vila> yes
<mgz> we can't do that - kernel32 doesn't exist on nix.
<mgz> would prevent import win32utils working there.
<vila> these tests requires win32 anyway
<vila> ha
<vila> this code is already protected by has_ctypes and plaftorm = win32 no ?
<vila> well, winver != 98
<mgz> nope, it could be, but that has downsides too.
<vila> what nope ? it *is* covered by: if has_ctypes and winver != 'Windows 98':
<mgz> with a lot of functions from different places, you end up loading many libraries at import type you may not need
<vila> oh.
<vila> (bit slow this morning)
 * vila scratches head
<mgz> >>> print sys.platform, win32utils.winver != 98
<mgz> linux2 True
<vila> I still don't get it, we've been able to import lazily without this trick
<mgz> ^was the 'nope'
<vila> let's start again :)
<mgz> if you look at existing code of this kind in osutils and win32utils
<vila> The attribute trick makes me frown, can we do without it ?
<mgz> you'll see they use a wide range of different tricks
<mgz> vila: I'm still looking for a way that doesn't suck :)
<vila> hmm
<mgz> a decorator that does the boilerplate here is one idea, but then that's doing more work at startup and is even more magical
<mgz> you need function specific code, but most of the wrapper wants to be just like all the other wrappers
<vila> yeah, so you have cache local to your function, why not have a shared one then (for the WINFUNCTYPE), you can still inject whatever you need for tests
<vila> or may be just documenting *that* magic (caching in the function attributes) is good enough to start with ?
<vila> But is it even worth caching when the others don't ?
<mgz> many of the other functions only get called once
<mgz> but having everything use the same idiom at some point would make life easier
<vila> right, so some of the things you said here are worth documenting in the proposal ;-)
<mgz> ^one option I haven't mentioned is ctypes allows an errcheck function attribute for the specific logic you need to add, but then the exposed object is still the generated class with the useless docstring
<vila> caching because used more than once (but still, why on the function itself ;)
<vila> if the docstring is the issue can't you just override it or provide a wrapper ?
<mgz> there's a point with ctypes where you have so many wrappers you forget where one starts and the next begins :)
<vila> bah, this discussion is becoming far longer than it should :-/
<mgz> :D
<mgz> you've given me some useful feedback.
<vila> mgz: reviewed, do the tweaks you feel necessary
<mgz> how would you feal about cfunc = <function_name>._c_function ...or can you think of a better naming scheme?
<vila> mgz: sry, missed that,
<vila> hmm, this sounds better
<mgz> pants, forgot news.
<mgz> lunch!
<mgz> blom blom.
<jelmer> mgz: hmm
<jelmer> I think I'm going to need a dictionary for that one
<mgz> just making funny noises :)
<mgz> okay, I need  break
<mgz> +a
 * lamont boggles at non-monotonically increasing revnos
<nyuszika7h> )
<nyuszika7h> Oops, auto-attach again >_<
<lamont> if a is at rev 10, b is based on rev 7 + a change + merge of a, and I bzr pull into a from b, then the revno of a becomes smaller... this does not seem sane to me
<lifeless> lamont: you've created a shorter left-hand-path
<lifeless> lamont: you may want to disable such pulls by setting the config option for that
<lamont> lifeless: I believe that I do, yes.
<lamont> Is that clear in the manpage?
<lifeless> look for append_revisions_only in 'bzr help configuration'
<Dov_Rine> what's the best way to install bazaar for use as a redmine repository?
<lamalex> lifeless, is there a simple
<lamalex> er whoops imeant to hit backspace not enter
<Noldorin> hi jelmer
<jelmer> hi Noldorin
<Noldorin> jelmer, hey.
<Noldorin> jelmer, so with regards to bzr+ssh, how is the url translated into a path on the SSH server?
<jelmer> Noldorin: it's the path part of the URL
<jelmer> Noldorin: bzr log bzr+ssh://foo.com/var/www/bla accesses /var/www/bla there
<jelmer> Noldorin: it supports ~
#bzr 2011-12-06
<Noldorin> jelmer, ah ok...
<Noldorin> so absolute path
<Noldorin> fair enough
<Pegasus_RPG> Hello. Quick question: if I bzr cp a file to another name, will future changes to the original be propagated to the copy?
<vila> hi all !
<jelmer> hi vila
<mgz> morning!
<jelmer> mgz!
<vila> jelmer: regarding bzr-upload, as mentioned in the review, I want to use dedicated series, not maintain compatibility at all costs on trunk
<vila> hey mgz
<vila> standup ?
<jelmer> vila: the plugin's metadata suggests it still supports 2.4
<vila> because we didn't bump the internal API for 2.5...
<vila> so apples and oranges
<vila> and as mentioned in NEWS, the code is still compatible with 2.4 so far, only the tests requires 2.5
<vila> but one needs to start somewhere :)
<vila> the intent is to have a 1.1.0 when bzr-2.5.0 is released
 * jelmer looks for his headset..
<jelmer> got it
<jelmer> vila, mgz: mumble?
<vila> jelmer: there we are ;)
<vila> jelmer, mgz : can you have a look at https://code.launchpad.net/~bzr/bzr/doc/+merge/84069 ? Given my implication I can't review it anymore ;)
<alansaul> Hey guys, how can I get previous versions of a file that I accidently deleted?
<alansaul> I dont want to take everything back, just them, can i just do a revert x.rb
<jelmer> vila: sure
<mgz> ...it didn't seem from the comments I saw go past there were any issues with that mp vila
<mgz> alansaul: yup.
<vila> mgz: yup, no issues AFAICS, but voting on it myself seems a bit... bizarre
<vila> oh crap a > 2.000 lines proposal :-/ Hmm, at least the submitter signed with his own blood that it's mechanical ;)
<mgz> we can throw things at him if it breaks stuff :)
<vila> Yeah, the most irritating part is to think that annotations will be broken one way or the other :--/
<jelmer> vila: +1ed
<vila> jelmer: thanks
<mgz> vila: on the annotations front, just think of it as jelmer accepting all blame from now on
<vila> hehe
<mgz> okay, made a teeny bit more work for the pilot, time for lunch
<jelmer> vila: when you have a chance, a review of https://code.launchpad.net/~jelmer/bzr/hpss-call-counts-3/+merge/84494 would be great - it fixes the hpss call count for lightweight checkouts which is causing spurious failures
<jam1> jelmer, mgz: I'm getting a weird bug with latest bzr.dev
<jam1> It is trying to take a lock: "~jameinel/u1db/index-transformations/.bzr/branchlock"
<jam1> shouldn't that be: ~jameinel/u1db/index-transformations/.bzr/branch/lock
<jam1> ?
<jam1> It looks like a bad trailing-slash normalization bu
<jam1> bu
<jam1> bug
<jelmer> hey jam1
 * jam1 goes to a speech therapist for stuttering :)
<jelmer> jam1: looks like you're also hitting a bad trailing-'g' normalization bug :-P
<jelmer> it does seem like that could be related to the recent URL changes
<mgz> what fun.
<jelmer> jam: is this on Windows?
<jam> currently, yes
<mgz> jam: file a bug with the command to run, we can probably repo and fix.
<jam> jelmer: http://paste.ubuntu.com/761635/
<jam> mgz: I'm just running 'bzr push' to launchpad :)
<mgz> o_O
<jam> k, weird, I also get it with bzr.dev -r-200
<mgz> r6079 is one known breaker
<mgz> if r6078 works and that one doesn't, means there's an extra regression the test suite didn't catch
<jam> well -200 is 6145
<jam> mgz: well, I generally keep up to date with bzr.dev, so 6078 seems a bit to old, but it does indeed work and 6345 does not
<jam> too
<jam> now I'm at "nothing to push", so I can't continue to validate it
<mgz> quick, write more code! :)
<wgz> okay, I don't get it just pushing to +junk so there must be something specific going on with the branch layout
<jam> mgz: https://bugs.launchpad.net/bzr/+bug/900764
<ubot5> Ubuntu bug 900764 in Bazaar "failure to push to Launchpad 'branchlock'" [Critical,Confirmed]
<wgz> ...or with u1db
<jam> Looks like I was using rev 6322 this morning, and I'm using 6345 when I noticed things were broken.
<jam> wgz: you can't hide from me :)
<jam> even weirder, I think I had successfully pushed a couple of times. Maybe it is a remote autopack issue?
<jam> but that shouldn't trigger a bug locking the branch
<wgz> oo... ooooo
<wgz> repacking would be extra fun.
<jam> well the failure is early on in bzrlib.push._show_push_branch
<jam> during the first remote write lock call on the Branch.
<jam> well, something is working now...
<wgz> how do we get logs from the launchpad side?
<jam> I wonder if it was a display bug, coupled with a temporary Launchpad failure.
<wgz> hm.
<wgz> that's an interesting thought, and testable.
<jam> mgz/wgz: Interestingly, I have 4 emails in my inbox from Launchpad talking about failures to generate merge proposals.
<jam> looks like something with the librarian there
<jelmer> yeah, the librarian was down for a while becuase of hardware problems
<wgz> I got a 503 from the librarian just before you posted.
<jelmer> it's not involved in code hosting though, as far as I know
<wgz> coming back and looking at the bug report again, I don't think it can be a bzr.dev regression
<wgz> the LockDir url is constructed on the launchpad side and just being reported to the client
<vila> jelmer: done
<jelmer> vila: thanks
<mgz> vila: for some reason, I'm not getting your mail sent to the bzr list
<mgz> can read it in the html list archive, but neither of your last two "week in" emails got to my inbox
<vila> o_O
<vila> mail log confirms the one for this morning was sent
<vila> not received but I'm pretty sure that's how I configured my subscription
<vila> (i.e. don't send me my own mails, thanks)
<mgz> it got as far as the list, but didn't then get back out to me
<mgz> and your last week's one had the same issue, I only saw it existed because I got the reply-to-the-reply
<vila> bah, vila, learn to read, he said the mail went to the list, not a problem on your side
<vila> mgz: that leaves: 1) an issue at your provider (aggressive spam filtering), 2) a wrong filtering on your side ?
<vila> mgz: they don't like French maybe ? ;-p
<mgz> it's canonical then google, and didn't get spamified
<vila> oh, on google ?
<mgz> I was wondering if there was anything else odd about either message that might cause it to get dropped
<vila> see ? They know far too much already :)
<vila> hmm, I can't imagine what can be different, let me check again
<vila> mgz: here is my local copy: http://paste.ubuntu.com/761701/
<vila> mgz: the only lines that you probably won't find in your copy are the 'X-Draft-From' and 'Xref' ones which are local
<vila> you should have more Received: lines though
<vila> in other news, consistent oops on https://code.launchpad.net/~gz/bzr/mv_removed_non_ascii_898541/+merge/84609
<vila> some one is trying to get between us, mgz, what a nefarious (but hopeless) conspiracy !
<vila> there is a suspicious "Warning: <type 'exceptions.KeyError'>: 'branch'" in the oops page...
<vila> just after a: "Warning: Macro expansion failed"
<vila> any recent bzr deployment on lp ?
<mgz> don't think so, but given jam's earlier experience something is up with the launchpad codehosting
 * vila nods
<vila> the librarian failure seem to have triggered a bunch of import failures.... and the importer caught them as lp down times and happily retried them, ending up with 0 additional failures \o/
<vila> it did flip-flop a lot (back/down/back/down) but still managed to retry all the right ones
<mgz> what's one of your oops # vila?
<vila> (Error ID: OOPS-cbc7444249203b34468eab8a253cf7f1)
<mgz> ...actually it's so consistent I can also get my own on that mp
<vila> there are several urls with %7Egz (I thought we settled on ~ being legal and as such never quoted anymore, may be not landed on lp ??)
<mgz> ...the oops page is really not very browsable
<vila> yup :)
<jelmer> vila: yes, that's not on LP yet
<vila> with 'that' being 'stop quoting ~' ?
<mgz> alright, is librarian related, forgot they put the diffs there
<vila> yeah, librarian related but librarian is back. Did you propose while it was down ?
<mgz> (what jam was saying earlier about getting diff generation failure email should have twigged earlier)
<vila> s//submit/
<mgz> it lost some files apparently, they need reuploading
<mgz> anyway, they're on it, so won't bug 'em further
<vila> jelmer: wow, that was confusing (the test rewrites), I got it now
<mgz> vila: oh conflicts expert
<mgz> how in the hell you you get to the state:
<vila> 2.4.2 is still in -proposed ?
<mgz> added: config.py / conflicts: Conflict adding file config.py. Moved existing file to config.py.moved.
<vila> mgz: different file-ids for the same file
<mgz> I can only get to a added: removed: conflicts: state.
<mgz> not a modified one.
<mgz> without the removed.
<vila> what branches do you encounter that in ?
<mgz> the repo of a bug in qbzr.
<mgz> I have the guy's branch state, but not clear instructions on how he got there, so I'm not sure how to write the test.
<vila> bzrlib.tests.test_conflicts
<vila> ha, crap, you don't like the way these tests are written
<vila> I had an idea about how to rewrite them but I've yet to do it ;)
<vila> at least you'll get the bits you need
<vila> also, you can have a look at po_merger tests which are script-based and easier to grasp,
<vila> basically you create a branch with all the stuff you need and then branch from the "right" revisions
<mgz> anyway, just creating two branches with the same file and merging doesn't do it.
<mgz> as in, diverging from the same root
<vila> mwhahaha, I want some of either 1) what you're smoking, 2) the tweaked bzr addressing the parallel import issues you're using ;)
<vila> if merge doesn't conflict merging the same path with two different file-ids it's probably because both paths use the same file-id :)
<mgz> it conflicts alright, but not the right way
<vila> text conflict ?
<mgz> I get added/removed, the example branch just has modified
<mgz> but with the conflict saying .moved has been created
<mgz> the diff is just a line in the file
<mgz> my diff is two files, one added, one removed
<vila> meh, I'm lost, can you paste your test ?
<mgz> ...I should look at the history in qbzr
<mgz> o_O there is only one revision
<wgz> vila: zip attachment in bug 815822
<ubot5> Launchpad bug 815822 in QBzr "AttributeError: 'NoneType' object has no attribute 'is_ignored'" [Undecided,Incomplete] https://launchpad.net/bugs/815822
<vila> jelmer: looking at https://code.launchpad.net/~bzr-core/ubuntu/oneiric/bzr/sru-2.4.2/+merge/81039 , shouldn't some sru team be subscribed there ?
<wgz> edit testrepo-fb-checkout/.bzr/branch/location to point to the right abspath of where you unpack it, then inspect testrepo-fb-checkout
<wgz> okay, I think I have an idea
<vila> grrr, of course I read that after doing it :)
<kirkland> jelmer: hey there!  back to my line of bzr/git import questions
<vila> wgrant: obviously the .moved file is not there anymore
<kirkland> jelmer: so i did my 'bzr up' in each of a dozen or so of the dirs that I imported from git into bzr
<vila> wgrant: sry, bad completion
<vila> wgz: obviously the .moved file is not there anymore
<kirkland> jelmer: now, it is customary to push each of those to its own branch in LP?
<kirkland> jelmer: for history/tracking purposes?
<mgz> vila: it's just an idea, I still want the expert opinion :)
<kirkland> jelmer: or how do others handle that?
<mgz> I think the way I was doing it was wrong, I have two child branches both create a file then merge one to the other
<jelmer> hi kirkland
<kirkland> jelmer: howdy :-)
<mgz> perhaps what's needed is a child branch to create a new file, move it over the file in the parent branch, then merge child to parent
<kirkland> jelmer: so there are a handful of tags (v1.5, v1.4.3, v1.7, etc)
<jelmer> kirkland: tags will be stored in the branch as well ("bzr tags")
<vila> mgz: or create a new file with the same path in branch A and B, then merge ../B
<jelmer> kirkland: but branches from git are usually pushed as separate branches onto Launchpad
<kirkland> jelmer: as I described?
<mgz> vila: that gives me the conflict I had, which is added f, removed f
<vila> mgz: but from a quick look, the stuff in error.zip is incomplete
<mgz> rather than modified f
<jelmer> vila: see poolie's comment on that MP
<jelmer> kirkland: it depends on your situation a bit - most people register launchpad imports to track branches in git
<jelmer> kirkland: what's the situation in which you're using bzr-git?
<kirkland> jelmer: I'm helping my new company migrate from git to bzr/Launchpad
<vila> jelmer: I followed the comment to bug #848064 and there he says (and I pretty much agree) that this is not specific to bzr (or at least we don't have evidence so far)
<ubot5> Launchpad bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed] https://launchpad.net/bugs/848064
<kirkland> jelmer: they have one project (private/proprietary in Launchpad)
<jelmer> kirkland: ah, I see - in that case what you described indeed makes the most sense - push each separate branch import from git as a separate branch on Launchpad
<kirkland> jelmer: great
<jelmer> kirkland: the tags should come along
<kirkland> jelmer: okay, I'll have a look
<vila> mgz: ctrl-alt-del, looks like I misunderstood
<jelmer> kirkland: (and new versions of bzr-git will in fact no longer create separate directories for tags)
<kirkland> jelmer: oh, interesting
<kirkland> jelmer: okay, thanks for your help, cheers!
<vila> mgz: .moved is the THIS file (confusing)
<vila> mgz: therefore, the added one should be the OTHER file
<vila> mgz: bbiab
<jelmer> vila: argh, Option didn't have a help argument in 2.4 :-(
<mgz> ha! got the repo
<mgz> ...that was the most convoluted thing ever
<vila> jelmer: and you encounter that in what context ?
<vila> mgz: so, fresh from the bug, he did delete .moved file and AFAICS we don't have the branch he was merging from
<vila> mgz: additionally, his dirstate file seem to miss the revid for the merge too :-/
<vila> mgz: on the other hand, he provided the .zip to reproduce a bug which is not related to conflicts.
<vila> mgz: in a nutshell, the branch he provided may not be one you can re-create
<mgz> vila: I don't have the exact dirstate he got, the 'modifed' thing is mystifying as the bug needs no file-id to repo
<mgz> but I have a series of steps that gets that problem
<vila> mgz: with bzr-2.3.4 ?
<mgz> with current bzr, the logic error in qbzr is reasonably clear
<mgz> it's just less obvious how to actually trigger it
<mgz> I'll wave the test case in front of you
<mgz> (shortly)
<vila> k
<jelmer> vila: current bzr-svn trunk is broken with bzr 2.4
<vila> ha, because of the new config support ?
<vila> jelmer: I thought I mention the compatibility part not being addressed when I first submitted but then thought you had different series targeted at 2.4 and 2.5 and finally, I forgot about it :-/
<jelmer> vila: np, it's not too hard to work around
<vila> jelmer: so, more than help should cause problems no ?
<jelmer> vila: some other minor regressions, fixing them now
<vila> jelmer: what kind ?
<jelmer> vila: not related to config, but apart from that bzr-svn trunk is 2.4-compatible
<vila> but not 2.3 ? Where do you draw the line ?
<vila> jelmer: stable + trunk ?
<jelmer> vila: 2.4 and bzr.dev at the moment
<vila> k
<jelmer> vila: it varies, I dropped 2.3 support a month or so ago
<jelmer> vila: I usually aim for the latest stable series and bzr.dev, but it depends on how hard it is to stay compatible
<vila> now that you mention it, you probably want to add a .id attribute in your store
<jelmer> vila: anyway, I just noticed it as I was trying to actually switch over some code to use the new options stuff
<vila> right, it's opt-in at the option level
<vila> but even the new options can still be read/modified with the old implementation
<jelmer> vila: right, but how well will 2.4 work?
<vila> bzr-2.4 use the new config implementation for only one (or a few) options
<vila> so it should work at it works before :)
<vila> worked
<vila> as far as bzr-svn is concerned, get_config_stack will not be called and since no branch option use get_config_stack in bzr-2.4 nothing has changed
<vila> jelmer: unless you encounter a scenario I can't imagine ?
<jelmer> vila: I'm wondering whether I should start using get_config_stack in bzr-svn, or if that will affect compatibility with bzr 2.4
<vila> that should even break with bzr-2.4, there is no get_config_stack there
<jelmer> vila: there is on SvnBranch :-)
<vila> ooooh, that
<vila> hmm
<vila> that's a tricky question :)
 * vila looks at bzr diff -rbzr-2.4.2.. bzrlib/config.py
<vila> jelmer: registering options looks suspicious
<vila> no cmdline overrides
<jelmer> vila: that's actually something that seems to work
<vila> k
<jelmer> vila: did cmdline overrides work at all in 2.4?
<vila> it didn't exist
<vila> just listing
<vila> ha, remote (smart) branches broken, no impact or bzr-svn ?
<jelmer> vila: nope - remote branches can't access svn stuff anyway, not even in bzr.dev
<vila> jelmer: and no expansion either, so overall I saw nothing likely to fail, the basic pieces were in place and if some internals have changed, they should already work in 2.4
<jelmer> vila: cool
<vila> and given the current read/write scheme using both implementations should be ok
<vila> once this model change (so bzr.dev only) it will become dangerous to access one option with both implementations
<vila> but even there, that will require modifying the value, so unlikely to be encountered soon (except for GUIs may be)
<mgz> okay, have a test
<mgz> don't really understand all this monkeying but hey
<mgz> vila: do you have a sec to look at a diff and tell me ways to make it saner?
<vila> mgz: shoot
<mgz> vila: http://pastebin.ubuntu.com/761875/
<vila> the 'remove/add/rename_one' dance you mean ?
<mgz> yeah, and any of the other branch creaty bits.
<vila> well, the branch creation bits are not that bad (unless you can create a richer branch in make_branch_and_tree)
<mgz> I guess remove/os.rename/add would work
<vila> yup, was about to ask/suggest about using os. everywhere in tree nowhere
<vila> as I understand it, error.zip was obtained after shell commands, with no bzr commands involved
<vila> so qbzr may be confused because some files referenced in the dirstate are not there anymore and some other have totally different content
<mgz> yeah, but I can't get into that state, though I can do this similar one.
<vila> oh, misread, make_branch_and_tree is the basic bzr one
<vila> so po_merger tests use branch_builder and scripts which can be more readable, but your tree setup being 10 lines long... that would be overkill
<vila> you can also add assertLength(1, tree.conflicts()) to complement self.assertPathExists("parent/f.moved")
<vila> EOD'ing
<mgz> thanks vila.
<vila> mgz: rhaa, my comments were confusing. One thing you should think about is that the bug may be caused by some difference between the dirstate content and what qbzr thinks about the wt. As it's written, your test may not reflect that as it uses an in-memory tree which *may* not trigger the same behavior
<vila> test scripts running complete commands are less likely to suffer from that which is why I mentioned them as opposed to the bzr-upload ones
<vila> there, that's should be clearer ;)
<vila> hmm, almost, by in-memory, I mean a wt with its internal state as opposed to loaded from the dirstate
<lamal666> lifeless, is pyjunitxml already integrated in testtools somehow?
<jelmer> lamalex: it's a separate package
<lamalex> i know, but im wondering if there's a simple integration path that i haven't figured out
<lifeless> lamalex: in what sense integrated?
<lifeless> if you mean 'report tests using it',most folk I know have been setting that up in their local test glue, or if they have non via subunit
<lifeless> there is a merge proposal just waiting copyright signoff to add a junitxml.main as a convenience for folk too
<lamalex> ah, i guess we dont really have any test glue we've just been doing python -m testtools.run discover
<lamalex> which is probably why im having a hard time figuring out how to fit the two together :P
<lifeless> right now the easiest thing will be
<lifeless> python -m subunit.run discover | subunit2junitxml -o tests.xml
<lifeless> (I think, thats from memory - use -h and season to taste)
<lamalex> yah
<lamalex> ok, thanks lifeless
<lamalex> i honestly would have never figured that out
<lifeless> heh
<lamalex> lifeless, does testtools output subunit by default/
<lifeless> no, subunit.run does (which is testtools compatible)
<lamalex> ahh
<lamalex> woop dere it is
<poolie> hi all
<wgz> hey poolie
<poolie> hi there wgz, how's it going?
<wgz> good, a little bit of an interesting launchpad day. how was your weekend?
<poolie> really nice
#bzr 2011-12-07
<vila> oh, hi all !
<mgz> morning all
<jelmer> hi mgz, vila
<vila> _o/
<lelit> hi everybody! I'm trying to understand the "remove-branch" command, and fail to see its purpose. My goal is to "retire" some remote branch, after it was merged in trunk and thus not anymore "active"...
<lelit> trying that command, I see it apparently deletes only the .bzr/branch subdir of the branch...
<lelit> given that the remote branches are in a "shared" repo (for a given user), is it safe to simply "rm -rf" the single branch, or does that corrupt the shared repo in some way?
<mgz> lelit: it's safe.
<lelit> great, thanks. OOC, do you know the purpose of the remove-branch command? when is it useful?
<mgz> lelit: not removing remote workingtrees with it is arguably a bug. mostly it rmbranch does just boil down to rm, the command exists so there's a consistent interface for different branch schemes
<lelit> I see, thank you
<mgz> I bet half these bzr-explorer file watcher bugs are just from accidentally including .bzr in the followed paths
<mgz> which then clashes with bzr trying to do internal work there at the same time
<vila> mgz: be bold, bet on the other half ;)
<mgz> the rest seems to be other misc locking/permission failures - some IDE holding files open, etc
<mgz> woho! failures.
<mgz> is there a way to get merge to not set the submit branch on things?
<mgz> I do too much editing of .bzr/branch/branch.conf as it is, and I merge sideways more than up.
<lelit> btw, a coworker yesterday asked me the difference between "submit-branch" and "push-branch", and I didn't find a satisfactory answer...
<vila> mgz: --no-remember
<vila> lelit: push_location is where push goes, submit_branch is where you merge from (the assumption is that it's where you *will* submit)
<lelit> thnx
<vila> mgz: also, 'bzr config --remove submit_branch
<vila> mgz: or 'bzr config submit_branch=<here, and nowhere else from now on>'
<mgz> ah, yes, `bzr config` is a bit easier than editing stuff in .bzr for single changes, slower when you want to nuke a bunch of stuff though :)
<mgz> an option to not do it in the first place would be nice, lots of merges aren't from a submit location
<vila> mgz: 'bzr merge --no-remember ../one-shot' ?
<mgz> next time I'll try and remember no remember but I doubt I'll remember
<mgz> okay, end of qbzr time and start of lunch time
<vila> .. which is why the default is --remember :-P
<vila> mgz: a fun one for you: try to make a test called 'test_base_dir' succeed
<vila> mgz: rats, the missing bit is also a spoiler :-/ The test should inherit from TestCaseInTempDir
<wgz> a repeat of bug 581298 maybe? :)
<ubot5> Launchpad bug 581298 in Bazaar "bt.test__walkdirs_win32.TestWin32Finder.test_dir fails without ever being run" [Undecided,Fix released] https://launchpad.net/bugs/581298
<vila> oooooh :)
<vila> indeed
<mgz> right, time to work out what to do with trace
<dannf> the libvirt/qemu-kvm UDD trees on LP seem to be hosed - attempts to branch from them give an error
<dannf> http://paste.ubuntu.com/762973/
<dannf> is this the right place to look for help on that?
<jelmer> dannf: hi
<jelmer> dannf: this is the right place
<dannf> jelmer: cool
<jelmer> dannf: this is bug 848064
<ubot5> Launchpad bug 848064 in Ubuntu Distributed Development "Revision not present branching from udd-imported branches on lp" [Critical,Confirmed] https://launchpad.net/bugs/848064
<dannf> jelmer: sounds like reimporting might be an option? what does that entail?
<poolie> hi all
<wgz> hey poolie!
<poolie> hi there
<GRiD> hi poolie, wgz
 * wgz waves at GRiD
<dvheumen> Hi, want to check something, just to be sure: If I create a symlink, add it to the working copy and then change my mind and 'bzr revert symlink'. Then it should not delete the symlink right?
<dvheumen> (add --> not yet commit)
<dvheumen> I'm asking because I think it's a bug in bzr
<abentley> dvheumen: No, we have special handling for files when reverting, but not for other types.  If you want to unversion the symlink without deleting it, "bzr remove --keep" will do that.
<dvheumen> abentley, then you don't consider this undesired behavior?
<abentley> dvheumen: correct.
<dvheumen> hmm... okay ...
<dvheumen> btw, do you mean remove or revert?
<abentley> dvheumen: I mean remove.
<dvheumen> so, in the case of revert?
<dvheumen> it seems strange to me to delete something that hasn't been under control in the first place
<abentley> dvheumen: Revert tries to return to to your previous state.   It doesn't consider how you got there.
<dvheumen> yeah exactly, so why delete a symlink that was 'originally' there before I added it to the working copy
<abentley> dvheumen: Because the previous state is the last-committed state, and that didn't have a symlink.
<abentley> dvheumen: We do the same with directories.
<dvheumen> but you make an exception for files then, doesn't that seem strange?
<abentley> dvheumen: Even with files, the exception is based on filetype, not based on whether you added them without committing.
<abentley> dvheumen: And we make that exception because deleting a file can cost the user a lot of data, whereas directories and symlinks don't contain much data in and of themselves.
<dvheumen> hmmm... okay, in that case it's not a bug :P
<dvheumen> (although I'm not completely sold on the reason ;-)
<dvheumen> (yet)
<dvheumen> thanks :)
<abentley> dvheumen: The more junk you leave in the way, the more you open yourself up to conflicts later on when tree updates create an entity with the same name.
<dvheumen> abentley, yeah, that's true. However, this symlink probably has some meaning and when I revert I would do this with a thought such as "on second thought, no I don't want to do this versioning operations". And it wouldn't occur to me that I'm actually deleting a file, changing a directory structure.
<dvheumen> so I'm accidentally touching something that I wouldn't expect
<dvheumen> although, maybe I should do some more reading, since it *is* reported that the symlink gets deleted
<abentley> dvheumen: Sure.  But there are tradeoffs here, and there isn't *much* meaning in the symlink.
<dvheumen> yeah, I know :)
<dvheumen> I should just get used to this behavior
<dvheumen> anyways, you're just in time ... I hadn't yet submitted the bug report :P
<abentley> dvheumen: You can also use shelve --all as an alternative to revert.  That will allow you to correct any surprising behaviour.
<dvheumen> I'll keep that in mind
<jelmer_> hey poolie, welcome back
<poolie> hi there, thanks
<LeoNerd> bzr checkout; edit stuff... bzr commit --local {because the laptop was offline}
<LeoNerd> How do I now push it upstream?  bzr push  claims no location known or specified. I know I -can- copypasta from  bzr info  but that feels awkward and hackish
<LeoNerd> Ahhh.. bzr push :bound
 * LeoNerd read  bzr help location-aliases
<Noldorin_> hi folks.
<Noldorin_> is there any way to provide secure access to a bzr server other than via SSH?
<jelmer> Noldorin: over http/https
<jelmer> or, alternatively, if you don't require a smart server you can also use sftp/ftp, smb, ...
<Noldorin__> jelmer sftp is still ssh... but yes the other options sound appealing. how does https speed compare to smart server?
<Noldorin__> (with ssh)
<jelmer> Noldorin_: the smart server can be used over HTTPS as well, though it requires some setup
<Noldorin__> ah right
<Noldorin__> jelmer, but not ftp?
<jelmer> Noldorin_: right, it would be pretty hard to tunnel something custom over ftp :-)
<Noldorin__> yeah heh
<Noldorin__> i could imagine!
<Noldorin__> jelmer, hmm will have a look, thanks for tip
<Noldorin__> be back in a bit
<jelmer> Noldorin__: ssh should be simplest to setup though (hardly any setup at all), any reason you're not using that?
<Noldorin__> jelmer, alas, windows server = ssh (almost) impossible
<Noldorin__> unless some has some good tips for it
<Noldorin__> tried a lot, but always some sort of error.
<Noldorin__> hmm
<Noldorin__> openssh for windows just isn't maintained :-(
<Noldorin__> maybe there are decent commercial solutions. who knows
<jelmer> ah, hmm
<jelmer> I don't have any experience with SSH servers on Windows
<Noldorin__> yeah. not sure many in the world do :-P
<Noldorin__> you use openssh sshd on linux though yes?
<jelmer> Noldorin__: yep
<Noldorin__> jelmer, maybe cygwin environment then...hard for windows services though
<Noldorin__> hmm
<Noldorin__> brb restarting
<Noldorin> jelmer, back
<jelmer> hi Noldorin
<Noldorin> hi
<Noldorin> did you have any thoughts while i was gone?
<jelmer> I had plenty, but nothing about SSH on Windows I'm afraid..
<Noldorin> heh
<Noldorin> fair enough
#bzr 2011-12-08
<Noldorin> jelmer, how's bzr-git and whatnot going anyway? :-)
<Noldorin> dw, won't pester you about my issue this time heh
<jelmer> Noldorin: mostly working on finishing some of the other stuff I've been working on at the moment, will get back to it after I finish this
<jelmer> (faster smart server, feature flags, colocated branches, multi-tarball support in UDD)
<Noldorin> cool :-)
<Noldorin> what's UDD though?
<Noldorin> also not familiar with feature flags heh
<wgz> Noldorin: on the grounds negative results are useful too, it would be great if you could post to the bzr list saying what you tried on the sshd front and how it failed
 * jelmer waves to wgz
<Noldorin> wgz, heh, i've largely forgot now. it was a traumatic experience. but i may be able to summarise the basics still.
<jelmer> g'night all
<wgz> night jelmer!
<Noldorin> night jelmer
<vila> hi all
 * vila entering 2.5b4 freezing
<vila> thanks to whoever merged up 2.4 to trunk, one less hassle :)
<vila> mgz, wgz: Can you run 'BZR_PLUGIN_PATH=-site make po/bzr.pot' in bzr.dev and look at the resulting diff
<vila> there seem to be more stuff for the registry options (good) but also some deletions (not all  good)
<vila> not to mention the irritating spurious line numbers changes but that's a different topic (I still think there should be a way to use filters to avoid that)
<vila> mgz, wgz: concretely, I'm concerned about '--strict' and '--directory' options for push being deleted
<vila> the rest seems fine
<vila> jelmer, poolie, mgz: about to commit -m 'release 2.5b4', so: pqm.lock(RM)
<vila> scratch that: pqm.unlock()
<lifeless> deleting -d? why?
<lifeless> also, can we please unbreak resolve --all path-to-tree ?
<vila> bug # ?
<vila> resolve --all is evil in general just don't use it
<lifeless> perhaps
<vila> -d is not deleted from the command, only from the .pot file which may be related to mgz deleting some global options which is why I want him to check
<vila> lifeless: I mean, --all remove the conflicts without trying to resolve them nor clean up, this should not be needed anymore
<vila> lifeless: if you encounter case where it breaks, please file bugs
<lifeless> vila: I use it every time someone deletes a directory from LP
<lifeless> vila: and we get directories that can't be removed or whatever
<lifeless> its the simplest way to get things correct
<vila> lifeless: resolve --take-other ? bzr.transform.orphan_policy=move ?
<lifeless> vila: far too hard
<vila> Did I miss a smiley there ?
<lifeless> no
<vila> --take-other is too much compared to --all ??
<lifeless> to remember that it exists when --all will DTRT, yes.
<vila> --all will not do the right thing
<lifeless> vila: you say that, but it does
<vila> hmm, I've seen it involved in too many bug reports to agree there, but if it works for you, you know why :)
<lifeless> https://bugs.launchpad.net/bzr/+bug/901580
<ubot5> Ubuntu bug 901580 in Bazaar "cannot resolve --all path-to-tree anymore" [Undecided,New]
<vila> but you started with 'can we please unbreak resolve --all path-to-tree ?' so I'm a bit confused
<lifeless> yes, I would like that command to work as it used to.
<vila> lifeless: when did it start failing ?
<vila> I don't remember recent changes there
<lifeless> vila: I'm not sure, 2.4 probably
<lifeless> I'm not tracking .dev these days
<lifeless> Not deliberately, just seems to have happened
<vila> jelmer, poolie, mgz: about to submit 'release 2.5b4', so: pqm.lock(RM)
<mgz> morning!
<vila> jelmer, poolie, mgz: pqm.unlock(), double-check your submissions against lp:bzr, news entries in particular should now go into 2.5b5
<vila> mgz: hey !
<vila> mgz: did you read the log here ?
<vila> mgz: or should I re-paste ?
<mgz> ah, I've not yet, but will do so
<mgz> vila: when I last checked, the pot changes were all correct, but I haven't looked at a full b3->b4 diff
<vila> mgz: may be '--strict' and '--directory' were dupes ? Anyway, if you can double-check and tell me, that would be nice :)
<mgz> heh, xgettext comlains about po-merge plugin, amusing (I guess that's why you said -site :)
<mgz> +p
<mgz> "utf8" -> "utf-8" works.
<vila> yeah, already fixed, silly python for using emacs markup with an encoding that is not recognized by emacs
<mgz> ha, I see the issue
<mgz> I make dpush a public command, which added the help for that
<mgz> and it appears 'after' push, so the options with the same help text get attributed to dpush and removed from push
<vila> huh ? --strict doesn't mention 'push' literally ?
<mgz> is says "Refuse to push..." which is also true for dpush
<vila> hehe
<vila> ok, a bit weird but good enough :)
<mgz> everything else looks fine
<vila> mgz: cool, thanks for checking !
<mgz> vila: if I remove the deduping code in export_pot, both headers get printed when combined by the gettext tools in the make step
<mgz> providing that as an option and using it from the makefile may be a good thing
<mgz> ie, rather than removing the entry and adding it further down, the diff is then:
<mgz> +# help of 'directory' option of 'dpush' command # help of 'directory' option of 'push' command
<vila> s/when/then/ ?
<mgz> -#: bzrlib/builtins.py:1158
<mgz> +#: bzrlib/builtins.py:1158 bzrlib/foreign.py:271
<vila> oh, far better no ?
<mgz> yeah.
<vila> also, make po/bzr.pot^W^W export-pot is a bit verbose, if you're tweaking around, can you add a -v option ?
<vila> tag wishlist ;)
<mgz> hm, should I do a b4 release today then?
<vila> mgz: yup
<vila> mgz: did you receive my freeze mail or is it another one that get lost ?
<mgz> that one arrived :)
<vila> ha good
<Mez> Hey.  I've just shelved something - now trying to unshelve it, I get
<Mez> bzr: ERROR: No such file: None
<Mez> how do I fix this?
<Mez> bzr 1.13.1
<Mez> (this bug is apparently fixed in 1.13 ?
<vila> Mez: wow, 1.13 is 2.5 years old, what distro/OS are you using ?
<Mez> a box that's still running jaunty :(
<Mez> Cause someone f**ked up when they created the dev machines.
<vila> correction, 1.23.*2* is 2.5 years old
<vila> correction of the correction, 1.13.*2* is 2.5 years old
<wgz> bug 319790 which *vila* says it fixed in 1.13 but I wouldn't trust him :)
<ubot5> Launchpad bug 319790 in Bazaar "bzr unshelve crashes losing all changes" [High,Fix released] https://launchpad.net/bugs/319790
<Mez> yeah - I'm viewing that now
<Mez> going to poke a backport onto the server
<wgz> using a non-ancient bzr would obviously help, or you could apply the patch from the bug and see if it works then :)
<vila> jaunty EOLed long ago we don't even have a PPA for it ;-/
<Mez> yeah - I know.... :(
<vila> Mez: looking at the patch and the bug comments, I agree with mgz, applying it locally is probably the shortest and safest way to get you unblocked
<vila> Mez: do you have admin rights on this machine ?
<Mez> yes.
<Mez> vila: also - that patch in that bug is present in this version :(
<vila> Merwin: Great ! Quick ! While nobody watch, upgrade to oneiric !
<vila> argh
<Mez> I think you just confused Merwin.
<vila> Merwin: sorry, bad completion :-/
 * vila curses xchat
<Mez> vila - I wish I was allowed.
<vila> Mez: Yeah, just kidding to remove some pain from your shoulders ;)
<vila> so, patch already applied ? Make sure you use the right bzr (bzr version)
<Mez> we've only got one install of bzr on there.
<Mez> (1.13.1
<vila> :-/
<Mez> hmm
 * Mez wonders if he can sshmount that box to his and then use his version of bzr
<fullermd> You could just run a newer version out of your homedir.
<Mez> Not without upgrading python
<fullermd> I said new_ER_, not necessarily new_EST_.
<vila> 2.4 should still work with your version of python (which is ?)
<fullermd> bzr has required py2.4 since...  I dunno.  Ever?
<fullermd> Certainly 1.3.
<fullermd> (13)
<Mez> Couldn't install the lucid version on jaunty - it required a higher verison of python-support
<fullermd> Binary packages are always more strict.
<Mez> Ninjas
<fullermd> The latest 2.3 from tarball should be fine.
<Mez> Ninja *
<Mez> I just mounted the box via sshfs to my machine
<Mez> then bzr unshelved on my machine
<vila> ha crap even my jaunty vm is toasted :-/
<vila> Mez: Pfew, good move ;)
<vila> Mez: unblocked then /
<vila> ?
<Mez> yeah... lol
<Mez> (I added the new files to the main repo"
 * vila stop cursing xchat and blames its keyboard instead
 * Mez <3 bzr but hates it when things like this happen because he has to deal with dodgyness
<Mez> Now all I need is stacked branches working :)
<Mez> not stacked...
<Mez> nested?
<vila> colocated ? :)
<Mez> vila: is what cologated?
<vila> stacked branches, colocated branches, nested trees, the later is not fully implemented yet
<vila> Mez: A set of branches for a single working tree all in the same .bzr directory
<Mez> whatever the bzr terminology for the equivalent of externals
<vila> Mez: more like the default git setup
<vila> nested trees then
<vila> but there are various plugins that already address some use cases
<vila> bzr-externals, scmproj
<Mez> not too sure I understand colocated branches.
<vila> Mez: It mainly matters for big working trees where you don't want to have one for every branch you work on but instead shares it (to avoid long recompiles for example). So you just switch from one branch to another but stay in the same dir
<vila> Mez: you could do that with bzr already as long as you maintain your branches in a separate hierarchy and use a checkout
<Mez> vila - I was going to say - we already do that XD
<vila> right, but some people find the actual setup too complex or just can't figure how to get there
 * Mez setup a nice bzr system
<Mez> but we have some issues with the codebases that we have to work on /systems
<mgz> is there a shortcut for deleting all tags from a branch that doesn't have those revisions present?
<mgz> I know pushing to it will propogate them again, but can try squishing
<jelmer> vila: 2.5b4 uploaded to Debian and Ubuntu
<mgz> darn slow connection, you beat me :D
<mgz> I did have to test some installer changes first, so can't just blame ISP
<wgz> dammit, final tests fail.
<wgz> runtime location change did break qbzr
<jelmer> it seems some of the gpg tests are still broken on sid
 * jelmer drops python-gpgme from the builddeps again
<wgz> okay, revert and rebuild works
<Merwin> hi guys
<vila> jelmer: \o/
<vila> jelmer: file a bug for this gpg failure ?
<mgz> remind me to unbreak my SxS after lunch
<vila> . o O (SxS... looks like a car reference...)
<Merwin> We are using bzr (4-5 peoples on the same repo, commiting many times a day). We have branches (not checkout). Each time someone push somethings, we have to do a bzr merge, and then a commit before pushing
<Merwin> The problem is that in bzr qlog, we finally only see "Merge" "Merge" "Merge" and we have to open each node to see what have been commited
<Merwin> Is there a way to avoid that ?
<vila> Merwin: that's the idea yes, the commit message after the merge is supposed to be a summary
<mgz> Merwin: having an integraty bot thingy really helps here
<Merwin> humf
<vila> Merwin: what would like ?
<vila> s//you/
<Merwin> So if I commit, merge, commit, push
<Merwin> I'll have to write twice the same commit :p
<mgz> he wants a pretty mailine like bzr has
<mgz> *mainline
<vila> yup, but in terms of workflow
<Merwin> vila, with git you can avoid this by not commiting the merge, and just push your own commits
<Merwin> Maybe this is like a checkout+local commits in bzr ?
<vila> Merwin: but then you get a straight mainline
<jelmer> Merwin: what commands would you use in git?
<Merwin> jelmer, humf I didn't remember lemme check
<Merwin> vila, yep, but we have a small team, we would prefer this
<vila> the smallest team starts at 2 and even there you'll have to merge when both people commit on top on a shared revision
<vila> unless you use a central branch and checkouts to make sure you're always up-to-date when you commit
<Merwin> jelmer, with a rebase :)
<Merwin> vila, are localcommits pushed ?
<Merwin> (in chekcout mode)
 * fullermd continues to advocate that the phrase "local commits" be struck from the checkout lexicon.
<vila> if you use a checkout there is no local commits, they always occur on the shared branch unless you use --local in which case you're not using the central branch anymore so you're back to square one and you have to merge locally to resync
<Merwin> humf
<Merwin> Ok, so there is no alternative ;)
<Merwin> It's not really important anyway
<vila> or too many... the bzr-rewrite plugin provides a rebase command if you're into that
<ccxCZ> problems with bzr-svn
<jelmer> ccxCZ: can you elaborate? :-)
<ccxCZ> http://paste.pocoo.org/show/517983/ << previously failed on different revno
<ccxCZ> so I assume the http is unreliable and bzr-svn fails instead of retrying
<jelmer> ccxCZ: right
<ccxCZ> is there some easy workaround?
<jelmer> ccxCZ: pull into the branch X revisions at a time
<ccxCZ> branch -r 1 and then pull -r with increments?
<jelmer> ccxCZ: yep
<ccxCZ> hmm still seems to fetch whole svn history
<jelmer> ccxCZ: it'll cache the history metadata first
<jelmer> ccxCZ: after that it tries to fetch the content of the individual revisions
<jelmer> ccxCZ: that first step is basically just running "svn log -v"
<ccxCZ> failed
<jelmer> ccxCZ: what failed exactly?
<ccxCZ> bzr: ERROR: A Subversion remote access command failed: REPORT of '/svn/e/!svn/bc/63093': Could not read response body: Connection reset by peer (http://svn.enlightenment.org)
<jelmer> ccxCZ: what's the command you're running?
<ccxCZ> bzr branch -r 1 http://svn.enlightenment.org/svn/e/trunk trunk
<jelmer> ccxCZ: does "svn log --with-all-revprops --xml -v http://svn.enlightenment.org/svn/e" work?
<ccxCZ> recieving...
<ccxCZ> ...slow...
<ccxCZ> 46187 to go (from 66033)
<jelmer> ccxCZ: I tried it here as well, and it hung up on me
<ccxCZ> subversion/libsvn_ra_neon/util.c:608: (apr_err=175002)
<ccxCZ> svn: REPORT of '/svn/e/!svn/bc/66033': Could not read chunk size: connection was closed by server (http://svn.enlightenment.org)
<jelmer> so it's mostly an issue of an unreliable server :-(
<ccxCZ> yeah
<jelmer> one way to work around it might be to create a local clone with svnmirror
<jelmer> and then run bzr-svn against that
<ccxCZ> there is such thing? I was on brink of installing svk for that
<jelmer> ccxCZ: it's part of svn itself
<ccxCZ> I see no such command here and neither as a subcommand of svn{,admin}
<ccxCZ> hmm, maybe it's in extras?
<jelmer> ccxCZ: sorry, it's named svnsync
<ccxCZ> gaargh svn, now I remember why I ran away from you
<ccxCZ> okay, managed to create a repo and now syncing revisions
<ccxCZ> wouldn't it be better to ask only for necessary data when doing branch -r 1?
<ccxCZ> https://code.launchpad.net/~vcs-imports/enlightenment/trunk btw
<saper> hi, I did "bzr launchpad-login" sucessfully (I have SSH key there) but I get "Permission denied (public key)" when doing "bzr branch lp:movim", since I don't have any rights on this project. How do I "bzr branch" anonymously while being "lp-loggedin" ?
<fullermd> That's an ssh error, not a LP permissions error.
<saper> thanks. seems like my session couldn't talk to ssh-agent. fixed by logging-in again, thanks!
<jordan> I have a noob question -- I just installed the bzr-gtk package on ubuntu 11.10, but am not seeing an executable for it. How do I start it up? :)
<jelmer> jordan: it's a plugin for bzr
<jelmer> jordan: e.g. "bzr viz"
<jordan> d'oh
<jordan> jelmer, ty
<jelmer> g'morning poolie
<poolie> hi there jelmer
<poolie> jelmer, that is nice to hear about multiple tarballs
<jelmer> poolie: from the standup you mean?
<jelmer> it's a bit disappointing how long that's taking
<poolie> is it slowing down because of anything in particular, like is it hard to test?
<jelmer> I thought I'd finished it - and it seemed to be working, but getting rid of some of the last issues has required some significant changes in bzr-builddeb
<poolie> bugs.launchpad.net/judge is now enabled, jelmer
<poolie> i know it's probably buggy
<poolie> s//buggy
<poolie> some stuff is hardcoded
<jelmer> poolie: thanks!
<jelmer> I don't remember what the bug was I wanted to report, but I'll file it next time I run into it
<jelmer> it did work well for some other stuff, comparing pypy to python2
<poolie> specifically N is hardcoded which is a bit ridiculous
<jelmer> it must depend on what N actually is, though, right ? :-)
<Noldorin> hi jelmer, poolie
<poolie> hi there
<lifeless> poolie: have you taken today off?
<lifeless> poolie: or are you here?
<poolie> both :(
<poolie> but i hope to go out soon
<poolie> what's up?
 * lifeless twistches
<lifeless> oh, I was going to suggest a bit of a chat, if you wanted
<poolie> that would be nice
<poolie> voip/pots/skype?
<lifeless> skype or pots
<poolie> will just finish something here, 2m
#bzr 2011-12-09
<Noldorin> jelmer, just saw your fix committed for an old bug of mine :
<Noldorin> :-)
<vila> hi all !
<jelmer> hi vila
<vila> jelmer: hey !
<jelmer> hi spiv
<mgz> monring all
<vila> mgz: hey !
<mgz> hey vila
<jelmer> hi mgz
<mgz> jelmer: did you see poolie's channel invite?
<jelmer> vila: is there anything left that's blocking us from porting more option users over to the new config system?
<mgz> that would be good to do, in a big bang
<mgz> most plugins have a trunk-tracking release
<jelmer> mgz: so there's nothing in particular blocking it?
<mgz> we'll see when vila returns, but not that I'm aware of.
<mgz> the one issue is if it makesmore overhead without also tackling the multiple-open issue.
<mgz> I think from the instrumentation of the test suite he did vila determined it was okay.
<jelmer> we're already using the config system for some of our options though, right?
<mgz> I'm not comletely clear where the line is.
<vila> jelmer, mgz: so, there are two bugs on the plate: bug #832042 and bug #832046
<ubot5> Launchpad bug 832042 in Bazaar "config files are read for each option" [High,In progress] https://launchpad.net/bugs/832042
<ubot5> Launchpad bug 832046 in Bazaar "needs a way to specify default values for config options by path" [High,Confirmed] https://launchpad.net/bugs/832046
<vila> the later is blocking the system-wide config file stuff imho
<vila> the former... well, if we start caching the config stack in the branch for example, we already address some the un-needed IOs
<vila> but to properly fix it, my feeling is that we need some help from library_state
<vila> other than that, there are various minor bugs that could be fixed while migrating the related options
<vila> and finally, most of the remaining options can be migrated right now
<vila> I should just fdi
<Merwin> patch: **** Only garbage was found in the patch input.
<Merwin> What does it means ?
<vila> I've just proposed a patch against udd which does such a complete migration with only same minimal additions (expanding options by default)
<vila> Merwin: 'patch' or 'bzr patch' ?
<Merwin> bzr patch
<Merwin> thibaut@thibaut-VirtualBox:~/OpenERP 6/OpenAssur/server$ bzr patch OpenAssur_TM_V2.patch
<Merwin> patch: **** Only garbage was found in the patch input.
<Merwin> bzr: ERROR: Patch application failed
<vila> Ok, that's from bzrtools ?
<mgz> generally it means you gave patch something that doesn't look like a patch
<Merwin> yep
<mgz> eg, `echo junk | patch`
<vila> probably garbage in the patch file that defeat parsing, can you paste it ?
<vila> pastebin
<vila> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<Merwin> http://friendpaste.com/299Lm5ens57L60noBAjrpG
<Merwin> it looks like a valid patch to me -_-
<mgz> two things jump out, doesn't have +++ --- file lines after modified, and has non-ascii
<mgz> `bzr patch` is pretty thin though, just try patch itself?
<mgz> eg. `patch -p0 < OpenAssur_TM_V2.patch`
<Merwin> same error
<Merwin> I'll ask the guy who sent it how he did it :p
<Merwin> The good way is bzr diff right ?
<mgz> yup.
<vila> Merwin: or even better: publishing a branch
<Merwin> Yep in this case we can't :-(
<mgz> you can probably manually edit the patch to make it work
<mgz> if you add after the === lines '+++ openerp/tools/convert.py' and '--- openerp/tools/convert.py' and the same for the other file -p0 should work
<jelmer> vila: I'm going to have a look at migrating the gpg options
<vila> jelmer: cool, don't hesitate to ping me if you encounter any issue or misunderstanding
<vila> jelmer: on the other hand, I don't want to divert you from other important bits ;)
<jelmer> vila: moving commit builder over to config stack saves 9 HPSS calls :)
 * vila profits :)
<vila> jelmer: yeah !
<vila> jelmer: because it avoids a call to ensure_real or because it uses a cached config ?
<vila> or both :)
<jelmer> vila: because it uses a cached config
<jelmer> commits over HPSS still use a lot of VFS calls
<vila> double \o/
<vila> testing list_package in udd queries launchpad,
<vila> OMG, that takes far too long,
<vila> let's kill ./selftest.py
<vila> huh ?? backtrace in import_package.py ? Wtf ?
<vila> oooooh
<vila> remember that signals are caught by the main thread ? remember that import_package.py defines a signal handler ? Here you go :)
<jelmer> urgh
<vila> pfew, at least I wasn't triggering real imports during a test run :)
<vila> jelmer: indeed, but I won't tackle that one now, just filing a bug
<vila> just one more example that test after is bad ;)
<jelmer> vila: hmm, the from_unicode function isn't actually called with unicode strings?
<vila> wow, that is unexpected
<vila> grr 'Alarm clock'
<vila> selftest.timeout = 60000 \o/
<jelmer> vila: nevermind, was my own option
<vila> jelmer: where was it coming from ?
<vila> default value ?
<jelmer> vila: yep
<jelmer> vila: default_email()
<vila> jelmer: something worth fixing or ?
<vila> .. or was the error clear enough to debug ?
<jelmer> vila: it was an issue I introduced
<jelmer> vila: found it
<jelmer> vila: environment variables aren't converted to unicode
<vila> jelmer: rings a bell ;)
<vila> jelmer: mgz will summarize the issues better than me
<mgz> I've got a branch for that.
<mgz> problem is it breaks things
<mgz> it's in my current bunch though, so will propose sometime
<mgz> okay, this works, and doesn't seem toooo violently bad
<jelmer> mgz: that would be nice, my branch depends on it :)
<mgz> which envvar is causing the grief for email though?
<mgz> for paths, we at least have something to go on, and simple values it doesn't matter
<jelmer> mgz: BZR_EMAIL and EMAIL
<mgz> other strings are more problematic
<mgz> hm. email should really be ascii, but I guess auto %-escaping would be okay?
<mgz> ...I think this even assembles into a one-liner
<jelmer> mgz: it also contains the users realname
<jelmer> mgz: also, the logic in config assumes that there are no differences in encoding for environment variables
<mgz> ah yes
<mgz> ctypes.c_void_p.in_dll(ctypes.pythonapi, "Py_FileSystemDefaultEncoding").value = ctypes.cast(ctypes.c_char_p("utf-8"), ctypes.c_void_p).value
<mgz> so, just the locale and falling back to utf-8 seems reasonable then - and throwing an error if that doesn't work would be okay
<mgz> because automated things that don't set a proper locale shouldn't then be supplying bogus values and expecting stuff to work
<mgz> ^note, using a string literal in the source is very important for that statement
<mgz> intern(s) otherwise, string must be immortal.
<mgz> hm, wait, still wrong.
<vila> don't forget to leave a way for the user to override
<vila> in ASCII :)
<vila> I mean, the way to override should require only ascii
<smoser> jelmer, you mentione dto me that i could 'set "commit-message-from-changelog = False" in bzr-builddeb's config, e.g. ~/.bazaar/builddeb.conf'
<smoser> i put this in ~/.bazaar/builddeb.conf, but to no avail:
<smoser>  commit-message-from-changelog = False
<smoser> bzr commit still wants to just use the changelog entry
<jelmer> smoser: hi
<smoser> hi :)
<jelmer> smoser: you'll need a [BUILDDEB] section for it as well I think
<smoser> ah. yeah, that makes sense.
<jelmer> smoser: I can understand why it's necessary, but I'm not sure if I agree it makes sense :)
<jelmer> AFAIK there aren't any other possible sections in that file
<smoser> well, i remember that i've had such a section other places.
<smoser> jelmer, hm..
<smoser> http://paste.ubuntu.com/764943/
<smoser> seems to not work
<smoser> yeah, strace shows its not even reading that file.
<smoser> bazaar.conf and locations.conf are all that seem to be being read.
<smoser> adding that section ot bazaar.conf made no difference
<smoser> yeah... i can't seem to change that behavior any way. not even in the local repository .bzr-builddeb/default.conf
<jelmer> smoser: is your .bzr-builddeb/default.conf versioned?
<jelmer> (it will only be read if versioned)
<soren> smoser: Which version of builddeb do you use?
<smoser> well, it was not, but making it versioned had no affect
<smoser> i'm using precise
<soren> smoser: And you don't have a leftover plugin in ~.bazaar/plugins?
<soren> ~/.bazaar/plugins, I mean.
<smoser> $ ls ~/.bazaar/plugins
<smoser> ls: cannot access /home/smoser/.bazaar/plugins: No such file or directory
<smoser> soren, so you do not see this behavior?
<vila> smoser, soren : what bzr versions are you using ?
<soren> smoser: To be honest, I've not tried.
<smoser> $ dpkg-query --show bzr bzr-builddeb
<smoser> bzr	2.5.0~beta3-2ubuntu1
<smoser> bzr-builddeb	2.7.9ubuntu1
<soren> smoser: I was just looking at the code.
<smoser> soren, its pretty easy to reproduce
<soren> Oh.
<smoser> bzr branch lp:ubuntu/some-thing
<smoser> cd some-thing
<soren> This change is newer than that.
<soren> 2.7.9 is r600.
<smoser> dch -i... add bogus entry... modify some file...
<soren> The change you need landed at 625-ish.
<smoser> bzr commit
<soren> http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/625
<jelmer> soren: in older versions you can disable it with a config option, we've just flipped the default value of the option
<soren> Sorry, 2.7.9 was 620.
<soren> But still < 625.
<soren> 625: Jonathan Riddell 2011-10-07 [merge] add commit-message-from-changelog config option for those who prefer to set their own commit message
<soren> 620: Jelmer Vernooij 2011-10-01 {2.7.9} releasing version 2.7.9
<jelmer> smoser: echo "[BUILDDEB]\ncommit-message-from-changelog = False\n" > ~/.bazaar/builddeb.conf should be sufficient, surprising that doesn't work :-/
<jelmer> I can confirm that actually setting it to True changes the behaviour in lp:bzr-builddeb, and there are tests that the option behaves correctly in the version you're running
<soren> bzr grep -r tag:2.7.9 bzr grep -r tag:2.7.9 commit-message-from-changelogcommit-message-from-changelog
<soren> whoops
<soren> bzr grep -r tag:2.7.9 commit-message-from-changelog
<soren> Gives me nothing.
<jelmer> soren: sorry, I misunderstood
<jelmer> soren: You're right, riddell didn't at the option at the same time as the feature
<jelmer> for some reason I was assuming they were
<soren> smoser: Grab a fresh checkout, and you're good. bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb
<smoser> soren, but then i'll just be complaining again sometime down the road and you'll ask if i have any stuff in ~/.bazaar/plugins :)
<jelmer> vila: https://launchpadlibrarian.net/86987008/buildlog_ubuntu-precise-armhf.bzr_2.5.0~beta4-1ubuntu1_FAILEDTOBUILD.txt.gz
<jelmer> vila: do you remember seeing *that* test fail earlier?
<jelmer> bzrlib.tests.per_transport.TransportTests.test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib)
<vila> pfew
<vila> jelmer: no
 * jelmer files a bug
<vila> jelmer: but looking at the traceback, it's most probably a close socket
<vila> closed
<mgz> new one to me.
<vila> which is weird because I'm pretty sure bugs have been fixed so that ssl sockets behave correctly (raise EBADF) instead of AttributeError
<jelmer> bug 902182
<ubot5> Launchpad bug 902182 in bzr (Ubuntu) "spurious failure of test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) on armhf" [High,Triaged] https://launchpad.net/bugs/902182
<smoser> ok...
<smoser> i can verify that bzr at 2.5.0~beta4-1ubuntu1 and bzr-builddeb at 2.7.9ubuntu1 (current precise) have this issue..
<smoser> but if i use bzr-buildeb from the bzr branch for plugin, i do not. and it seems to read that file and respect the value both ways.
<smoser> so basically this seems "fix-committed" to me.
<smoser> bu if there was some test that was supposed to have caught this, it is broken.
<smoser> as i ran this all on a fresh ec2 instance.
<jelmer> smoser: the option was actually added after 2.7.9 and initially defaulted to True. It has since been changed to False
<jelmer> but in 2.7.9 there is no way of turning it off - I assumed the option and the behaviour were added at the same time but they weren't - sorry for the confusion
<jelmer> I'm going to upload 2.8.0 to sid/precise once I finish multi tarball support
<soren> smoser: Yes. Yes, I will.
<darthdweller_> hey all
<jelmer> hi darthdweller_
<darthdweller_> how do i download a specific version of a branch using bzr from launchpad
<darthdweller_> in bzr the terminal code is this bzr branch lp:project-name
<darthdweller_> but how do i download a specific version
<jelmer> darthdweller_: bzr branch -r<revno> lp:project-name
<darthdweller_> thanks
<vila> bzr branch -r<version> lp:project-name, see 'bzr help branch' and 'bzr help revisionspec'
<GRiD> hi jelmer, around?
<vila> jelmer: I'm reviewing common-bzrdir-component and...
<vila> jelmer: it's a tough one :)
<vila> jelmer: I don't think I will be able to finish today so if you have more explanations to add that will be welcome,
<vila> jelmer: I'm not sure I fully understand your intents here nor the fallouts... for example, are you dropping some features for formats older than metadir or things like that ?
<vila> jelmer: seeing  def from_string(cls, format_string) implemented as <check format_string is for me> return cls()
<vila> jelmer: makes me wonder if this whole format machinery is really worth it
<vila> jelmer: can't we just get the same effect with probers + a simple registry ?
<mgz> vila: new fun thing for the pilot to review
<mgz> where 'fun' might also be read as 'scary'
<vila> hehe, I'd better end my week before it's too late instead ;)
<jelmer> vila: sorry, wasn't paying attention to IRC
<jelmer> vila: No, there aren't any features that are being dropped
<jelmer> vila: from_string() is there because feature-flags will allow more than one line in the format file
<mgz> the @classmethod change seems good
<mgz> the rest is a bit harder to see just from the diff, looks like in some cases there are more identical copies of methods rather than better sharing
<mgz> GRiD: that's a yes, but missed your ping by the look of it, hence the 'just ask' suggestion with irc
<jelmer> mgz: which methods?
<vila> yeah, same feeling
<vila> _find_format
<jelmer> that's a utility function in BzrFormat, that code is used by the find_format methods in {BranchFormatMetaDir, RepositoryFormatMetaDir, WorkingTreeFormatMetadir, BzrDirFormat}
<vila> I don't want to sound negative (especially so late), I know this code is... dense, but I have a hard time relating your cover letter with the diff
<vila> right, but what duplication are you avoided ?
<vila> avoiding
<mgz> speaking of cover letters... the config changes look ace jelmer but I could do with a sketch for reviewing it
<jelmer> vila: that logic was present in those 4 classes
<jelmer> mgz: argh, I actually meant to cancel that, but it seems like lp-propose created an MP even though I said I didn't want it. :(
<jelmer> vila: now find_format() is smaller and using the _find_format helper method
<jelmer> network_name's default implementation is no longer duplicated in all four classes, just present in BzrFormat
<vila> _find_format != find_format !
<jelmer> vila: _find_format is a helper for find_format()
<vila> geee, this diff *is* confusing :)
<vila> jelmer: I think I start to understand :)
<vila> jelmer: is it correct to say you introduced a common base class that wasn't conceivable *before* metadirs were introduced (since repository/branch/tree were three distinct hierarchies) ?
<jelmer> vila: Yes
<vila> bah, that's what you say in your cover :-/
<jelmer> crap, I'm sorry - that was clear in my mind but I didn't describe it very well in the MP description
<jelmer> vila: and the feature flags MP goes one step further and adds that class even as a base class for BzrDirFormat, and adds some more methods to it
<vila> ha, the nightmare of splitting work across multiple MPs and trying to keep track of who understand what ;)
<vila> jelmer: review: tweak
<vila> jelmer: mostly, please, please, write or update some doc about this stuff, each time I have to dig into this area... I blame me for not writing some explanations about it
<vila> and on that, have a nice week-end guys, family is hungry :)
<jelmer> vila: fair enough
<mgz> what are you going to cook for them?  :)
<jelmer> vila: you too, have a good weekend :)
<vila> mgz: I don't know yet :)
<mgz> jelmer: I think bug 873412 needs confirming and a prio, as it's a known symptom and people seem to be able to hit it
<ubot5> Launchpad bug 873412 in Bazaar Subversion Plugin "sqlite3.OperationalError: unable to open database file" [Undecided,Incomplete] https://launchpad.net/bugs/873412
<fullermd> Maybe they're eating him.  That's why he has to stop typing.
<jelmer> mgz: it's not new though :-/
<mgz> you don't have to mark it as 'New' :)
<jelmer> heh
<kirkland> struggling here importing something from cvs into bzr
<kirkland> cvs repo info at http://sourceforge.net/scm/?type=cvs&group_id=162326
<jelmer> hi Dustin :)
<kirkland> jelmer: howdy :-)
<jelmer> kirkland: are you trying to import it through a Launchpad import, or some other way?
<kirkland> jelmer: i just filed a new bug, but it looks like maybe I'm hitting https://bugs.launchpad.net/bzr-cvsps-import/+bug/788914
<ubot5> Ubuntu bug 788914 in CVS to Bazaar importer "unexpected keyword argument 'pb'" [Critical,Fix committed]
<kirkland> jelmer: LP import failed, so I'm trying by hand now
<kirkland> jelmer: I filed Bug 902315
<ubot5> Error: Launchpad bug 902315 could not be found
<kirkland> hmm, not sure why that's private
 * kirkland undoes that
<kirkland> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/902315
<jelmer> that very much looks like a dupe of 788914, indeed
<kirkland> jelmer: okay, I see "fix-committed" ... where/how do I get an update for that?
<kirkland> jelmer: should i just branch the plugin directly?
<kirkland> jelmer: i was running from 11.10 packages
<jelmer> kirkland: yeah, it's fixed in lp:bzr-cvspsimport but not yet in the package
<kirkland> jelmer: okay, so mkdir -p ~/.bazaar/plugins ?
<kirkland> jelmer: and then bzr branch lp:bzr-cvspsimport there?
<jelmer> kirkland: yep
<kirkland> jelmer: k, let me try
<kirkland> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/bzr-cvspsimport/".
<kirkland> missing -
<jelmer> I'm not sure if that'll work with a local checkout though, it might need a copy of the repository
<kirkland> jelmer: okay, so now i have a bzr directory
<kirkland> jelmer: it appears the import succeeded
<kirkland> jelmer: but it doesn't look like a branch of the source code yet
<kirkland> jelmer: what does that take?
<jelmer> kirkland: it might not create a checkout
<jelmer> kirkland: does "bzr log" work?
<kirkland> jelmer: nope
<kirkland> jelmer: here's what I did ...
<kirkland> cd $(mktemp -d)
<kirkland> cvs -z3 -d:pserver:anonymous@talpa.cvs.sourceforge.net:/cvsroot/talpa co -P .
<kirkland> jelmer: I think that gets me the CVSROOT
<kirkland> jelmer: then I did a bzr cvsps-import path/to/cvs/root talpa /tmp/talpa.bzr
<kirkland> jelmer: then I have stuff in /tmp/talpa.bzr
<kirkland> jelmer: but it's not a bzr branch
<jelmer> kirkland: is there anything in /tmp/talpa.bzr/.bzr ?
<kirkland> jelmer: $ find /tmp/talpa.bzr/ -name ".bzr"
<kirkland> /tmp/talpa.bzr/bzr/talpa/.bzr
<jelmer> kirkland: can you try running "bzr co" in /tmp/talpa.bzr/bzr/talpa ?
<kirkland> jelmer: kirkland@x220:/tmp/talpa.bzr/bzr/talpa$ bzr stat
<kirkland> bzr: ERROR: No WorkingTree exists for "file:///tmp/talpa.bzr/bzr/talpa/.bzr/checkout/".
<kirkland> jelmer: $ bzr co
<kirkland> bzr: ERROR: Not a branch: "/tmp/talpa.bzr/bzr/talpa/.bzr/branch/": location is a repository.
<jelmer> hmm, odd
<jelmer> it's been a while since I've used bzr-cvsps-import, let me see if I can import it here
<jelmer> I immediately get an error from "bzr cvsps-import"
<jelmer> bzr: ERROR: Could not find the cvs versioned file for CVSROOT/checkoutlist. Looking for it at /tmp/tmp.2MUY7W8mmz/CVSROOT/talpa/CVSROOT/checkoutlist,v and /tmp/tmp.2MUY7W8mmz/CVSROOT/talpa/CVSROOT/Attic/checkoutlist,v.
<kirkland> jelmer: erg
<kirkland> jelmer: dang, this is frustrating;  okay, thanks for your help  :-/
<jelmer> kirkland: where's the import on launchpad? I'm curious about the error
<kirkland> jelmer: http://launchpadlibrarian.net/87103042/kirkland-ezncrypt-trunk.log
<kirkland> jelmer: possibly the error is just waiting on accepting the ssh host key?
<jelmer> kirkland: that seems to be lacking a :pserver: prefix
<kirkland> jelmer: oh?  should I try re-running?
<jelmer> kirkland: yeah, but fix the CVS root first :)
<kirkland> jelmer: ?
<kirkland> jelmer: this isn't my code or project
<jelmer> kirkland: the CVS root specified in the code import I mean
 * jelmer tries
<kirkland> jelmer: sorry, man, this is over my head, I don't really know what I'd be putting in there
<jelmer> kirkland: :pserver:anonymous@talpa.cvs.sourceforge.net:/cvsroot/talpa
<jelmer> for the CVS root and talpa for the module
<kirkland> jelmer: locally, or in LP?
<jelmer> kirkland: in LP
<kirkland> jelmer: ooooooh, sorry :-)
<kirkland> jelmer: yeah, I did that
<jelmer> kirkland: let me know if it works
<jelmer> for some reason I can see the log file for the import but not the import itself (is it private?)
<kirkland> jelmer: yeah, sorry, i imported it a private project
<kirkland> jelmer: should i just register talpa as a project?
<kirkland> jelmer: restarted the import here: https://code.launchpad.net/~kirkland/talpa/trunk
<jelmer> kirkland: seems to've disappeared
<kirkland> jelmer: heh, i moved it :-)  sorry
<kirkland> jelmer: https://code.launchpad.net/~ecryptfs/talpa/ecryptfs
<kirkland> jelmer: this is actually fixes to talpa to get it to work with ecryptfs
<kirkland> jelmer: so i've set the owner to the ecryptfs team, project talpa, branch name ecryptfs
<kirkland> jelmer: does that seem reasonable to you?
<jelmer> kirkland: yep
<kirkland> jelmer: cool, and registering the project in LP...was that the right thing to do?
<jelmer> kirkland: yep
<kirkland> jelmer: great, thanks for your help
<kirkland> jelmer: i think this is working now
<jelmer> it seems to be doing something :)
<kirkland> jelmer: the private import seemed to have completed
<kirkland> jelmer: it was in a review stage or something when i killed it
<glyph> is the maintainer of the mac installer here?
#bzr 2011-12-10
<dOxxx> good evening...
<dOxxx> I'm having a weird problem with WorkingTree.open(...)
<dOxxx> It's giving me a NotBranchError for a path that `bzr info` works just fine on.
<dOxxx> I'm using bzr 2.5b4.
<fullermd> Does info say there's a working tree there?
<dOxxx> hmm... it says "Repository tree (format: 2a)"
<dOxxx> I can see files there
<fullermd> Probably then.
<fullermd> Mmm.  Are you pointing at the _root_ of the WT?  Maybe you want open_containing() instead?
<dOxxx> I was getting the same error woth open_containing
<fullermd> (or is that even what it's called?  These are really vague memories, that never had any business in my brain in the first place)
<fullermd> Well, OK, I'm about 5 guesses beyond where I have any business talking about bzrlib now   :p
<dOxxx> heh ok thanks
<Noldorin> hi jelmer
<Noldorin> hi wgz
<Noldorin> jelmer, you around either?
<glyph> https://bugs.launchpad.net/bzr-mac-installers/+bug/902437
<ubot5> Ubuntu bug 902437 in Bazaar Mac Installers "installer incorrectly installs script pointing at /usr/bin/python instead of /usr/bin/python2.6" [Undecided,New]
<glyph> Oh, it's a wiki.
<glyph> Is there any known configuration where running 'bzr branches' is reasonably fast?
<jelmer> glyph: locally it should be reasonably quick
<jelmer> glyph: you're talking about the branches command from bzrtools I guess?
<glyph> jelmer: Yeah.
<glyph> Oh, I get it, it's slow because there are svn branches in here, and that's driving it crazy
<jelmer> glyph: yeah
<glyph> svn checkouts, I should say, like, with .svn directories not .bzr directories :)
<jelmer> glyph: "bzr branches" from bzrtools scans the directory structure and tries to open every path in existence
<jelmer> glyph: bzr 2.5 has a new "bzr branches" command, which uses an API call and should be much faster for svn stuff
<glyph> however, right now, 'bzr branches' against a server directory which I know contains only bzr branches, has taken about 15 minutes, and has downloaded 1.5 megs of data at 2kb per second
<glyph> server's running bzr 3.3.3
<glyph> erm
<glyph> 2.3.3.
<glyph> https://bugs.launchpad.net/bzrtools/+bug/902566
<ubot5> Ubuntu bug 902566 in BzrTools "bzr branches is comically slow on a remote repository" [Undecided,New]
<glyph> Which is the version of bzr-svn which actually works?
<glyph> Is 1.1.0 okay or do I need 1.1.1?
<wgz> apparent tip.
<wgz> +ly
<dOxxx> for bzr 2.5 you need bzr-svn tip
<Noldorin> hey jelmer , poolie
<Noldorin> hi wgz
<glyph> wgz: I don't mean to work with bzr 2.5
<glyph> I mean to work, like, at all :)
<glyph> jelmer: I think maybe I want to kill those revision properties that keep sending us to The Hell of Nobody Can Merge Anything
<glyph> but I want to make really sure I understand the implications first
<Noldorin> wgz, i've got sshd running nicely on my windows server now :-)
<Noldorin> wondering what specific things i can do to make it worth nicely with bzr
<Noldorin> grr
<Noldorin> devs are actually having the weekend off :-P
<Noldorin> come baaack
<glyph> Noldorin: don't worry, some of us are slaving away
<Noldorin> glyph, oh good ;-)
<glyph> Noldorin: not on bzr, but bzr is getting in our way ;)
<Noldorin> glyph, you're a core member?
<Noldorin> oh okay
<Noldorin> hmm
<Noldorin> what's the prob?
<glyph> Noldorin: https://bugs.launchpad.net/bzr-svn/+bug/485601
<ubot5> Ubuntu bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,Fix released]
<glyph> Noldorin: it's fixed, but not really
<glyph> like, bzr-svn won't introduce this issue any more, but you have to upgrade everybody and then destroy all your old branches and repositories
<Noldorin> glyph, ah right. don't use bzr-svn fortunately
<jelmer> hi glyph
<wgz> glyph: so we have bug 806348 for the bazaar side of handling bust repos, I agree it's confusing there's a closed bzr-svn bug for one bustage cause
<ubot5> Launchpad bug 806348 in Launchpad itself "BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps" [Critical,Triaged] https://launchpad.net/bugs/806348
<wgz> Noldorin: which one did you get working?
<Noldorin> jelmer, wgz there you guys are heh
<Noldorin> wgz, OpenSSH
<Noldorin> which is reassuring :-)
<wgz> ...what version?
<Noldorin> on cygwin, but still...
<Noldorin> latest
<Noldorin> 1.7.2 i think?
<wgz> ah, that's okay then.
<Noldorin> it uses NTLM auth
<Noldorin> and runs as a windows ervice
<Noldorin> which is cool :-)
<wgz> was concerned that the native port seemed very dead
<Noldorin> wgz, basically http://t.co/V8dN4h12 got me most of the way there
<wgz> Noldorin: so, have you tested bzr+ssh with it yet?
<Noldorin> wgz, yeah. it works :-)
<Noldorin> wgz, are there any "recommended settings"/configuration though?
<wgz> Noldorin: use an ssh agent, and maybe the append revisions only config setting... can't think of anything else in particular
<Noldorin> wgz, what does revisions only?
<Noldorin> and where do i set this config setting? ;-)
<wgz> Noldorin: it's an option on init, or in .bzr/branch/branch.conf
<Noldorin> wgz, ah ok
<Noldorin> wgz, btw, is there any way i can configure the root path that bzr+ssh uses?
<Noldorin> for branches
<wgz> Noldorin: ...not sure of the easiest way, there are probably several options
<Noldorin> wgz, okay...
<Noldorin> what are they then ? :-)
<Noldorin> maybe i can choose then
<wgz> never tried it, but I'm guessing you could set the sshd to put people in a different cwd, or maybe include a cd in bzr_remote_path, or set up a lp: style alias as on your client
<Noldorin> wgz, oh, so all paths in bzr+ssh urls are relative to the cwd?
<lifeless> no, they are relative to the server root
<lifeless> which defaults to / on the server
<wgz> okay, scratch ideas one and two then, maybe lifeless has more.
<lifeless> whats the goal?
<lifeless> oh, I see
<Noldorin> lifeless, to change where bzr+ssh urls refer to on the fs...
<lifeless> so, bzr <thing> bzr+ssh://host/... will invoke bzr serve --allow-writes / --stdout or something like that
<Noldorin> ah
<lifeless> you can mangle that by using a custom 'bzr' on the server, using a custom ssh server (like thomi's student-bzr-service or LP's hosting service do)
<lifeless> or
<lifeless> you can do it client side
<lifeless> by using bzr-bookmarks
<lifeless> or similar
<lifeless> lastly, you can use bzr+ssh://host/~/ to mean 'relative to my home dir'
<Noldorin> lifeless, interestingly, on cygwin all paths are relative to the home dir anyway
<Noldorin> custom ssh server just isn't an option
#bzr 2011-12-11
<Noldorin> lifeless, that's not expected behaviour surely?
<Noldorin> hmm
<Noldorin> wgz, any ideas about that either?
<lifeless> Noldorin: cygdrive should tell you a little about what is up
<Noldorin> lifeless, hmm?
<Noldorin> lifeless, i don't know what you mean by cygdrive in this context.
<lifeless> Noldorin: thats cygwins mapping tool
<lifeless> Noldorin: or you can just run mount I guess :P
<Noldorin> lifeless, still, how about thev
<Noldorin> url?
<lifeless> Noldorin: the mount table controls what / is in cygwin
<Noldorin> hi lifeless
<lifeless> Noldorin: hi
<Noldorin> lifeless, sorry, was late yesterday and had to go
<Noldorin> what were you saying lastly?
<lifeless> I had nothing more to add
<lifeless> I'd described how you can address the url length
<lifeless> and you asked why / in cygwin was your home dir, so I pointed you at the cygwin mount table
<Noldorin> lifeless, oh, i didn't see that. you probably replied after i left
<Noldorin> mind briefly repeating both of those points please? :-P
<Noldorin> copy and paste will do
<lifeless> pasted the transcript (with very minor skipping) to you
<Noldorin> ok
<Noldorin> cheers
<Noldorin> hey lifeless. do you have much experience on windows?
#bzr 2012-12-03
<sil2100> Hi!
<mgz> hey
<sil2100> Could anyone help me with a quick question bzr related? Since I remember a configuration option in bzr that disables ssh key authentication - I need it now but can't find it anywhere
<sil2100> I remember using it in the past
<mgz> I'm guessing you mean you want read-only http access to launchpad rather than bzr+ssh?
<sil2100> Yes
<mgz> remove launchpad_username from ~/.bazaar/bazaar.conf
<sil2100> I have no launchpad_username there ;) Checked that already
<sil2100> Ok, I did it differently
<sil2100> I simply switched to using http://* directly
<sil2100> But thanks!
<mgz> really? what does `bzr config launchpad_username` say?
<mgz> you can also remove the [Launchpad] section of authentication.conf to be sure, but that should be ignored if the name isn't in the main config
<zyga> hey, I'm trying to use bzr join, I have two 2a branches, let's say A and B, I branch B to A/B (so it's inside the A branch), running bzr join B from root of A fails with:
<zyga> bzr: ERROR: Cannot join B.  Trees have the same root
<zyga> is this expected?
<mgz> I take it A is a fork of B? and wow, you really are trying to do things in the most convoluted ways possible.
<zyga> no
<zyga> A and B are independent
<zyga> mgz: what is convulted about join?
<mgz> is that actually true? experience says at least one of them is probably going to be something like a fastimport from git.
<zyga> it is true (the are independent), and the other part you said is also true (B is an export from git, but it was never derived from A in any way)
<zyga> a is lp:checkbox
<zyga> b is lp:~zkrynicki/+junk/plainbox
<zyga> no common ancestry in any way
<zyga> I gave up trying to export the merged tree from git
<zyga> as I was unable to fix the bugs in bzr-fastimport and bzr-git
<zyga> so I thought that good old bzr join should work
<zyga> mgz: is this a bug in bzr core or is the bzr join --help description just confusing and I'm doing something wrong on the basic level
<mgz> zyga: as reported, join works fine. what's borked is your branches.
<zyga> mgz: how are they borked?
<mgz> (probably, I can't get the +junk one)
<zyga> oh
<zyga> sorry
<zyga> typo
<zyga> mgz: please try again
<jelmer> zyga: if these are fairly old bzr branches they might both have the old constant tree root file id
<zyga> jelmer: I don't undestand what that is
<zyga> jelmer: checkbox is failry old if you look at the history
<mgz> jelmer: one is a fastimport thing, the other is an oldish branch
<jelmer> mgz: ah
<jelmer> mgz: I guess the fastimport thing should be using rich roots then?
<zyga> mgz: both branches use 2a format
<zyga> mgz: what is the "constant tree root file id"?
<mgz> ...I pretty much think helping you do this is a waste of time, because you're just making your branches more and more complicated...
<zyga> mgz: could you explain what I'm doing wrong
<mgz> what's the benefit of embedding a the history of the old project in a subdirectory of your new fork?
<zyga> mgz: it's a requirement of the team leader, we wish to contiune working on the fork in the old repository
<mgz> sure, but why that way around?
<mgz> it would be better to just merge your changes into the existing code and not screw around with the structure surely...
<zyga> mgz: how would I merge my changes into lp:checkbox?
<zyga> mgz: and how is any of that explaining why bzr join is not working, is any of the repositories damaged?
<jelmer> mgz: is this a duplicate root file id issue? I think I missed an earlier part of the conversation
<mgz> for the record:
<mgz> (Pdb) e
<mgz> BadSubsumeSource(Can't subsume <WorkingTree6 of /home/ubuntu/tmp/checkbox> into <WorkingTree6 of /home/ubuntu/tmp>. Trees have the same root)
<mgz> (Pdb) e.tree.get_root_id()
<mgz> 'TREE_ROOT'
<mgz> (Pdb) e.other_tree.get_root_id()
<mgz> 'TREE_ROOT'
<mgz> jelmer: zyga posted to an internal canonical list for reasons passing understanding, so you're missing some context
<jelmer> mgz: ah, I'll leave it to you then
<zyga> mgz: what I posted to the caonical list was not related much, maybe apart from just trying various things to make this work, the join issue is separate IMHO
<jelmer> mgz: (you do know about the merge-into plugin?)
<mgz> basically he created a new project on github as a fork of an existing bzr project, added the existing project as a submodule, and is now struggling to reintegrate the codebases
<zyga> mgz: you are incorrect
<zyga> mgz: plainbox is not a for of checkbox
<mgz> zyga: was going to post what I understood from looking briefly and get you to correct anything I didn't understand, maybe I should do that
<zyga> mgz: ok
<zyga> mgz: we can move the discussion to a proper place if you'd like
<zyga> mgz: basically I want to "join" two projects, one of which was in git another in bzr, into bzr
<mgz> so, we could make the join work, but I'm unconvinced that's what you really want
<zyga> mgz: anything that works is fine, fixing bugs in bzr is good if I can do that as a side effect
<zyga> mgz: fixing bugs in bzr-fastimport would be good as well but I've yet unable to trace that issue to something I can report
<mgz> can you explain what plainbox is to me briefly? it uses the checkbox code, and is described in the readme as a "plain replacement", but you're saying it's not a fork?
<zyga> mgz: ditto to bzr-git
<zyga> mgz: it's a rewrite that our team is doing
<mgz> bzr-git is simple (I think, you missed pasting the error), you used submodules in your git branch, which aren't supported
<zyga> mgz: since checkbox became unmaintainable and the team lead made a decision to rewrite it
<mgz> so it is a fork?
<zyga> mgz: I see, I didn't know they were unsupported
<mgz> or... a redo from scratch?
<zyga> mgz: no, it's a rewrite, not a fork
<zyga> yes
<mgz> then why integrate the histories?
<zyga> it uses some of checkbox scripts in practice (hence the submodule)
<zyga> but the core is independent
<zyga> mgz: so is lp:checkbox broken in any way?
<zyga> mgz: or is the plainbox bzr export broken?
<mgz> depends what you're trying to do.
<zyga> mgz: well, use bzr the way it's advertised so to speak, getting bzr join to work would be a good start
<zyga> mgz: ?
<mgz> writing an email.
<zyga> thanks!
<zyga> everyone, for reference, unless something major happens, the most likely bzr branch for plainbox is going to be copied from lp:~zkrynicki/+junk/plainbox
<zyga> we'll just need do decide if we want it in lp:plainbox or lp:~something/checkbox/plainbox
<zyga> meh
<zyga> wrong window :)
<mgz> zyga: +metoo bug 1031773 and I'll get round to doing something about that
<ubot5> Launchpad bug 1031773 in Bazaar "Failed to run bzr" [High,Confirmed] https://launchpad.net/bugs/1031773
<mgz> your variation on the underlying problem was at least less obnoixious than the one hidetaka got...
<zyga> looking
<mgz> didn't want to just back the code out, but that's probably the sanest option...
<zyga> mgz: osutils.rename calls systems 'mv'?
<zyga> mgz: or is some part of python borked to return non-unicode, localized message?
<mgz> Python 2 returns non-unicode, localised messages, when setlocale is called
<zyga> ahh
<mgz> it calls rename(2) underneath
<Nav_> Hello. I need some help at installing centralized workflow thing on a CentOS server
<Nav_> can someone help?
#bzr 2012-12-05
<jelmer> hmm, no mgz today?
<tsdh> Hi.  I've pushed some commits, and it turns out the changes were broken.  How do I undo them, e.g., creating a reverse patch undoing my changes in revnos 312, 313, and 315?
<tsdh> Ok, think I got it.
#bzr 2012-12-06
<Logan_> james_w: Are you around?
<james_w> Logan_, yeah
<Logan_> james_w: could you please requeue_package.py --full hivex ?
<Logan_> There's currently an import failure for it that should be resolved with that command.
<james_w> Logan_, done
<Logan_> Thanks. :)
<james_w> with --priority for good measure :-)
<Logan_> Awesome. :P
<mortrca> Whenever a member of my team commits changes, the file <RepositoryLocation>/.bzr/repository/pack-names is changed so that it is no longer owned by the group, but by the user that has committed the changes. This makes it impossible for anyone to commit changes until the ownership is changed back. How can I fix this?
<fullermd> The file gets replaced, I'm pretty sure, so it shouldn't matter.  They just need to be able to write the dir.
<bob2> you need to fix their umasks
<bob2> and then make .bzr g+s, recursively
<mortrca> fullermd: Even with permission to write to the directory the file becomes unavailable.
<fullermd> umask shouldn't matter; bzr will inherit the dir mode.
<fullermd> The g+s is probably it.  I keep forgetting about the problems of inferior FS semantics  ;p
<mortrca> I will give that a try, thank you.
<bob2> umask is need to make it group writable
<fullermd> No, bzr will do that itself if the dir is group writable.
<fullermd> ('m pretty sure it'll even make it world writable if the dir is...)
<mgrandi> so apparently you can make bzr run out of memory by having a big commit >.>
<mgrandi> but strangely you can still commit it
<venefyxatu> mgrandi: there are several ways to make it run out of memory :-)   https://bugs.launchpad.net/bzr/+bug/367545 and https://bugs.launchpad.net/bzr-svn/+bug/191731
<ubot5> Launchpad bug 367545 in bzr (Ubuntu) "Huge memory usage for bzr branch/checkout" [High,Triaged]
<ubot5> Launchpad bug 191731 in Bazaar Subversion Plugin "Memory problems prevent branch of very large svn repositories" [High,Triaged]
<venefyxatu> ooh, fun
 * venefyxatu pokes ubot5
<mgrandi> probably involves the branch one
<mgrandi> but also happens during merge / pull
<askhl> Hi.  I'm trying to share a repostiory on one computer with multiple people using ssh.  But after a push by USER, the file .bzr/repositories/pack-names will be owned by USER.USER, which prevents other users from pushing until I fix the group permissions.  How should I solve this?  The examples I find on the net do not seem to have to deal with this problem.
<askhl> Let me rephrase my previous question: "How do I properly grant commit rights to someone?"
<pef_> hi! I have installed bzr on a cluster and I'm getting
<pef_> Value "/etc/ssl/certs/ca-certificates.crt" is not valid for "ssl.ca_certs"
<pef_> No valid trusted SSL CA certificates file set. See 'bzr help ssl.ca_certs' for more information on setting trusted CAs.
<pef_> See `bzr help ssl.ca_certs` for how to specify trusted CAcertificates.
<pef_> Pass -Ossl.cert_reqs=none to disable certificate verification entirely.
<pef_> however, I don't want to have to pass that argument each time when I call bazaar
<pef_> how do I turn it off in my ~/.bazaar?
<pef_> I've tried
<pef_> ssl.cert_reqs=none
<pef_> ssl.ca_certs=none
<pef_> but it doesn't change anything
<jelmer> pef_: that should do it
<jelmer> pef_: what section did you set it in?
<pef_> I didn't know I had to put it in a section
<pef_> those two lines are the only contents of the file
<pef_> what should [go above]?
<jelmer> e.g. [DEFAULT]
<jelmer> though I think if you don't have a section, it means it's in that one too
<pef_> nope, adding [DEFAULT] hasn't made a difference
<pef_> any other ideas?
* You're now known as ubuntulog
#bzr 2012-12-07
<Meatball_py> hi, how can I change the parent location of a local bzr repo?
<mgrandi> boop
<jonkirkman> blip
<mgrandi> so does nayone know of a bug report with bzr running out of memory when doing a pull / merge?
<jelmer> hi mgrandi
<mgrandi> hi
<jelmer> mgrandi: there are a few
<jelmer> bug 109114
<ubot5> Launchpad bug 109114 in Bazaar "[master] bzr holds whole files in memory; raises MemoryError on large files" [High,In progress] https://launchpad.net/bugs/109114
<jelmer> bug 183156
<ubot5> Launchpad bug 183156 in Bazaar "bzr branch uses too much RAM when not using a shared repository" [High,Confirmed] https://launchpad.net/bugs/183156
<mgrandi> yeah, thats bad
<jelmer> bug 367545
<ubot5> Launchpad bug 367545 in bzr (Ubuntu) "Huge memory usage for bzr branch/checkout" [High,Triaged] https://launchpad.net/bugs/367545
<jelmer> bug 650463
<ubot5> Launchpad bug 650463 in Bazaar "out of memory on pull from Subversion" [Medium,Confirmed] https://launchpad.net/bugs/650463
<mgrandi> i almost borked everything becuase i commited a large file
<jelmer> https://bugs.launchpad.net/bzr/+bugs?field.tag=memory
<mgrandi> it committed fine, but pull merge and everything else failed
<mgrandi> and since it was in the pack file even if i uncommitted, it still failed D:
<mgrandi> why does commit work fine but the others don't?
<mgrandi> well thanks, ill look at them!
<bschaefer> Hello, I've got an interesting problem with a bzr branch. I merged a branch, then reverted that branch. Then pushed a new branch with changes, but the branch I reverted thinks it is apart of that branch...
<bob2> do you understand what revert does
<bschaefer> I ment reverted the changes done from the merge
<bschaefer> and I would hope so
<bschaefer> anything that isn't commited to that branch
<bschaefer> well now theres a conflict merging a branch, because it thinks it was merged. Though none of the files were merged...just the revisions. soo Im not sure why the files were reverted but not the revision info
<spiv> bschaefer: how did you do the revert?
<bschaefer> spiv, first I did: bzr merge <branch name>
<spiv> bschaefer: did you perhaps do something like "bzr revert file1 file2", or even "bzr revert .", rather than just plain "bzr revert"?
<bschaefer> spiv, then just bzr revert
<bschaefer> spiv, hmm I don't think so
<bschaefer> spiv, usually I just do a normal bzr revert
<bschaefer> normally*
<spiv> "bzr revert" would have reverted the pending merges (i.e. the revision info) as well as the files, so if that's what you did then it's a mystery how you got into this state.
<bschaefer> yes it is...as the files are not with the merge, but the info is
<bschaefer> the only way I saw is a bzr merge --included-merges
<spiv> Anyway, if you haven't done anything interesting on that branch since that unwanted merge commit, you could bzr uncommit back to just before it.
<bschaefer> hmm when I did a bzr uncommit, then commit those changes
<spiv> bzr status will report "pending merges" as well as uncommitted file edits and adds.
<bschaefer> it has all the info under pending merges, which I wasn't 100% if it would still keep that info with it
<spiv> (To be clear, I should say: uncommit, and then revert, so that 'bzr status' is clean.  Or alternatively 'bzr pull -r THAT_REV --overwrite')
<bschaefer> but then I still have to merge that to the master branch, which I don't have those rights :)
<bschaefer> and uncommiting then revert worked fine,but I wasn't sure how to get that merged over the master branch
<spiv> Ah, well, if that master branch already has unwanted changes in it, and you don't have rights to change that branch, it's out of your hands!
<bschaefer> shoot...
<bschaefer> well Ill have to just poke someone with the rights to get that uncommited...
<spiv> You'd have to ask whoever has permission to change the master branch to either also uncommit that revision, which they might not want to do (because it can cause grief if other branches have already branched/pulled that revision), or perhaps commit something on top to get back to an acceptable state.
<spiv> Exactly what you and they want to do from here depends on what you want to have happen :)
<bschaefer> yeeah, it is just very odd, this is the second time it has happened to me, the it was a while ago
<bschaefer> is there any way to revert umm revisions like 723.3.3: http://paste.ubuntu.com/1417835/
<bschaefer> but then again im not sure what I would be commiting, as no files are in the branch that are unwanted, just the revision info
<bschaefer> spiv, thanks! Ill go poke someone with right to try and get that revert before anything else gets put on top :)
#bzr 2012-12-09
<Wiz_KeeD> hello guys, can someone please tell me if bzr qlog should be readily available when installing bzr or is it a third-party that i need to isntall? (Ubuntu 32bit 12.04 LTS)
<Peng> Wiz_KeeD: Ought to be the, uh, qbzr package. I think.
<Wiz_KeeD> i tried installing it with apt-get and i got The following packages have unmet dependencies:
<Wiz_KeeD>  qbzr : Depends: python-qt4 but it is not going to be installed
<Wiz_KeeD> E: Unable to correct problems, you have held broken packages.
<Peng> Sorry, apt is not my thing.
<Wiz_KeeD> heh,thanks anyway man
<ychaouche> Wiz_KeeD: there should be an apt command to fix your packages
<Wiz_KeeD> tried several, none worked ychaouche
<ychaouche> Hi #bzr. I want to start with bazaar, I just read the 5min tutorial and the getting started guide and I have a few questions : So suppose I have my code in code. I'd cd to code, then the getting started guide tells me to bzr init. bzr help init tells me that This creates and empty branche. How come I can create a branch without creating a repository first ?
<ychaouche> Or is the repository created along with the branch and everything is put inside the .bzr directory ?
<ychaouche> I have the feeling that source code (files) are mixed with the "revisions", i.e bzr files. They're all put inside the source code. Am I right ?
<ychaouche> I'm coming from subversion where source code is checked out from a repository, where svn stores branches/revisions etc.
<ychaouche> Please tell me if this is correct : http://pastie.org/pastes/5501937/text
<fullermd> You can do init without init-repo just fine.  It'll just colocate and use an internal repo.
<fullermd> Which is a related, but not identical, construct to svn's repo.
<ychaouche> fullermd: ok suppose I do init-repo to create a repo, then init to create a branch. Is this workflow correct ?
<fullermd> Assuming there's a "cd" in the middle, so the branch is under the repo.
<fullermd> But really, if you're just starting out working with bzr, I'd ignore it.
<fullermd> Using repos properly makes things a lot nicer, but it's not a semantic difference, and thinking about it at this point is likely to overcomplicate things.
<fullermd> You're thinking svn; in svn, the repo is an important (or _the_ important) boundary/unit.  In bzr, it's completely irrelevant; the _branch_ is the important unit.
<ychaouche> ah ok
<ychaouche> thanks for this _important_ information
<ychaouche> no pun intended
<ychaouche> So one doesn't really need a repository right ?
<fullermd> Not an explicitly-created one, no.  If you don't make one (with init-repo), each branch (made with init) will create and use an internal one.
<ychaouche> fullermd: So I'll just create a normal directory with mkdir foo instead of bzr init-repo foo and put my branches there
<fullermd> All that a shared repo does is save you disk space/IO/etc by sharing storage between branches.  Everything works the same either way.
<ychaouche> ok, I'll do that in a second stage
<fullermd> And you can use reconfigure to switch things around to using a shared repo later, so I'd recommend ignoring it for the moment, just to cut down on the number of things you're thinking about.
<ychaouche> ah cool
<ychaouche> So, suppose I want to work on a dev branch, and from times to times, when features are ready, create a production branche. How do I create a production branche ?
<fullermd> `bzr branch dev production`
<ychaouche> fine
<ychaouche> let me try this
<fullermd> You may find some of the stuff in and around <http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief> useful.  Or maybe not.
<fullermd> Won't mean much until you use the commands for a little while, probably; doesn't help with that.  But it does talk about the abstract pieces underneath that you're manipulating.
<ychaouche> ok let's leave that for later.
<ychaouche> ok I created a branche. How cool is that.
<ychaouche> fullermd: so if I just copy everything inside a branch and give it to someone, it contains everything he needs to branch/merge and do stuff, right ?
<fullermd> Normally, you'd do that by having the branch somewhere they can read, and let them use it as the source for a `bzr branch` invocation of their own.
<ychaouche> do I need to setup a webserver for that ?
<ychaouche> or a bazar server ?
<fullermd> Most common is probably ssh access.  Though that's more of a bother when people don't already have shared access to a system somewhere.
<fullermd> You can run over dumb http; it'll be slower than over a smart transport, though you probably won't notice the difference with small branches.
<fullermd> And there's the bzr:// server, which works OK for ad-hoc or global readability.  It doesn't have any AAA support or hooks, so it won't suit a lot of cases.
<ychaouche> bzr explorer : bzr: ERROR: No module named explorer.lib.commands http://pastie.org/5502113
<ychaouche> I'm using bzr 2.4.1
<ychaouche> Is it problematic if the parent branch is not where bzr thinks it is ? http://pastie.org/5502524
<jelmer> ychaouche: no, that shouldn't matter
<jelmer> ychaouche: it just means that it will do the wrong thing if you don't specify a branch explicitly to 'bzr pull'
<ychaouche> jelmer: fine
<ychaouche> Same for merging, right ?
<ychaouche> should I merge back dev to prod.
#bzr 2013-12-02
<philsf> hi, I have a local bzr branch I created in 2008, and I pushed to launchpad before I found out the format had changed. I bzr upgrad'ed the local branch, but pushing does not upgrade the remote branch, and now I can't build using LP recipes because of format mismatch. How can I upgrade the LP branch?
<Peng> "bzr upgrade" can operate on a remote URL. I'm not sure that's still the best way to handle it, though.
<philsf> Peng, I removed the remote bazaar branch and pushed again. thanks
<Peng> That too...
#bzr 2013-12-03
<dmemdfd> Hi all. I've got a project located at an external url and a machine which updates its local content (using bzr update) from that url. Recently url of the project changed and now I need to change location of the repository (sorry...I'm a newbie to bazaar).  I made "bzr branch <new location>" and now bazaar tells me it branched all revisions from the new url but as far as I can see urls configured in branch.conf still point to the
<dmemdfd> old url. Is this correct or I used the wrong command ?  Thank you very much
<lfaraone> Can I dpush to a git repository on the local filesystem?
<lfaraone> dpush git+file:// isn't supported, it looks like
<fullermd> I would presume you'd just give it the path.
#bzr 2013-12-04
<quicksilver> congrats to all the canonical chaps on the LSE 1000 list ;)
<jml> quicksilver: huh what?
<jml> oh I see.
<quicksilver> jml: http://www.telegraph.co.uk/finance/1000-companies-inspire-britain/
<quicksilver> at least I assumed "CANONICAL GROUP LTD information technology, South East London" was canonical.
<jml> presumably
<Wiz_KeeD> hey guys
<Wiz_KeeD> anyone speaking german well here?
<Cas-> Hi, quite new to bzr and I am getting a diverged error when trying to push to remote branch but get same error after merging in the upstream branch, I'm a bit confused now
<Wiz_KeeD> Can anyone tell me how I can obtain the branch's root dir?
<Cas-> oh I realised I modified my commit in my branch so needed to use push --overwrite
<Peng> Wiz_KeeD: "bzr root"?
<Wiz_KeeD> Peng, you are a genius!
 * Wiz_KeeD hugs
<Wiz_KeeD> thanks :D
<Peng> :D
#bzr 2013-12-05
<charlie> I want to start developing for ubuntu, but was wondering if its okay/suggested to develop in 14.04 daily build installation?
#bzr 2013-12-06
<glen> is this project dead? https://launchpad.net/bzr-fastimport
#bzr 2013-12-07
 * fullermd does his bimonthly "scream at bug 315399" dance.
<ubot5> bug 315399 in Bazaar "diff gives huge areas of unnecessary changes" [Medium,Confirmed] https://launchpad.net/bugs/315399
<Noskcaj> Would someone mind uploading http://mentors.debian.net/package/bzr-email to debian? It changes the maintainer to the QA team, other than that it just adds ubuntu's changes and bumps debhelper.
<Noskcaj> And can someone update https://code.launchpad.net/~debian-bazaar/bzr-explorer/unstable to point to the new debian address
#bzr 2013-12-08
<glen> how do i delete tag on remote bzr?
<jelmer> glen: bzr tag --delete -d remote-url name
<glen> thanks
<glen> does anyone here know about bzr-git syncing
<jelmer> glen: there are a few tools in git built around the fast-import toolchain
<jelmer> and there is bzr-git
<jelmer> I'm mostly familiar with the latter
<glen> i'm actually using bzr-git-ng, but it's frontend to fastimport things
<glen> there was some bug in bzr migration, so i uncommitted two commits in both bzr and git, now i'm stuck with some other message: http://sprunge.us/TeLX
<jelmer> glen: I think you mean git-bzr-ng?
<glen> yes
<jelmer> sorry, not familiar with that tool
<glen> i'm just not understanding where it gets that ref, and what files to clear more
#bzr 2014-12-05
<sotiredofthesest> I've got a branch that I've committed and I no longer want it sitting in my bzr repo.  What's the proper way to delete it?
<sotiredofthesest> I think the last time that I had this problem I ended up messing something up by using the shell "rm" command.
<lulwhat> hello is anyone here ?
#bzr 2015-12-05
<xmajedz> yo
<xmajedz> any one there
#bzr 2016-12-06
<LeoNerd> Having dist-upgraded my laptop, I can't run bzr any more. Lots of complaints of:  TypeError: first argument must be string or compiled pattern
<LeoNerd> Ah; already fixed. I just had to  apt-get install bzr/unstable
#bzr 2016-12-07
<throstur> is there a "lazy resolve conflicts" command? for some really weird reason everything is conflicted and I just want to "revert all conflicted files"
<LeoNerd> What do you mean "lazy"?
<throstur> I ended up just using sed on bzr status and doing it that way
<throstur> took a lot longer than it could have but it worked
#bzr 2016-12-08
<ychaouche> Hello #bzr
<ychaouche> I am confused with this problem : bzr add DIRECTORY seems to be failing silently because when I try to commit it tells me there are no changes to commit : : https://gist.githubusercontent.com/ychaouche/fff5b16c70286a5b1e75f8e32c8e4fab/raw/f9f29db1f06a8baf92d088fc587a8dc6a552d6e9/gistfile1.txt
<ychaouche> but when I try to commit from inside DIRECTORY it happily accepts to.
<fullermd> I'd say it's a separate branch.
<fullermd> That is, ~/SCRIPTS is a branch, and ~/SCRIPTS/DOTFILES is also a branch, and you've got changes in DOTFILES, but there aren't any in SCRIPTS ('cuz DOTFILES isn't part of scripts)
<ychaouche> possible
<ychaouche> when branch root is "." then DOTFILES is itself a branch, right ?
