| === nlisgo_ is now known as nlisgo | ||
| ScislaC | 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? | 01:17 |
|---|---|---|
| ScislaC | Okay... apparently the push went into limbo and I could uncommit and then push. | 01:21 |
| === ubott2 is now known as ubottu | ||
| magcius | huh | 10:04 |
| magcius | 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 | 10:04 |
| magcius | 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? | 10:05 |
| thumper | magcius: i think there is a bug somewhere for that | 10:19 |
| thumper | magcius: I think it should record locally both the translated and untranslated path | 10:19 |
| thumper | magcius: that way bzr could give you some more meaningful error messages | 10:19 |
| magcius | thumper: there's some other problems with bzr I have. | 10:22 |
| thumper | magcius: ask and maybe I can help | 10:22 |
| magcius | thumper: 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 | 10:23 |
| Peng_ | Or we can dismiss you completely, but at least you tried. :D | 10:23 |
| magcius | thumper: and it had this large number "1546588" but no end goal | 10:23 |
| magcius | thumper: this wasn't a Launchpad repo | 10:23 |
| Peng_ | magcius: One situation that causes is that is known/in progress/fixed. Not sure which. | 10:23 |
| Peng_ | magcius: Uh, dunno about the large number, tho. | 10:23 |
| thumper | magcius: a local repo? | 10:23 |
| magcius | thumper: Savannah | 10:23 |
| thumper | magcius: ah | 10:24 |
| thumper | magcius: as far as I'm aware, Savannah doesn't yet have a smart server | 10:24 |
| thumper | magcius: so it is using a dumb network transport | 10:24 |
| magcius | thumper: why do you need a smart server? | 10:24 |
| thumper | magcius: I know that they are looking into this | 10:24 |
| Peng_ | magcius: So performance doesn't suck. | 10:24 |
| magcius | thumper: shouldn't Content-Length be all you need? | 10:24 |
| thumper | magcius: you don't need one, but it makes it much faster | 10:24 |
| magcius | thumper: alright | 10:24 |
| thumper | magcius: the way that the 2a format works makes it pretty inefficient over dumb network transports | 10:24 |
| magcius | thumper: 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 | 10:25 |
| magcius | thumper: I think "bzr up" with no arguments, if up to date, should say "(maybe you meant to bzr pull?)" | 10:25 |
| magcius | or something similar | 10:26 |
| thumper | magcius: for a bound branch that makes sense | 10:26 |
| magcius | thumper: okay | 10:26 |
| magcius | and the last three gripes I have are all Loggerhead ones | 10:26 |
| Peng_ | Heh. | 10:26 |
| thumper | magcius: have you filed the gripes as bugs on lp:loggerhead? | 10:27 |
| magcius | thumper: not yet | 10:27 |
| magcius | one, please put a lefthand margin on the code viewer. It's impossible to read code with no indentation levels | 10:27 |
| thumper | magcius: please do, we are starting to get some more traction on loggerhead | 10:27 |
| magcius | thumper: I will | 10:27 |
| magcius | two, please don't put ":" in your URLs. They make this horrible "%3F" | 10:28 |
| Peng_ | Heh. | 10:28 |
| Peng_ | I forget, where is that done? | 10:28 |
| magcius | and for some reason, Loggerhead doesn't handle the double encoding that some awful browsers do which turn "%3F" in a URL into "%253F" | 10:29 |
| magcius | So it's impossible to paste a link without hand-editing it | 10:29 |
| magcius | 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 | 10:30 |
| magcius | And that's all | 10:30 |
| magcius | What I would do for the third one is set up a soft redirect like cgit does | 10:31 |
| magcius | Otherwise, great work! | 10:32 |
| Peng_ | Please file bugs. | 10:33 |
| magcius | Peng_: I feel sort of bratty about filing 4 or 5 bugs at once | 10:34 |
| Peng_ | magcius: Heh, I do too when I do that, but as kind of a Loggerhead developer, I don't mind. Your bugs sound good. | 10:35 |
| Peng_ | s/do too/feel the same way/ | 10:36 |
| cbz | 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 | 10:41 |
| Peng_ | cbz: You'll have to be more specific than "some kind or another". | 10:42 |
| cbz | 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 | 10:47 |
| cbz | it's not consistently the same path | 10:47 |
| cbz | I tried creating it without a shared repository and got that error once, and got this once bzr: ERROR: [Error 5] Access is denied | 10:48 |
| cbz | 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 | 10:49 |
| cbz | In which case i can't figure out why it should work fine on one machine and not on the other | 10:49 |
| Peng_ | cbz: Got some weird file system? A network file syste,? | 10:50 |
| cbz | no - both are on virtually identically specced windows machines, using the same install image and using local disks | 10:51 |
| cbz | svn is working on both machines too - so it isn't that | 10:52 |
| jelmer | mwhudson: hey | 11:38 |
| jelmer | mwhudson: it'd be great if you contributed a patch for bug 525571 ! | 11:38 |
| ubottu | Launchpad bug 525571 in launchpad-code "bzr svn-import fails when invoked concurrently" [High,Triaged] https://launchpad.net/bugs/525571 | 11:38 |
| james_w | hey jelmer | 12:06 |
| james_w | back home now? | 12:06 |
| jelmer | james_w: hey | 12:09 |
| jelmer | james_w: yeah, it was nice to see a bit of Lisbon though, wasn't all bad :-) | 12:09 |
| james_w | good | 12:10 |
| Peng_ | jam: ping | 13:30 |
| Peng_ | Darn. Now I have to do research! :P | 13:31 |
| mwhudson | jelmer: i guess | 13:32 |
| cbz | gah | 13:35 |
| cbz | another Error 5 | 13:35 |
| Peng_ | 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. | 13:39 |
| cbz | curiouser and curiouser - everything appears to have worked properly *APART* from populating the working tree | 13:40 |
| cbz | 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 | 14:24 |
| jelmer | cbz: what are you trying to do exactly? | 14:24 |
| cbz | 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 | 14:28 |
| cbz | The latter appears to be possibly locking related | 14:29 |
| cbz | The former appears to be this https://bugs.launchpad.net/subversion/+bug/347334 | 14:29 |
| ubottu | Ubuntu bug 347334 in subversion "bzr: ERROR: [Errno 5] Can't open 'C:\tmp\tempfile.tmp': Zugriff verweigert ("Permission denied")" [Medium,Triaged] | 14:29 |
| luke-jr | so I hacked bzr-svn up enough to get it working with my svn repo finally, but now it only works pre-bzr-svn :/ | 17:48 |
| luke-jr | that is, the first bazaar commit on svn breaks it | 17:48 |
| luke-jr | presumably from the root dir properties | 17:48 |
| luke-jr | is there a way to get bzr-svn to ignore that subset of the properties yet still read the revid/author/etc info? | 17:48 |
| cbz | i found i had to use rebase rather than pull - no idea if that is your issue | 18:10 |
| cbz | Separate issue - is it safe to delete obsolete_packs? | 18:12 |
| === Adys_ is now known as Adys | ||
| jelmer | luke-jr: you can remove those properties from the repository manually | 18:28 |
| jelmer | 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 | 18:28 |
| luke-jr | jelmer: impossible without recreating the svn repo | 18:28 |
| luke-jr | jelmer: right now, my copy is a bugfix ;) | 18:29 |
| jelmer | luke-jr: I disagree it's a bugfix | 18:29 |
| luke-jr | jelmer: you saw the diff? | 18:29 |
| jelmer | luke-jr: anyway, we've had this discussion before :-) | 18:29 |
| jelmer | luke-jr: no, but I assume it's what we talked about earlier? | 18:30 |
| luke-jr | unlikely | 18:30 |
| luke-jr | it's a simple fix | 18:30 |
| jelmer | do you have the diff up somewhere? | 18:30 |
| luke-jr | http://bazaar.launchpad.net/~luke-jr/bzr-svn/bzr-svn-longest-branch-path/revision/3250 | 18:30 |
| luke-jr | beyond that change, it | 18:30 |
| luke-jr | it's mere configuration | 18:30 |
| luke-jr | another approach that would fix it even better is assuming (correctly) that any/all parents of a branch are also a branch :p | 18:31 |
| jelmer | luke-jr: So you're basically considering branches/ to be a branch as well? | 18:34 |
| luke-jr | jelmer: the code repository has had many various layouts over the years | 18:34 |
| luke-jr | branches = armagetronad/trunk/armagetronad;armagetronad/branches/*/armagetronad;armagetron/trunk;armagetron/branches/*;armagetronad/trunk;armagetronad/branches/*;armagetronad/armagetronad/trunk;armagetronad/armagetronad/branches/*;private/*/*/armagetronad | 18:34 |
| luke-jr | this lists all of them (I think) | 18:35 |
| luke-jr | originally it was armagetron/{trunk,tags,branches}, then armagetronad/{trunk,tags,branches}, then armagetronad/{trunk,tags,branches}/armagetronad | 18:36 |
| luke-jr | etc | 18:36 |
| jelmer | ah, I think I understand what you're trying to do now | 18:36 |
| luke-jr | bzr-svn sees the parent branch using a different layout and assumes it's not a branch, so cuts the branch short | 18:36 |
| luke-jr | so with that patch, plus the config, I can access the older revisions fine | 18:37 |
| luke-jr | but commits from misconfigured/unpatched bzr-svn are messing me up now | 18:37 |
| jelmer | luke-jr: I don't see how that could be a problem, the commits' revision ids contain the branch path | 18:37 |
| cbz | can i set whoami on a per repository basis? | 18:38 |
| luke-jr | well, part of it was the bzr:revision-id:v3-list-QlpoOTFBWSZTWZvbKhsAAAdRgAAQABK6798QIABURMgAAaeoNT1TxT1DQbKaeobXKiyAmlWT7Y5MkdJOtXDtB7w7DOGFBHiOBxaUIu7HQyyQSvxdyRThQkJvbKhs property | 18:38 |
| jelmer | cbz: yes | 18:38 |
| luke-jr | the first column tells bzr-svn what the bzr-revno is | 18:38 |
| luke-jr | and is now wrong | 18:38 |
| luke-jr | by 1933 revisions | 18:38 |
| jelmer | luke-jr: that | 18:38 |
| luke-jr | if I recreate the svn repo with that modified, bzr log shows adjusted revnos, but still cuts history short | 18:39 |
| jelmer | 's a bug in your branch, it shouldn't generate different data from existing svn data | 18:39 |
| luke-jr | so I'm missing something else as well | 18:39 |
| luke-jr | jelmer: ??? | 18:39 |
| jelmer | luke-jr: your branch can generate other revisions than older versions of bzr-svn | 18:39 |
| jelmer | luke-jr: but it should not generate different contents for revisions with the same revision id | 18:40 |
| * luke-jr wants to keep compatibility with existing misconfigured-bzr-svn branches, btw | 18:40 | |
| luke-jr | anyhow, that's actually unrelated to my branch | 18:41 |
| luke-jr | that's the difference between unconfigured and configured | 18:41 |
| jelmer | luke-jr: from what you're saying I get the impression you've broken backwards compatibility somehow | 18:41 |
| luke-jr | unconfigured bzr-svn cuts the history short when the repo changes layout | 18:41 |
| jelmer | luke-jr: no | 18:41 |
| luke-jr | configured bzr-svn continues the history back to the first commit | 18:41 |
| jelmer | 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) | 18:42 |
| luke-jr | 1.0.2 seems to still use branching schemes... | 18:42 |
| jelmer | luke-jr: the layout doesn't influence the length of the history in any way | 18:42 |
| luke-jr | o.O | 18:42 |
| jelmer | luke-jr: 1.0.2 still supports branching schemes if you try to access a repository that uses them | 18:42 |
| jelmer | luke-jr: but (unless you set 'mapping = v3' it won't write them) | 18:43 |
| jelmer | anyway, gtg - back in an hour or 3 | 18:43 |
| luke-jr | :( | 18:43 |
| luke-jr | jelmer: aha, I see. | 18:44 |
| luke-jr | jelmer: any way to destroy the branching schemes stuff without losing actual commit info? | 18:44 |
| luke-jr | ideally keeping revids compatible with existing branches? :) | 18:44 |
| === radoe_ is now known as radoe | ||
| === Adys is now known as [Adys] | ||
| jelmer | luke-jr: no, there isn't a way to do that while keeping the revision ids | 23:02 |
| jelmer | luke-jr: you would need branching schemes to do that | 23:02 |
| luke-jr | how about with new revids? | 23:02 |
| luke-jr | (keeping file-ids?) | 23:03 |
| jelmer | IIRC the file ids shouldn't change anyway | 23:05 |
| luke-jr | even if the files are now seen as being created in another revision? | 23:05 |
| luke-jr | in any case, I still need a way to ignroe the v3 mapping data | 23:05 |
| jelmer | 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 | 23:07 |
| jelmer | luke-jr: ignoring the v3 mapping data can only really be done by stripping all the bzr: properties from those revisions | 23:07 |
| luke-jr | but now that the full history is visible, it sees the *real* svn revno the files were introduced | 23:07 |
| luke-jr | whereas the old data and now-real file-ids all "appeared" in the cutoff rev | 23:07 |
| luke-jr | jelmer: these aren't revprops, so impossible :( | 23:08 |
| jelmer | rikght, so those file ids would change | 23:08 |
| luke-jr | no config setting to change the prop name perhaps? | 23:08 |
| jelmer | luke-jr: no, that means the mapping is no longer deterministic (because dependent on a config variable) | 23:08 |
| luke-jr | better than broken :/ | 23:08 |
| jelmer | luke-jr: unfortunately this really is a legacy problem with the v3 mappings | 23:08 |
| luke-jr | what of the file-id issue? | 23:09 |
| luke-jr | since it sounds like I'm going to need to re-write the Svn repo anyway, is there a revprop or root prop I can throw on svn-r1 to set file-ids to a specific string? | 23:09 |
| jelmer | 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 | 23:10 |
| luke-jr | it needs to be on the rev introducing the file? | 23:12 |
| jelmer | yeah, or affecting the file somehow | 23:12 |
| jelmer | (text modification, rename) | 23:12 |
| * luke-jr ponders | 23:14 | |
| jelmer | luke-jr: I'm sorry you got bit by this as an early adopter of bzr-svn | 23:15 |
| jelmer | luke-jr: we did get it right in the end imho, but that doesn't change your existing data of course.. | 23:15 |
| luke-jr | well, it'd probably be easiest to do a one-time conversion and just trash svn at the end IMO | 23:16 |
| luke-jr | but that creates a different problem | 23:16 |
| luke-jr | in fact, it might be something I need to consider now... | 23:16 |
| luke-jr | I'm going to need to redo this process yet again someday, when Bazaar can do a lossless conversion | 23:16 |
| luke-jr | will that again require new revids? :/ | 23:16 |
| jelmer | luke-jr: what do you mean with lossless conversion exactly? | 23:17 |
| jelmer | luke-jr: svn:externals, svn:mime-type, that sort of thing? | 23:17 |
| luke-jr | versioned/file properties and copy metadata, at least | 23:17 |
| jelmer | luke-jr: but yeah, supporting any of those will require a mapping bump so new revids | 23:18 |
| luke-jr | :( | 23:18 |
| jelmer | luke-jr: I'm hoping to add support for them all at once | 23:19 |
| luke-jr | even if we don't care to be compatible with other bzr-svn (because we throw away the Svn)? | 23:19 |
| jelmer | luke-jr: what about the existing imports that have already been made of your svn repo with other versions of bzr-svn? | 23:20 |
| luke-jr | well, by preserving the revid, those should be compatible? :) | 23:21 |
| jelmer | luke-jr: bzr doesn't like multiple (different) revisions with the same revid | 23:21 |
| luke-jr | if you mean the present-day problem, that's why I want to keep the file-ids | 23:21 |
| luke-jr | i c | 23:21 |
| jelmer | luke-jr: that's the whole reason bzr-svn is so careful about revids | 23:21 |
| luke-jr | and bzr doesn't have timestamps so it can replace an old <revid> with a new <revid>? | 23:21 |
| jelmer | luke-jr: timestamps of what exactly? When the revision was written to disk? | 23:22 |
| luke-jr | hmm, good point | 23:22 |
| luke-jr | last update? | 23:22 |
| luke-jr | could probably be an integer version actually | 23:22 |
| jelmer | the newest revision wasn't necessarily created by a "correct" version of bzr-svn | 23:22 |
| jelmer | luke-jr: who determines that integer version? And what if converting from one to the other is not lossless? | 23:23 |
| luke-jr | the human perhaps | 23:23 |
| jelmer | luke-jr: bzr-svn isn't the only place where this problem arises - bzr itself has multiple storage formats, all with different capabilities | 23:23 |
| jelmer | luke-jr: what do you consider the canonical version? | 23:24 |
| luke-jr | any version that's lossless from the initial commit? :) | 23:24 |
| jelmer | luke-jr: what's the initial commit in this case? | 23:25 |
| luke-jr | in my case, a commit on CVS or Subversion | 23:25 |
| jelmer | luke-jr: and what if somebody else bases a commit on a version-2 import of the svn revision | 23:25 |
| jelmer | luke-jr: and then you try to merge their commit into your local repo where you have version-3 ? | 23:26 |
| jelmer | luke-jr: bzr will need version-2 as well to be able to apply the deltas it has received | 23:26 |
| luke-jr | lossless is lossless | 23:26 |
| jelmer | luke-jr: if you only support lossless then this is pointless | 23:26 |
| jelmer | luke-jr: since one version can't support nested trees while the other does | 23:27 |
| jelmer | luke-jr: as lossless conversion between them is not possible | 23:27 |
| luke-jr | CVS -> Subversion was possible <.< | 23:27 |
| luke-jr | I guess I should be glad we didn't use cherry-picking in Svn | 23:27 |
| luke-jr | then we'd have yet more functionality to wait for Bzr to supprot | 23:28 |
| luke-jr | :/ | 23:28 |
| luke-jr | on that note, though... any idea why it's taking so long for these things (versioned file metadata and copying) to get spec'd? it's not like imports need bzr to act on it, just store it | 23:29 |
| jelmer | luke-jr: CVS and Subversion both aren't centralised | 23:29 |
| jelmer | luke-jr: versioned file metadata as such isn't on the agenda afaik | 23:31 |
| jelmer | luke-jr: just individual things, e.g. keywords, line endings, etc | 23:31 |
| jelmer | luke-jr: copy metadata needs a decision on what to do about merges | 23:31 |
| jelmer | luke-jr: the worry is that storing that information and not using it will cause invalid data to be recorded | 23:31 |
| luke-jr | for now, a merge involving a copy could easily just throw an unsupportederror | 23:32 |
| jelmer | 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 | 23:32 |
| luke-jr | how is that disagreeing with it? :p | 23:32 |
| jelmer | luke-jr: throwing an unsupportederror seems like a bad idea to me, that means everything that involves copying is unmergeable | 23:32 |
| luke-jr | well, there's various possibilities | 23:33 |
| luke-jr | it could just conflict every time and let the human handle it | 23:33 |
| jelmer | luke-jr: I'm disagreeing that we should support merge for copies when we introduce copy tracking support. | 23:34 |
| jelmer | luke-jr: I think just supporting it for annotate/log and roundtripping for e.g. bzr-svn/bzr-git is a step forward. | 23:34 |
| luke-jr | git doesn't support copies anyway | 23:34 |
| luke-jr | I really just want to finish migrating our project to Bazaar and leave Subversion historical | 23:35 |
| jelmer | luke-jr: one of the problems with all of these is also that they require format changes in bzr itself | 23:37 |
| jelmer | luke-jr: and that's something we're not fond of either | 23:37 |
| jelmer | luke-jr: or would at least like to do in batches | 23:37 |
| luke-jr | the sooner the better :p | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!