User1: I have a branch I committed and pushed to not knowing a change happened prior to committing (I almost always do a pull prior to the process, but forgot to this time). Anyway, I did a bzr revert, it got my local copy mostly back in shape, but it's trying to force me to do a merge. Is that trying to do it locally or on lp?
User1: Okay... apparently the push went into limbo and I could uncommit and then push.
User2: huh
User2: I just spent 20 minutes trying to understand why it wasn't pulling new revisions when I figured out that it doesn't track when the "lp:foobar" shortname updates
User2: is there any reason why bzr couldn't, when I say, "bzr get lp:mything", store the literal "lp:mything", and not the resolved URL?
User3: User2 i think there is a bug somewhere for that
User3: User2 I think it should record locally both the translated and untranslated path
User3: User2 that way bzr could give you some more meaningful error messages
User2: User3 there's some other problems with bzr I have.
User3: User2 ask and maybe I can help
User2: User3 one is the progress bar. I was trying to branch a repo, and it was stuck on what looked like 0% for the longest time
User4: Or we can dismiss you completely, but at least you tried. :D
User2: User3 and it had this large number "1546588" but no end goal
User2: User3 this wasn't a Launchpad repo
User4: User2 One situation that causes is that is known/in progress/fixed. Not sure which.
User4: User2 Uh, dunno about the large number, tho.
User3: User2 a local repo?
User2: User3 Savannah
User3: User2 ah
User3: User2 as far as I'm aware, Savannah doesn't yet have a smart server
User3: User2 so it is using a dumb network transport
User2: User3 why do you need a smart server?
User3: User2 I know that they are looking into this
User4: User2 So performance doesn't suck.
User2: User3 shouldn't Content-Length be all you need?
User3: User2 you don't need one, but it makes it much faster
User2: User3 alright
User3: User2 the way that the 2a format works makes it pretty inefficient over dumb network transports
User2: User3 another: I tried to do "bzr up" (was still in svn mode) and it said "Tree is up to date." until I realized I was supposed to pull
User2: User3 I think "bzr up" with no arguments, if up to date, should say "(maybe you meant to bzr pull?)"
User2: or something similar
User3: User2 for a bound branch that makes sense
User2: User3 okay
User2: and the last three gripes I have are all Loggerhead ones
User4: Heh.
User3: User2 have you filed the gripes as bugs on lp:loggerhead?
User2: User3 not yet
User2: one, please put a lefthand margin on the code viewer. It's impossible to read code with no indentation levels
User3: User2 please do, we are starting to get some more traction on loggerhead
User2: User3 I will
User2: two, please don't put ":" in your URLs. They make this horrible "%3F"
User4: Heh.
User4: I forget, where is that done?
User2: and for some reason, Loggerhead doesn't handle the double encoding that some awful browsers do which turn "%3F" in a URL into "%253F"
User2: So it's impossible to paste a link without hand-editing it
User2: third, don't change between this "tree" link and the "file" link. Nice URLs should be hand-editable, if I'm linked to a file, the first instinct for me to get the directory is delete the filename portion
User2: And that's all
User2: What I would do for the third one is set up a soft redirect like cgit does
User2: Otherwise, great work!
User4: Please file bugs.
User2: User4 I feel sort of bratty about filing 4 or 5 bugs at once
User4: User2 Heh, I do too when I do that, but as kind of a Loggerhead developer, I don't mind. Your bugs sound good.
User4: s/do too/feel the same way/
User5: this is very strange, bzr works on one machine to import svn repositories, on the other any attempt to create branches ends in errors of some kind or another
User4: User5 You'll have to be more specific than "some kind or another".
User5: the branch will work up to a point, and then i'll get an error saying "bzr: error: [error 145] the directory is not empty: u'" with a path inside the shared repositoriy i'm using
User5: it's not consistently the same path
User5: I tried creating it without a shared repository and got that error once, and got this once bzr: ERROR: [Error 5] Access is denied
User5: The only consistent thing is that there is some indications from the various mailing lists that some kind of locking may be involved at least in some cases
User5: In which case i can't figure out why it should work fine on one machine and not on the other
User4: User5 Got some weird file system? A network file syste,?
User5: no - both are on virtually identically specced windows machines, using the same install image and using local disks
User5: svn is working on both machines too - so it isn't that
User6: User9 hey
User6: User9 it'd be great if you contributed a patch for bug 525571 !
User7: Launchpad bug 525571 in launchpad-code "bzr svn-import fails when invoked concurrently" [High,Triaged] https://launchpad.net/bugs/525571
User8: hey jelmer
User8: back home now?
User6: User8 hey
User6: User8 yeah, it was nice to see a bit of Lisbon though, wasn't all bad :-)
User8: good
User4: jam: ping
User4: Darn. Now I have to do research! :P
User9: User6 i guess
User5: gah
User5: another Error 5
User4: jam: Never mind about the ping. FYI, I just made it impossible to do Container._set_property for attributes that start with an underscore. Hope you don't mind, but it was the easiest way to fix a nasty bug.
User5: curiouser and curiouser - everything appears to have worked properly *APART* from populating the working tree
User5: i'm pretty sure at least some of my troubles are coming from bugs within subvertpy - or at least the version bundled in bazaar2-.1.1
User6: User5 what are you trying to do exactly?
User5: just branch from a fairly large subversion repository - on one machine it works flawlessly, on the other i get an Error 5 or an Error 145 for identical commands
User5: The latter appears to be possibly locking related
User5: The former appears to be this https://bugs.launchpad.net/subversion/+bug/347334
User7: Ubuntu bug 347334 in subversion "bzr: ERROR: [Errno 5] Can't open 'C:\tmp\tempfile.tmp': Zugriff verweigert ("Permission denied")" [Medium,Triaged]
User5: i found i had to use rebase rather than pull - no idea if that is your issue
User5: Separate issue - is it safe to delete obsolete_packs?
User6: luke-jr: you can remove those properties from the repository manually
User6: luke-jr: alternatively you could hack bzr-svn to ignore them, your copy of bzr-svn would already break very badly when interoperating with other versions of bzr-svn
User6: luke-jr: I disagree it's a bugfix
User6: luke-jr: anyway, we've had this discussion before :-)
User6: luke-jr: no, but I assume it's what we talked about earlier?
User6: do you have the diff up somewhere?
User6: luke-jr: So you're basically considering branches/ to be a branch as well?
User6: ah, I think I understand what you're trying to do now
User6: luke-jr: I don't see how that could be a problem, the commits' revision ids contain the branch path
User5: can i set whoami on a per repository basis?
User6: User5 yes
User6: luke-jr: that
User6: 's a bug in your branch, it shouldn't generate different data from existing svn data
User6: luke-jr: your branch can generate other revisions than older versions of bzr-svn
User6: luke-jr: but it should not generate different contents for revisions with the same revision id
 * luke-jr wants to keep compatibility with existing misconfigured-bzr-svn branches, btw
User6: luke-jr: from what you're saying I get the impression you've broken backwards compatibility somehow
User6: luke-jr: no
User6: luke-jr: older versions of bzr-svn that used branching schemes did that, it's not true for newer versions (bzr-svn >= 0.4.x)
User6: luke-jr: the layout doesn't influence the length of the history in any way
User6: luke-jr: 1.0.2 still supports branching schemes if you try to access a repository that uses them
User6: luke-jr: but (unless you set 'mapping = v3' it won't write them)
User6: anyway, gtg - back in an hour or 3
User6: luke-jr: no, there isn't a way to do that while keeping the revision ids
User6: luke-jr: you would need branching schemes to do that
User6: IIRC the file ids shouldn't change anyway
User6: luke-jr: the default file id generation algorithm doesn't use the revision id but just the svn revno in which the file was introduced, the path at that point and the repo uuid
User6: luke-jr: ignoring the v3 mapping data can only really be done by stripping all the bzr: properties from those revisions
User6: rikght, so those file ids would change
User6: luke-jr: no, that means the mapping is no longer deterministic (because dependent on a config variable)
User6: luke-jr: unfortunately this really is a legacy problem with the v3 mappings
User6: luke-jr: you can set the bzr:file-ids revprop on revision properties that introduce new files to force the file ids for certain paths
User6: yeah, or affecting the file somehow
User6: (text modification, rename)
 * luke-jr ponders
User6: luke-jr: I'm sorry you got bit by this as an early adopter of bzr-svn
User6: luke-jr: we did get it right in the end imho, but that doesn't change your existing data of course..
User6: luke-jr: what do you mean with lossless conversion exactly?
User6: luke-jr: svn:externals, svn:mime-type, that sort of thing?
User6: luke-jr: but yeah, supporting any of those will require a mapping bump so new revids
User6: luke-jr: I'm hoping to add support for them all at once
User6: luke-jr: what about the existing imports that have already been made of your svn repo with other versions of bzr-svn?
User6: luke-jr: bzr doesn't like multiple (different) revisions with the same revid
User6: luke-jr: that's the whole reason bzr-svn is so careful about revids
User6: luke-jr: timestamps of what exactly? When the revision was written to disk?
User6: the newest revision wasn't necessarily created by a "correct" version of bzr-svn
User6: luke-jr: who determines that integer version? And what if converting from one to the other is not lossless?
User6: luke-jr: bzr-svn isn't the only place where this problem arises - bzr itself has multiple storage formats, all with different capabilities
User6: luke-jr: what do you consider the canonical version?
User6: luke-jr: what's the initial commit in this case?
User6: luke-jr: and what if somebody else bases a commit on a version-2 import of the svn revision
User6: luke-jr: and then you try to merge their commit into your local repo where you have version-3 ?
User6: luke-jr: bzr will need version-2 as well to be able to apply the deltas it has received
User6: luke-jr: if you only support lossless then this is pointless
User6: luke-jr: since one version can't support nested trees while the other does
User6: luke-jr: as lossless conversion between them is not possible
User6: luke-jr: CVS and Subversion both aren't centralised
User6: luke-jr: versioned file metadata as such isn't on the agenda afaik
User6: luke-jr: just individual things, e.g. keywords, line endings, etc
User6: luke-jr: copy metadata needs a decision on what to do about merges
User6: luke-jr: the worry is that storing that information and not using it will cause invalid data to be recorded
User6: luke-jr: I'm not sure if I agree with that last part, I'd like it to actually be stored myself and perhaps just used for log/annotate. I don't really care about merge atm
User6: luke-jr: throwing an unsupportederror seems like a bad idea to me, that means everything that involves copying is unmergeable
User6: luke-jr: I'm disagreeing that we should support merge for copies when we introduce copy tracking support.
User6: luke-jr: I think just supporting it for annotate/log and roundtripping for e.g. bzr-svn/bzr-git is a step forward.
User6: luke-jr: one of the problems with all of these is also that they require format changes in bzr itself
User6: luke-jr: and that's something we're not fond of either
User6: luke-jr: or would at least like to do in batches
bzr
Ubuntu IRC