| spiv | Well, technically, a .bzr/repository folder without an upload folder is corrupt. | 00:02 |
|---|---|---|
| spiv | It happens to be a very easy-to-repair corruption, though. | 00:02 |
| emmajane | spiv, yes. :) | 00:02 |
| emmajane | spiv, it's "corrupt" not "OMG THE SKY IS FALLING" ... | 00:02 |
| kenichi | hello, i'm a bzr n00b, and it's printing this error with a "get" : bzr: ERROR: Lock not held: LockableFiles... | 00:04 |
| kenichi | hmm.... it also happens with "info" on the same URL... is it a server issue? | 00:04 |
| jml | I need to make a knit branch with lots of ugly, url-escape-needing paths. | 00:11 |
| jml | anyone have one lying around? | 00:12 |
| mwhudson | bzr-svn is good at that :) | 00:12 |
| mwhudson | jml: https://code.edge.launchpad.net/~mwhudson/pydoctor/axiom-attr-support might fit | 00:12 |
| mwhudson | yeah, looks like it | 00:13 |
| jml | mwhudson: sweet. thanks. | 00:13 |
| mwhudson | e.g. http://bazaar.launchpad.net/~mwhudson/pydoctor/axiom-attr-support/.bzr/repository/knits/06/ | 00:14 |
| lifeless | jml: interesting; its a key goal of switch to switch with edits; you just want a '--with-edits' option, or ??? | 00:22 |
| jml | lifeless: basically, yes. | 00:22 |
| jml | lifeless: the thing that's happened a lot to me is that I've switched to trunk to pull, and got conflicts because I have uncommitted changes. | 00:23 |
| lifeless | jml: would it help if switch told you about the remaining local edits? | 00:23 |
| lifeless | e.g. switch == switch + status --short? | 00:23 |
| jml | lifeless: before or after it switched? | 00:23 |
| lifeless | post | 00:24 |
| lifeless | pre is meaningless as the switch may eliminate outstanding changes | 00:24 |
| jml | hmmm. well, it would help if there was a clear way to undo it, particularly in the case of conflicts. | 00:24 |
| lifeless | jml: I think this needs more discussion; please mail the list and I'll try to reply tonight once backa tthe hotel | 00:25 |
| jml | lifeless: will do. | 00:25 |
| mwhudson | i've always found it slightly weird that pull doesn't complain about local changes | 00:28 |
| mwhudson | if you're pulling, you're maintaining a local mirror | 00:28 |
| mwhudson | wth are you doing editing it? | 00:29 |
| mwhudson | other workflows may vary i guess | 00:29 |
| Peng_ | kenichi: :P | 00:30 |
| Peng_ | fwiw, kenichi is running bzr 1.10, and i experience the same problem in bzr.dev. | 00:33 |
| kenichi | http://pastebin.com/d37ce3b4f <--- all two lines of my issue :) | 00:33 |
| Peng_ | Traceback: http://paste.pocoo.org/show/VFV2fMUc25uhKKEBIuRf/ (But it doesn't look very interesting; the exception is rather self-explanatory.) | 00:36 |
| mwhudson | is bzr-svn messing things up again? | 00:37 |
| Peng_ | mwhudson: For this? --no-plugins doesn't help. | 00:38 |
| mwhudson | ah well | 00:39 |
| Peng_ | Heh. | 00:40 |
| abentley1 | mwhudson: It's more for a workflow where you "bzr pull; bzr commit; bzr push". | 00:42 |
| === abentley1 is now known as abentley | ||
| mwhudson | yeah, i guess so | 00:43 |
| jml | use pyflakes guys | 01:02 |
| jml | https://bugs.edge.launchpad.net/bzr/+bug/307327 | 01:03 |
| ubottu | Error: <Bugtracker.plugin.Launchpad instance at 0x874150c> bug 307327 not found | 01:03 |
| jml | I smell replication lag :) | 01:03 |
| spiv | jml: by "guys", you mean "abentley" ;) | 01:04 |
| abentley | jml: ? | 01:07 |
| spiv | abentley: a -Dhpss mutter that moved in your patch from remote.py to graph.py is failing due to a missing import of mutter in graph.py | 01:08 |
| abentley | spiv: | 01:08 |
| abentley | Sorry. | 01:08 |
| spiv | abentley: not a big deal. I'm considering just deleting the offending mutter. | 01:09 |
| spiv | I don't think we've ever really used it, so it's just yet another thing filling log files. And -Dhpss isn't exactly the right condition for it now it's in a more general-purpose class. | 01:11 |
| spiv | Hmm, although, you did make a _debug variable for it. | 01:12 |
| spiv | So if we want to keep the debugging there ought to be tests for the debug case. | 01:12 |
| abentley | spiv: Yeah, I agreed that hpss was the wrong flag for a general-purpose thing. | 01:12 |
| jml | I'm going to make a plugin that does: bzr down bottom:; bzr pull; bzr up-thread --auto; bzr switch <original-thread> | 01:13 |
| spiv | abentley: do you have any interest in keeping that debugging? I'm inclined to just delete it. | 01:13 |
| abentley | spiv: No, I don't. | 01:13 |
| abentley | jml: What about "shelve --all" first? | 01:13 |
| spiv | Ok, let's just remove it as cruft. It's not hard to reinstate if someone actually wants it. | 01:13 |
| jml | abentley: and unshelve at the end? not a bad idea. | 01:14 |
| abentley | jml: yeah | 01:14 |
| spiv | jml, abentley: patch for 307327 sent | 01:21 |
| abentley | spiv: I see you also deleted an import. Was that deliberate? | 01:24 |
| * jml bundle buggers. | 01:25 | |
| spiv | abentley: yes. That import statement was unused. | 01:25 |
| spiv | I meant to mention that in the email... | 01:25 |
| spiv | abentley: that import statement was all that was standing between me and clean "pyflakes bzrlib/graph.py" output :) | 01:26 |
| mwhudson | i cleaned up all the flakes in bzrlib/[ab]*.py at one point i think... | 01:27 |
| abentley | spiv: I'm not sure why that was there in the first place. It may have been backwards compatibility. | 01:27 |
| spiv | abentley: well, in the absence of a comment... | 01:27 |
| * spiv looks at how long it's been there | 01:28 | |
| * spiv also wishes Python had a mechanism for deprecating module attributes | 01:28 | |
| spiv | abentley: that line was added on "Fri 2007-06-08 17:48:42 -0400", in a commit by you saying "Rename graph to deprecated_graph" | 01:29 |
| spiv | abentley: I guess it's been deprecated long enough by now? | 01:29 |
| abentley | spiv: lemme check bzrtools | 01:30 |
| spiv | abentley: hah. :) | 01:30 |
| abentley | spiv: bzrtools is still importing that stuff, but I can change it to use deprecated_graph. | 01:31 |
| spiv | abentley: thanks | 01:40 |
| spiv | abentley: I guess I should add a note to NEWS just in case someone else is still using them. | 01:41 |
| lifeless | spiv: please do | 01:41 |
| lifeless | you can deprecate a module BTW | 01:41 |
| lifeless | 1) make it demand loaded within bzrlib, 2) during import emit a warning | 01:41 |
| jml | lifeless: I've reviewed tags. I'll get to the others later. | 01:45 |
| spiv | lifeless: really, part 1) isn't even necessary. | 01:45 |
| lifeless | spiv: well, it helps :P | 01:45 |
| spiv | :) | 01:45 |
| Rolly | Someone made a mistake and committed a sensitive file in the very first revision of a branch. Can I use rebase to fix this? I think I can, but I don't understand the documentation | 01:45 |
| lifeless | jelmer: ^ we really need to make this a nobrainer | 01:46 |
| lifeless | Rolly: its something like 'bzr init; bzr merge -1 ../source; bzr revert --forget-merges; bzr rm SENSITIVE; bzr commit -m 'first post'; bzr rebase -r 2.. ../source' | 01:47 |
| Rolly | lifeless: thanks! I'll give it a shot | 01:47 |
| mwhudson | that's merge -r 1 ../source, i think | 01:47 |
| Rolly | yeah | 01:48 |
| lifeless | you'll need to use a new repository too, as the history data will stay in the repository and that would be annoying for you :) | 01:48 |
| Rolly | Ah that's OK, it's not shared :) | 01:48 |
| * spiv -> food | 01:52 | |
| Rolly | whoops, there's also a sensitive change in revno 3 | 01:53 |
| Rolly | I think I can figure it out | 01:54 |
| jml | bzr expunge-swearing | 01:54 |
| Rolly | whoops. "bzr merge -r 2 ../source" => bzr: ERROR: A nested progress bar was not 'finished' correctly. | 01:59 |
| lifeless | Rolly: -r 1..2 | 02:00 |
| lifeless | also file a bug | 02:00 |
| lifeless | bbiab, bus time | 02:00 |
| Rolly | thanks lifeless | 02:00 |
| Rolly | still get the error | 02:01 |
| Rolly | filed bug #307340 | 02:17 |
| ubottu | Launchpad bug 307340 in bzr "bzr merge: A nested progress bar was not 'finished' correctly" [Undecided,New] https://launchpad.net/bugs/307340 | 02:17 |
| meoblast001 | hi | 03:02 |
| lifeless | Rolly: oh, try -r 1..2 --force | 03:02 |
| meoblast001 | i want someone to pull from my project on launchpad but he's not a launchpad member | 03:03 |
| meoblast001 | what should he do? | 03:03 |
| lifeless | Rolly: though really, to get rev2 you want to be using rebase at that point | 03:03 |
| meoblast001 | bzr pull bzr+ssh://bazaar.launchpad.net/~mysticgalaxies/opencollab/devel ? | 03:03 |
| lifeless | meoblast001: go to the project page, then the branch and there is an http url | 03:03 |
| lifeless | meoblast001: bzr branch http://bazaar.launchpad.net/~mysticgalaxies/opencollab/devel | 03:04 |
| meoblast001 | ok | 03:04 |
| meoblast001 | thanx | 03:04 |
| Rolly | lifeless: --force still produces the same error | 03:16 |
| lifeless | Rolly: ok, you're going to have to edit the code and disable the error about progress bar not closed to see the real error | 03:21 |
| lifeless | Rolly: thats in bzrlib.progress.py | 03:21 |
| Rolly | can do | 03:23 |
| Rolly | bzrlib/progress.py? | 03:25 |
| Peng_ | Rolly: Yeah. | 03:27 |
| igc | hi all | 03:27 |
| Rolly | Peng: you'll have to guide me through it, I'm afraid. I don't know very much python. | 03:27 |
| Peng_ | Rolly: Eh. I just walked in on this conversation. | 03:27 |
| Peng_ | igc: Hello | 03:27 |
| Rolly | oh sorry, I was addressing lifeless | 03:28 |
| lifeless | Rolly: have a look for the error in the file | 03:29 |
| lifeless | Rolly: line 150 | 03:30 |
| lifeless | change | 03:30 |
| lifeless | raise errors.Missing... | 03:30 |
| lifeless | to | 03:30 |
| Rolly | ah | 03:30 |
| lifeless | return # raise errors.Missing | 03:30 |
| Rolly | lifeless: http://pastie.org/337348 | 03:34 |
| lifeless | Rolly: thats a bug; may be hard to reproduce. abentley ^ can you suggest anything? | 03:37 |
| lifeless | Rolly: may need to fill abentley in on how you got that | 03:37 |
| lifeless | Rolly: also, have you already done the init;merge;revert--forget;rm;commit dance to get the first rev across? | 03:37 |
| Rolly | yes i did | 03:38 |
| lifeless | Rolly: try bzr diff -r 1..2 ../source | bzr patch :) | 03:38 |
| Rolly | That will work, but I can wait for abentley to give his input | 03:40 |
| abentley | Rolly: I wasn't aware of any bugs in that area. Is this a publically-available branch? | 03:48 |
| === Quadduc1 is now known as Quadduc | ||
| Rolly | I'm afraid not | 03:48 |
| Rolly | Both target and source branches are 1.9-rich-root | 03:48 |
| abentley | Rolly: So you're running it on an empty branch? | 03:50 |
| Rolly | abentley: I did a few things first: | 03:52 |
| Rolly | bzr init ; bzr merge -r 1 /source ; bzr revert --forget-merges ; cp config.php config.php.template ; bzr rm config.php ; bzr add config.php.template ; bzr ci -m "Initial import" | 03:52 |
| Rolly | by the way, that last commit produced messages like "renamed TODO => TODO", "renamed classes => classes", "renamed models => models", etc | 03:54 |
| Rolly | just thought that was a little wierd | 03:54 |
| Rolly | and at the end of the messages it said: | 03:55 |
| abentley | Rolly: So, you should never merge into an empty branch unless you're deliberately trying to get the effect of pull. | 03:55 |
| Rolly | deleted | 03:55 |
| Rolly | deleted config.php | 03:55 |
| Rolly | Committed revision 1. | 03:55 |
| Rolly | notice the empty "deleted" | 03:55 |
| Rolly | I see | 03:55 |
| Rolly | I try again, this time using pull | 03:56 |
| Rolly | *I'll | 03:56 |
| abentley | Well, in your case, maybe that works. But the results are generally confusing. | 03:57 |
| abentley | Rolly: I *think* what you did is equivalent to "bzr pull -r -1; bzr uncommit" | 03:59 |
| abentley | Rolly: Why "bzr rm config.php"? | 04:00 |
| Rolly | I don't want config.php versioned at all (I wanted a sanitized config.php.template instead) | 04:02 |
| Rolly | I think pull was the wrong choice | 04:02 |
| abentley | Rolly: The empty deleted might refer to the root directory. | 04:04 |
| Rolly | It did work, though. No errors when I tried merge -r 1..2 ../source | 04:04 |
| Rolly | but config.php is right there, in revno 1 | 04:05 |
| Rolly | oh, you suggested "bzr pull -r -1; bzr uncommit". I'll try that | 04:06 |
| Rolly | doesn't uncommit still leave the old tip in the repo, though? | 04:07 |
| spiv | Yes. | 04:07 |
| Rolly | Ah, that won't work for me, then. | 04:08 |
| abentley | Rolly: So does merge. | 04:08 |
| Rolly | I think that's why lifeless initially suggested 'bzr init; bzr merge -r 1 ../source; bzr revert --forget-merges; etc...' | 04:11 |
| abentley | Rolly: That will still leave the old tip in the repo. | 04:11 |
| spiv | There currently isn't anything that removes revisions from a repo. You can gc the repo manually by making a new repo and copying across only the tips you want to keep. | 04:12 |
| Rolly | Is there no way to rebase this branch so that the sensitive file in revno 1 of ../source is completely gone? | 04:12 |
| spiv | Rolly: removing the sensitive data from the history of the branch is different to also removing it from the repo. | 04:13 |
| Rolly | spiv: what about the remove-revisions plugin? | 04:13 |
| spiv | Rolly: Rebasing will change the branch history, but you still need to take extra steps (i.e. making a new repo) to remove the revisions from the repo. | 04:14 |
| abentley | Rolly: If you create a new copy of the branch with "bzr branch", it won't copy the tip. | 04:14 |
| spiv | Rolly: I'm not familiar with it, sorry. | 04:14 |
| Rolly | OK. Boy, this is extremely confusing to me ;D | 04:15 |
| Rolly | if I branch -r 1 of ../source, the offending file I wish to remove is right there in my repo, no? | 04:16 |
| Rolly | *in my new repo | 04:16 |
| abentley | Rolly: Yes. I'm talking about if you branch "." | 04:18 |
| Rolly | What if I simply export or copy revno 1 of ../source into my new empty repository, delete the file, and commit? | 04:20 |
| Rolly | Can I then continue to merge the rest of the revisions in ../source? | 04:20 |
| abentley | Rolly: You need to preserve the file-ids, or else merge won't work. So plain copy or export is not going to do what you want. | 04:21 |
| Rolly | And will that keep the deleted file out of the repo? | 04:21 |
| Rolly | I see | 04:21 |
| Rolly | 'bzr remove-revision' will apparently 'Remove revisions from repository'. Do you think I could use that command to accomplish what I want? | 04:22 |
| abentley | Rolly: I don't know that command. | 04:22 |
| abentley | What plugin does it come from? | 04:23 |
| spiv | If it does do that, then that will accomplish what you want. | 04:23 |
| Rolly | http://people.samba.org/bzr/jelmer/bzr-remove-revisions/trunk | 04:23 |
| Rolly | But how would it fit in to this whole process? | 04:23 |
| abentley | Rolly: Presumably, you could run it after you had generated your revised version of the branch. | 04:24 |
| Rolly | bzr init ; bzr pull -r 1 ../source ; bzr remove-revision -r 1 ; bzr add . ; bzr ci | 04:24 |
| Rolly | something like that? ^ | 04:24 |
| spiv | Rolly: that plugin looks like it needs revids, rather than revnos. | 04:25 |
| spiv | (which makes sense) | 04:25 |
| abentley | Rolly: No, you can't commit when your current revision doesn't exist. | 04:25 |
| abentley | Rolly: You don't need remove-revision. You just need to branch "." | 04:25 |
| spiv | Rolly: so the procedure would be: generate a branch without the offending revision in its ancestry (e.g. with rebase), then generate a repo without that revision (e.g. with remove-revision, or e.g. by making a new standalone branch). | 04:26 |
| Rolly | abentley: Do you mean 'bzr branch ../source/.' ? | 04:26 |
| abentley | Rolly: EMPHATICALLY NO | 04:26 |
| Rolly | :*( | 04:26 |
| Rolly | spiv: the offending revision is revno 1. Is rebase still possible? | 04:27 |
| abentley | I mean "bzr branch . new_version_of_branch_without_offending_revision_in_repo" | 04:27 |
| Rolly | thanks I'm trying that now | 04:28 |
| spiv | Rolly: I haven't used the rebase plugin enough to know. | 04:28 |
| abentley | Rolly: you need to do that after you've committed your alternate revno 1. | 04:29 |
| abentley | Rolly: And probably your alternate revno 2 also. | 04:29 |
| spiv | But it sounds like you want a different first revision, rather than to just remove the first revision? If so, the "init;merge;revert--forget;rm;commit dance" lifeless mentioned sounds reasonable. | 04:29 |
| Rolly | abentleyL I'm really sorry, I don't understand. I just did "cd ../source ; bzr branch . ../new" and it branched all of the revisions | 04:30 |
| abentley | Rolly: The problem is that you did "cd ../source". | 04:30 |
| abentley | Rolly: You have a current directory, containing an alternate revno 1, which does not have config.php. *that* is what you need to branch. | 04:31 |
| abentley | You have not told me the name of that directory, so I'm calling it "." | 04:32 |
| Rolly | Gotcha. And what does "new_version_of_branch_without_offending_revision_in_repo" mean? | 04:32 |
| Rolly | is that the location I'm branching to? | 04:33 |
| abentley | Rolly: Yes. | 04:33 |
| Rolly | Eureka, thanks | 04:33 |
| Rolly | Is the "." somehow special? | 04:34 |
| spiv | No, it's a path like any other. | 04:35 |
| spiv | Well, a path meaning "the current directory", of course. But just a path. | 04:35 |
| Rolly | Thanks spiv/abentley/lifeless. I'll continue tomorrow but I think I know what I'm doing now | 04:35 |
| chrismurf | How can I *permanently* obliterate all records of a file from BZR? | 05:55 |
| chrismurf | I'm trying to move some files from a previous closed SVN repo to an open BZR repository, and would like to maintain what history I can, but delete some files which aren't being opened | 05:56 |
| spm | chrismurf: "A" method that I personally used: http://www.stedee.id.au/2008/11-06/manually_migrating_subversion_repository_launchpadbzr | 06:00 |
| spm | there may be other better ways. YMMV. | 06:00 |
| chrismurf | hmm - doesn't sound like fun, but does sound like exactly what I'm looking for :-) | 06:01 |
| chrismurf | thanks | 06:01 |
| spm | np | 06:01 |
| chrismurf | what's the benefit of faffing about with svndump and svnadmin, rather than just using svn2bzr --exclude? | 06:02 |
| Peng_ | We use bzr-svn instead now, and it can't exclude? :P | 06:02 |
| chrismurf | haha - I see :-) | 06:03 |
| chrismurf | oh yeah - svn2bzr doesn't even exist | 06:03 |
| chrismurf | how about that | 06:03 |
| Peng_ | svn2bzr doesn't exist anymore? | 06:04 |
| chrismurf | well, the repo linked to on the site is down: http://bazaar-vcs.org/svn2bzr | 06:07 |
| chrismurf | but there are branches in LP that I'm looking at. | 06:07 |
| spiv | chrismurf: which repo is that? The links I followed on that page all seem to work. | 06:07 |
| chrismurf | bottom of page | 06:08 |
| chrismurf | "Current development version can be found in" | 06:09 |
| spiv | chrismurf: that link works for me. | 06:09 |
| spiv | chrismurf: | 06:09 |
| spiv | $ bzr log -r -1 --line http://bzr.labix.org/svn2bzr/trunk/ | 06:09 |
| spiv | Format <RepositoryFormatKnit1> for http://bzr.labix.org/svn2bzr/trunk/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance | 06:09 |
| spiv | 13: Gustavo Niemeyer 2008-04-06 Merging changes from James Henstridge branch... | 06:09 |
| chrismurf | oop -I'm being stupid | 06:09 |
| chrismurf | no HTML page, but BZR Repo. | 06:09 |
| chrismurf | thanks | 06:10 |
| === beuno_ is now known as beuno | ||
| chrismurf | Judicious use of svn2bzr is just the ticket. Thanks spm! | 06:26 |
| spm | chrismurf: np. I found that bzr-svn just wouldn't work the way I needed it to. Could have been pebkac. Shrug. I got there in the end. :-) | 06:41 |
| chrismurf | yeah - I'm finding it doesn't quite do what I want either :-/ | 06:41 |
| chrismurf | in particular SVN mv's (of which there were some near the end) are not handled well | 06:42 |
| chrismurf | I think that's a problem on the SVN side, but I'm trying to figure out how to match up the move's manually... | 06:42 |
| chrismurf | sigh. | 06:42 |
| chrismurf | I need a repository editor ;-) | 06:42 |
| chrismurf | little delete here and tweak there.... voila! | 06:42 |
| chrismurf | what could possibly go wrong | 06:43 |
| spm | I vaguely recall it would only process about half of the main repo and then barfed. Hence the switch to svn2bzr, which worked. | 06:43 |
| spm | :-) | 06:43 |
| chrismurf | I tried to include /trunk/foo/bar and exclude everything else, and it barfed until I also included /trunk$ and /trunk/foo$ | 06:43 |
| chrismurf | wasn't smart enough to create dir's | 06:44 |
| spm | heh - try and use svndumpfilter maybe? | 06:44 |
| chrismurf | may just look at the BZR python API and code the transfer by hand. | 06:44 |
| chrismurf | don't know svndumpfilter or particularly want to learn SVN internals :-) | 06:45 |
| chrismurf | or maybe I'll just horribly abuse svn2bzr -- hard to say. I'll come up with something. | 06:46 |
| spm | svndumpfilter is documented enough in the red-bean book (from memory); and the actual dump file is pretty obvious - well I was able to use awk against it :-) | 06:46 |
| chrismurf | anybody know generally how to import "SVN MV" actions to BZR? | 06:51 |
| chrismurf | ie how to convert a "delete, add" to a "rename" | 06:51 |
| lifeless | chrismurf: bzr pull will do that | 06:55 |
| chrismurf | ah - as opposed to bzr co? | 06:55 |
| lifeless | well bzr co svn://foo will do a branch operation, same overall result | 06:56 |
| chrismurf | hm - seemed to not understand mv's somehow... | 06:56 |
| chrismurf | will try again. | 06:56 |
| lifeless | sleeptime for me | 06:56 |
| lifeless | gnight all | 06:56 |
| vila | hi all | 07:32 |
| chrismurf | spm, you there? | 07:43 |
| jelmer | spm, what were you trying to do exactly? | 08:30 |
| jelmer | spm: Importing a svn branch into bzr but ignoring some files from the svn branch in the process? | 08:31 |
| jelmer | lifeless, What should be made a no-brainer? | 08:31 |
| spm | jelmer: hey. 2 things - 1. import trunk, ignore all the tags and branches made; and a series of files that I didn't want/need in bzr & 2. change the 'committer' so LP would register it as me. That 2nd was more of an everest challenge than truly being useful. :-) | 08:33 |
| * igc dinner | 08:34 | |
| jelmer | spm, ah, ok | 08:34 |
| jelmer | spm: That's indeed not possible with bzr-svn | 08:35 |
| jelmer | spm, The idea would be that bzr has some tools to do that sort of thing | 08:35 |
| spm | :-) | 08:35 |
| spm | jelmer: fwiw, I originally worked this out back in July, so reasons for/why etc are a tad vague now. The blog posting was the streamlined version when I redid for another project. | 08:36 |
| spm | "I know this works; I will do it this way" | 08:37 |
| tga | howdy | 08:41 |
| jelmer | spm, ah, thanks | 08:42 |
| jelmer | spm, (just curious, but it's good to know about that use case) | 08:42 |
| spm | jelmer: np, glad to help even in such a small way :-) | 08:42 |
| tga | I'm looking at setting up a central repository for a project and I'm not sure where the files are actually supposed to live | 08:43 |
| tga | the manual says that "central shared branches typically only want to store history, not working copies of files" | 08:43 |
| tga | so where do the files go? | 08:43 |
| bob2 | tga: do you understand the distinction between working copy, repository and branch? | 08:44 |
| tga | not fully, as it's probably evident | 08:44 |
| tga | working copy = actual files I'm working on, checked out from repo | 08:44 |
| spm | tga: they live inside the ... repository, kinda like inside a zip file, to use a really loose analogy. You can extract them in the dir in the cental location, but don't have to. | 08:44 |
| bob2 | repository = bag of revision data | 08:44 |
| bob2 | branch = pointer to one revision (and thus all that revision's ancestors) | 08:45 |
| bob2 | working copy, yeah | 08:45 |
| bob2 | so in a ceentral shared branch dealy, you just have branches and a repository, no working copies | 08:45 |
| tga | so does the repository contain the actual files or just changes? | 08:46 |
| bob2 | the latter, sort of | 08:46 |
| tga | so when I check out a file is recreated by going through all changes? | 08:46 |
| bob2 | conceptually | 08:47 |
| bob2 | in reality it'll probably have a nearby copy cached | 08:47 |
| tga | I see now, so there is no need for a working copy on the repo | 08:47 |
| bob2 | *handwave* | 08:47 |
| spm | tga: exactly | 08:48 |
| tga | alright, thanks, I'm slowly getting to understand what's going on | 08:48 |
| spm | tga: if you have access to 2 machines? create a local repo. add some files, commit, repeat a few times to get some simple history; now 'bzr push' that repo to the 2nd PC via, eg, ssh. You should only have a .bzr in the remote directory. | 08:50 |
| spm | on the 2nd machine; now bzr branch from that .bzr only directory, and behold, all the files re-appear :-) | 08:50 |
| spm | So in your case; that 2nd machine would be the central repo that everyone else could branch from. Clear as mud? | 08:51 |
| tga | why do I need to explicitly create a repo? from what I can see, bzr init on a directory gets me the same thing | 08:51 |
| spm | you don't need to. | 08:52 |
| tga | what do I get by doing it though? | 08:52 |
| spm | ... control over who can commit to trunk | 08:52 |
| bob2 | it is just a storage optimsation | 08:52 |
| bob2 | you only need to store changes shared between related branches once | 08:52 |
| bob2 | rather than for each one | 08:52 |
| bob2 | spm: you sure you need a repository for that? | 08:53 |
| tga | sooo technically I could bzr init on my working dir and copy the .bzr dir to the server? | 08:53 |
| spm | bob2: no - I misunderstood the question - your answer was more correct | 08:53 |
| bob2 | tga: yup | 08:53 |
| tga | that's nice | 08:53 |
| spm | tga: is very nice. we rsync dir's all over the place that way. Even to the prod servers. | 08:54 |
| bob2 | (if you 'bzr init' in a repository, though, you can't - .bzr in the branch doesn't store the "revision data", it just points at the repository's store) | 08:54 |
| tga | just to make sure I'm on the right track here, does this sound alright: bzr init, add, commit on /local/project/src dir, bzr init-repo on empty /server/project, then in /local/project/src, bzr push /server/project/trunk | 08:58 |
| Peng_ | tga: I just walked in on this conversation, but yes, it does. | 09:03 |
| tga | thanks Peng_ | 09:04 |
| * tga is fixing a million "file name too long" errors | 09:04 | |
| Peng_ | tga: (You'd probably want to create a local repo too in /local/project or whatever, if you hadn't already.) | 09:04 |
| tga | why? | 09:04 |
| Peng_ | In case you want multiple branches. | 09:05 |
| tga | oh, I see | 09:05 |
| tga | so I don't duplicate code all over the place? | 09:05 |
| Peng_ | Without a shared repository (bzr init-repo), "bzr branch" will copy the entire repository, which just wastes space. | 09:06 |
| tga | gotcha | 09:07 |
| jonnydee | hi, does anyone know when the bzr-1.10 installer for windows will be released? | 10:36 |
| Peng_ | jonnydee: Posts on the list have said that there are problems with the machine they're built on, so the answer is either "When the people responsible for the machine fix it", or "When someone else manages to go through the complicated build procedure". | 10:49 |
| Peng_ | (Or, "When anybody manages to figure out what's wrong in the first place, and fix it" | 10:49 |
| Peng_ | ) | 10:50 |
| jonnydee | Peng_: thangs for your info :) | 11:36 |
| LarstiQ | moin | 12:05 |
| rocky | is there anyway to merge repos? i need all the history out of one repo to go into another repo | 14:03 |
| awilkins | rocky: You can just branch the branches into the other repo | 14:07 |
| awilkins | Do you mean "can I splice the history of two branches together" though? | 14:07 |
| rocky | no i think your first suggestion is what i need | 14:07 |
| rocky | i have bzr repo X, repo Y ... repo Y has a couple branch histories that i need in repo X, and i need to destroy repo Y | 14:08 |
| awilkins | The converse is also true - you can "split" repos by making new ones and only branching branches with history you wish to keep into them | 14:08 |
| rocky | hm... how do i make eshell display the status bar that comes up on a long bzr checkout? :) | 14:09 |
| vila | rocky: export BZR_PROGRESS_BAR=tty | 14:16 |
| === maxb is now known as Guest97053 | ||
| Peng_ | rocky: Repositories are just big bags of revisions. They don't have to be related at all. | 14:25 |
| === Guest97053 is now known as maxb | ||
| etank | how do i tell bzr to stop watching a file that is already being watched | 14:44 |
| etank | bzr ignore tells me that it is already being watched and will not be ignored | 14:44 |
| awilkins | bzr ignore foo | 14:45 |
| awilkins | bzr rm foo --keep | 14:45 |
| etank | aah | 14:45 |
| etank | --keep | 14:45 |
| etank | cool thanks awilkins | 14:45 |
| awilkins | You're welcome | 14:45 |
| etank | i did a bzr rm and the file went o00f | 14:45 |
| etank | s/o00f/p00f/ | 14:45 |
| awilkins | you could make an alias - "forget = rm --keep" | 14:46 |
| etank | that would work too | 14:46 |
| etank | sweet | 14:46 |
| etank | i should have looked at http://doc.bazaar-vcs.org/bzr.dev/en/quick-reference/quick-start-summary.pdf more closely | 14:49 |
| etank | what i was looking for is right there in the middle :) | 14:49 |
| tga | how can I automatically update a working copy of a branch on the server every time there is a commit? | 15:16 |
| Peng_ | tga: If you're pushing over bzr+ssh or sftp, you can use the bzr-push-and-update plugin. | 15:17 |
| tga | ah, plugin, right | 15:23 |
| marcoil | with bzr-svn 0.5 rc1: "bzr: ERROR: Could not determine revno for {svn-v4:<s3kr3t>:33292} because its ancestry shows a ghost at {<s3kr3t>}". Any idea? | 15:31 |
| marcoil | (when committing, btw) | 15:32 |
| marcoil | the last two days with bzr-svn have been hell, really. I don't know what I did, but it stopped working perfectly as it used to do and it's making me go nuts :( | 15:34 |
| LarstiQ | marcoil: did that timeframe include a move from 0.4 to 0.5 | 16:05 |
| LarstiQ | ? | 16:05 |
| marcoil | yep, it was the only way of getting it to at least work. For one commit :) Then I got that strange message. Sorry, I didn't want to rant... | 16:05 |
| LarstiQ | why did 0.4 not work? | 16:06 |
| marcoil | I added a branch to the svn-branching-scheme and I stated getting lots of error messages | 16:06 |
| marcoil | and couldn't commit | 16:07 |
| bialix | hi, is Marius here? | 16:12 |
| LarstiQ | marcoil: aha | 16:18 |
| bialix_ | I guess no. | 16:23 |
| LarstiQ | marcoil: branching-schemes are a painful area of bzr-svn, so I'm unfortunately not surprised changing it gave some problems | 16:25 |
| LarstiQ | marcoil: as to 0.5, I haven't tried it yet. It's supposed to get rid of branching schemes, but apparently it's not yet ideal either. | 16:25 |
| marcoil | anything that gets rid of the branching schemes is great... Our repo has some really strange scheme | 16:26 |
| lamont | so how do I get bzr visualize (bzr-gtk) in intrepid without getting that bzr-notify crack? | 17:01 |
| jam | lamont: I'm pretty sure the notify stuff is only a "recommends" not a requires | 17:09 |
| jam | I would uninstall bzr-dbus if it lets you easily | 17:09 |
| lamont | bzr-notify is delivered in the bzr-gtk package | 17:09 |
| lamont | which I just removed from my machine as the simplest way to get rid of the totally annoying popup | 17:09 |
| lamont | of course, if there's a way to have it _NOT_START_, that'd let me have bzr visulaize | 17:10 |
| jam | I don't really know enough about it to help | 17:10 |
| jam | I generally run from source | 17:10 |
| lamont | because every commit really wants to interrupt my thought process with a popup telling me that, oh wait: I just committed | 17:10 |
| jam | mkdir -p ~/.bazaar/plugins; cd ~/.bazaar/plugins; bzr co lp:bzr-gtk gtk | 17:11 |
| lamont | ah | 17:11 |
| lamont | yeah - I'm a package kind of guy | 17:11 |
| lamont | and I use bzr when the folks I'm working with want me to use it... otherwise there's this other VCS that I'm still more comfortable with that has all my source in it already... | 17:12 |
| === stoneToad is now known as StoneToad | ||
| StoneToad | lamont: you can tell it to stop running | 17:16 |
| lamont | StoneToad: yeah... it was a "GRRR HOW" kind of moment that I didn't want to bother figuring out | 17:17 |
| * fullermd didn't even know there was a 'notify', and still doesn't know what it does :p | 17:17 | |
| StoneToad | lamont: ah yea, I ran into the instructions somewhere when I was trying to figure out what the hell this icon in my satuts bar was :) | 17:18 |
| StoneToad | try apt-get remove bzr-dbus | 17:20 |
| StoneToad | intrepid pulls in recommends by default now | 17:20 |
| StoneToad | (which is the correct default for debian based systems) | 17:21 |
| StoneToad | if you want to block a recommended package from being installed you can do something like apt-get install packageIwant packageIdontwant- | 17:22 |
| StoneToad | you can also use + appended to the name to make it install that package (handy for forcing an alternative package that provides a dependency) | 17:22 |
| lamont | StoneToad: yeah... apt and I are old friends | 17:23 |
| lamont | and installing recommends? yeah, makes sense for many things, esp when suggests are correctly used | 17:23 |
| StoneToad | ahh how important that "correctly" is :) | 17:24 |
| lamont | verily | 17:25 |
| lamont | esp when many crackheads use Recommends as "I think this'd be cool" | 17:26 |
| onox | I get this error when I try to pull a branch: | 17:26 |
| onox | bzr: ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. | 17:26 |
| onox | anyone know what's wrong? | 17:26 |
| StoneToad | are you in a console? (no X) | 17:27 |
| lifeless | onox: remove the bzr-dbus plugin; there is a bug if you are not in a X session | 17:28 |
| onox | in a gnome-terminal | 17:28 |
| onox | never happened before. Just yesterday with 1.9 and today with 1.9 and 1.10 | 17:33 |
| Tak | I get that sometimes with screen sessions as well | 17:35 |
| Tak | (even in an X session) | 17:35 |
| lifeless | onox: aare you in a screen session that was started from a previous X instance? | 17:36 |
| onox | no | 17:36 |
| onox | it happens when emerge starts to pull in revisions of awn-extras | 17:36 |
| lifeless | emerge is probably isolating itself then | 17:37 |
| lifeless | I'll try and get it ixed today, but its kinda hectic here | 17:37 |
| onox | lifeless: maybe, I do have sandbox and userfetch FEATURES enabled, but it has worked for months this way | 17:38 |
| lifeless | onox: did you dbus version change? they change the exact error-to-catch regularly | 17:40 |
| lifeless | its like whack-a-mole | 17:40 |
| onox | lifeless: nope, only upgraded portage to 2.1.6 on Dec 11 02:13 | 17:41 |
| onox | but it also happens with pkgcore | 17:42 |
| lifeless | onox: so the cause is probbly something adding more sandboxing IMO. | 17:42 |
| lifeless | not the root cause, which is the bug, but the proximate cause | 17:43 |
| onox | I'll try it without sandboxing | 17:43 |
| onox | back in 20 min. | 17:43 |
| lamont | lifeless: all of dbus is whack-a-mole | 18:00 |
| lifeless | abentley1: https://code.edge.launchpad.net/~bzr/bzr-dbus/trunk seems not to be syncing | 18:05 |
| lifeless | abentley1: the webui is showing 37, I see 38 as most recent | 18:05 |
| === poolie1 is now known as poolie | ||
| abentley1 | lifeless: That's how it looks to me, also. | 18:10 |
| === abentley1 is now known as abentley | ||
| lifeless | mthaddon: ping ^ | 18:13 |
| mthaddon | lifeless: let me check if there's a problem with the branch scanner | 18:43 |
| abentley | lifeless: I'm adding the ability to specify a thread to up-thread --auto | 19:22 |
| lifeless | abentley: cool. Do we hwave up-thread --auto? | 19:23 |
| abentley | lifeless: We do. | 19:23 |
| abentley | lifeless: Should up-thread $THREAD imply --auto? | 19:24 |
| abentley | lifeless: The alternative seems to be erroring. | 19:24 |
| lifeless | abentley: yes, I think it should | 19:25 |
| abentley | lifeless: Cool. Will do. | 19:25 |
| lifeless | alternatively | 19:25 |
| lifeless | up-thread is automatic, and --manual is used to go up one-thread manually | 19:26 |
| abentley | Okay, I'll do that. | 19:27 |
| bialix | luks: hi | 19:54 |
| === sabdfl1 is now known as sabdfl | ||
| === asac_ is now known as asac | ||
| abentley | lifeless: --no-auto or --manual? --no-auto is just a change of default, and won't break anyone. | 20:24 |
| lifeless | abentley: no-auto seems ugly to me | 20:24 |
| lifeless | loom is still really beta, I think breaking people is better than ugly | 20:24 |
| abentley | lifeless: Okie. | 20:25 |
| lifeless | --manual isn't perfect either, if you think of a better name, go for it | 20:27 |
| abentley | lifeless: I've pushed the performance enhancements and --manual change into my branch. | 20:48 |
| lifeless | abentley: cool; doubt I can look trivially today, can you drop a merge-request into lp for it ? | 20:49 |
| abentley | lifeless: Sure. | 20:50 |
| jam | lifeless: after today you are gone until January, right? | 21:31 |
| enigma | Question about bzr-svn 0.5 RC1... | 21:38 |
| enigma | It's great that it supports following copies now. Woohoo! | 21:39 |
| enigma | Is the SVN version which made the copy supposed to be showing up in the version history? | 21:39 |
| enigma | Example. | 21:39 |
| enigma | If I have: svn copy http://server/svn/trunk/foobar http://server/svn/branches/newfoo | 21:40 |
| enigma | Then, if I do a bzr branch on each of those URLs. | 21:40 |
| enigma | I don't get the same history. | 21:40 |
| enigma | The history for the copy has an extra revision in it: the revision that made the copy. | 21:41 |
| jelmer | enigma: Yes, that's correct | 21:41 |
| enigma | So I can't merge between the branches. | 21:41 |
| enigma | Which seems a little strange to me since in bzr when I make a branch, the history is identical. | 21:41 |
| jelmer | enigma, You can merge between the two, they share the same ancestry | 21:41 |
| enigma | Oh...you're right...my mistake...I was trying to "pull" | 21:41 |
| enigma | I can't pull from the "trunk" to the "branch" | 21:42 |
| enigma | Since the trunk is missing a revision. | 21:42 |
| enigma | I'm just trying to understand if that's the intended behavior. | 21:42 |
| jelmer | yeah, that sounds right | 21:42 |
| jelmer | the same thing would happen if you had two bzr branches, one of which was one revision ahead of the other | 21:42 |
| enigma | So I should be using "merge" instead of "push" and "pull"? | 21:42 |
| enigma | Yeah, that's what's messing me up. | 21:43 |
| enigma | In SVN, they are identical. | 21:43 |
| enigma | Intuatively, I expect the rev that made the branch to not count as a revision from bzr's point of view. | 21:43 |
| jam | enigma: well, why have a separate branches if you are going to push&pull between them to keep them as identical mirrors? | 21:43 |
| enigma | Just like making a new branch in bzr doesn't create a revision. | 21:43 |
| jelmer | enigma, they have the same contents in svn | 21:43 |
| jelmer | enigma, but they have a differen thistory in svn too | 21:44 |
| jam | enigma: but it does in svn | 21:44 |
| jelmer | enigma, try running "svn log" on both | 21:44 |
| jam | IIRC you have to commit the new branch | 21:44 |
| jelmer | enigma, creating a new branch in svn means doing a "pointless" commit | 21:44 |
| enigma | jelmer: We have a "business requirement" to use SVN. | 21:44 |
| enigma | And that "business requirement" mandates a layout. | 21:44 |
| enigma | So, there are some branches in two parts of the tree that are simply clones of each other. | 21:45 |
| jam | enigma: interesting. Though I would still say "merging things into trunk" rather than push&pull is a better way to work | 21:45 |
| jam | If only for the joy it gives "bzr log --short" | 21:45 |
| jelmer | enigma, sure, I don't see what the problem is with that pointless commit in either svn or bzr | 21:46 |
| jam | enigma: so after creating the new branch, can you push that back into trunk? | 21:46 |
| enigma | One thing we've done before is a: bzr push --overwrite http://sever/svn/branches/newbranch | 21:46 |
| enigma | jam: let me try | 21:47 |
| jam | It seems like it would be a bit weird for svn to support that | 21:47 |
| jam | since it versions everything in the same namespace | 21:47 |
| jelmer | it does support it | 21:47 |
| enigma | Then I can push and pull between the two...which is REALLY COOL! :-D | 21:47 |
| enigma | So I was expecting to be able to do that between branches in SVN with 0.5...but I can't because of the extra "pointless commit" which made the branch. | 21:48 |
| jelmer | jam, It removes the old branch with the same name and creates a new one with the same name | 21:48 |
| enigma | jam: and it pushes the whole revision history with it. :-D | 21:48 |
| jelmer | enigma, only in 0.4 | 21:49 |
| jelmer | because you had two branch paths with different branching schemes | 21:49 |
| enigma | Oh...OK. | 21:49 |
| jelmer | it should no longer do that in 0.5 | 21:49 |
| jelmer | enigma, you should be able to get around the pointless commit by using merge or rebase | 21:49 |
| enigma | OK...that's good to know. | 21:49 |
| enigma | I can rebase an SVN branch? | 21:50 |
| jelmer | well, you can rebase your local bzr branch before you push it to svn | 21:50 |
| enigma | Oh, I see...but then I can't push it back to the original, right? | 21:50 |
| jelmer | enigma, right | 21:50 |
| enigma | Is there anyway to "hide" or "ignore" the pointless commit and not have it considered part of the branches history? | 21:51 |
| enigma | Since it really is meaningless from bzr's point of view? | 21:51 |
| jelmer | enigma, you can set the bzr:hidden revision property on the pointless commit | 21:51 |
| jelmer | that will make bzr-svn ignore it | 21:51 |
| enigma | Yeah!? Is "bzr:hidden" in the docs? | 21:52 |
| enigma | It's new to me. | 21:52 |
| jelmer | enigma, no, it's not in the docs | 21:52 |
| enigma | How do I use it? | 21:52 |
| jelmer | it's an experimental new feature | 21:52 |
| enigma | OK, and it's part of 0.5 RC1? | 21:53 |
| enigma | How do I use it? | 21:53 |
| jelmer | it's not actually intended to be set by users | 21:53 |
| jelmer | but you can, if you insist | 21:53 |
| enigma | >:-) | 21:53 |
| jelmer | set "bzr:hidden" to "" | 21:54 |
| jelmer | and "bzr:root" to the branch path on which you made the commit, with all leading and traling slashes trimmed | 21:54 |
| jelmer | you will have to remove your bzr-svn cache if you do this, since bzr-svn normally sets this during commit | 21:55 |
| jelmer | and you will have to make sure everybody else who is using that repository removes their bzr-svn cache as well | 21:55 |
| enigma | Where is that property set? | 21:56 |
| jelmer | you can set it with "svn propset --revision ... | 21:56 |
| enigma | SVN let's you set properties on revisions? Really? (I never knew...) | 21:57 |
| enigma | OK. I'll give that a go | 21:57 |
| jelmer | enigma, not out of the box | 21:57 |
| jelmer | enigma, you have to enable the right revision property hook | 21:58 |
| enigma | Oh, OK. I'll check and see if that's setup for our repo. | 21:58 |
| enigma | Thanks again for all your help! | 21:58 |
| enigma | bzr-svn is fantastic! I've been really impressed. | 21:58 |
| jelmer | thanks | 21:59 |
| jelmer | enigma: btw, you will have to remove your existing bzr branches if they were created using bzr-svn already contain any revisions on which you're setting these svn properties | 22:00 |
| enigma | OK...that's good to know too. Thanks. | 22:01 |
| LarstiQ | heya poolie, sabdfl | 22:28 |
| sabdfl | howdy LarstiQ | 22:28 |
| poolie | hello LarstiQ | 22:30 |
| === mtaylor_ is now known as mtaylor | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!