| lifeless | reconcile in pack form | 00:00 |
|---|---|---|
| lifeless | the instructions are over cautious | 00:00 |
| jelmer | lifeless: Notes when upgrading in 1.0rc1 says to reconcile before upgrade. | 00:06 |
| lifeless | 11:00 < lifeless> the instructions are over cautious | 00:06 |
| jelmer | ah | 00:07 |
| jelmer | sorry | 00:07 |
| lifeless | but use 1.0 | 00:07 |
| lifeless | not an rc :) | 00:07 |
| fullermd | At least for a few hours yet, don't use a rc ;) | 00:08 |
| mathrick | is bzr-git supposed to be able to check out git branches (as in, remote ones)? | 00:19 |
| mathrick | or does it only work with a pre-existing working tree or something? | 00:20 |
| mathrick | meh, neither seems to work at all | 00:24 |
| lifeless | bzr-git is not ready for that yet | 00:40 |
| mathrick | yeah, I can see that | 00:41 |
| mathrick | does pack-0.92 support nested trees? | 00:46 |
| jelmer | mathrick: no | 00:48 |
| mathrick | aha, so dirstate-with-tags is the best bet now? | 00:48 |
| jelmer | dirstate-with-tags doesn't support nested trees either | 00:49 |
| mathrick | rich-root-pack yelled at me it doesn't support nested trees either | 00:49 |
| mathrick | jelmer: well, I have a bzr-svn repo in that format | 00:49 |
| jelmer | that must be dirstate-with-subtree | 00:49 |
| mathrick | with a merged-into tree... | 00:49 |
| jelmer | not dirstate-with-tags | 00:49 |
| tonyyarusso | Hi folks, I'm afraid I don't entirely understand how bzr works (or any versioning thing for that matter), but want to check it out. Do I need anything more than a web host that supports Python scripts? | 00:49 |
| mathrick | jelmer: oh, I probably meant that, yeah | 00:49 |
| mathrick | jelmer: in any case, I saw your mail where you say you're replacing all references with rich-root-pack, but it explicitly said it doesn't support nested trees here | 00:50 |
| mathrick | tonyyarusso: you don't need any web host (or python scripts there for that matter) | 00:50 |
| mathrick | web only comes into play if you want to share your repos publically | 00:51 |
| jelmer | mathrick: bzr-svn doesn't need nested trees | 00:51 |
| mathrick | jelmer: aha, I remebered from somewhere that it did | 00:51 |
| mathrick | I wonder why | 00:51 |
| jelmer | mathrick: however, you can't downgrade a branch to a format with less features, even though you don't use those features at the moment. | 00:51 |
| mathrick | jelmer: oh, but I do use nested trees (I believe, unless merge-into doesn't actually use them) | 00:52 |
| tonyyarusso | mathrick: I was hoping to have things accessible from multiple locations (I'm looking for a way to get at my files from various computers - and I have DreamHost space) | 00:52 |
| mathrick | tonyyarusso: then all you really need for bzr is ssh access for writing and http access for reading | 00:52 |
| tonyyarusso | mathrick: So is there nothing server-side about it at all other than the storage space? | 00:52 |
| mathrick | pretty much yeah | 00:53 |
| tonyyarusso | cool | 00:53 |
| jelmer | mathrick: merge-into doesn't use nested trees afaik | 00:53 |
| mathrick | you can use smart server if you can run it on the remote side, but it's entirely optional (and wouldn't probably improve your life significantly, as you're likely to have rather limited needs at first) | 00:53 |
| mathrick | jelmer: I see | 00:53 |
| tonyyarusso | Next question: is there a way to integrate bzr with nautilus, so the actual bzr processes would be transparent when accessed from a gnome desktop? (although olive isn't too hard to use either, just another step though) | 00:54 |
| jelmer | tonyyarusso: There is nautilus-bzr, but it's less maintained than olive | 00:54 |
| mathrick | tonyyarusso: I don't think I understand the "transparent bzr process" thing, but there was something like that, yes | 00:54 |
| tonyyarusso | jelmer: ah | 00:55 |
| * tonyyarusso shall go experiment | 00:55 | |
| mathrick | tonyyarusso: I never really believed in file-manager + VCS integration | 00:56 |
| foom | mathrick: it's really good for the less-technical users who also have to use the VC system. | 00:58 |
| * tonyyarusso is technical enough, just lazy ;) | 00:58 | |
| mathrick | foom: perhaps, but I can't help but feel the impending abstraction leak | 00:59 |
| lifeless | mathrick: there is pack-0.92-subtree | 01:01 |
| mathrick | ah, upgrade --help doesn't list the -subtree variants at all | 01:03 |
| foom | mathrick: they're hidden so that you won't use them. ;p | 01:03 |
| mathrick | why not? | 01:03 |
| mathrick | I clearly need them | 01:03 |
| mathrick | oh, because of the cannot downgrade thing? | 01:04 |
| lifeless | yes | 01:05 |
| mathrick | hmm, upgrading to both pack-0.92 and pack0.92-subtree, I get: | 01:15 |
| mathrick | bzr: ERROR: Directory not empty: "/home/mathrick/Dev/rails/bzr-pokerolymp2/.bzr/repository": [Errno 39] Directory not empty | 01:15 |
| fullermd | I wish we had a progress bar for that inventory building or whatever it is check does while it says it's checking versionedfile 0/xxx... | 01:29 |
| mathrick | I've noticed quite a few places where I think bzr used to have progressbars but lost them in 0.9x+ | 01:30 |
| jelmer | mathrick: in 0.9x specifically or in the new formats? | 01:33 |
| mathrick | jelmer: I'm not sure, I just know it happened around 0.9x | 01:33 |
| mathrick | okay, I need to sleep | 01:39 |
| mathrick | night | 01:39 |
| lifeless | mathrick: file a bug on the upgrade error please | 01:42 |
| lifeless | abentley: ping | 01:49 |
| * igc lunch | 02:02 | |
| abentley | lifeless: pong | 03:05 |
| abentley | poolie: have I missed the window yet? | 03:09 |
| spiv | abentley: I don't think so, I think he was intending to make the tarball about an hour from now. | 03:11 |
| igc | abentley: well to check in an hour or so if we're ready to go | 03:12 |
| igc | if you get stuff into the pqm queue, poolie will most likely wait for it to merge (I'm guessing) | 03:13 |
| abentley | Okay, I'm landing the InterDifferingSerializer, because that was a slam dunk. | 03:16 |
| abentley | Thanks everyone for the reviewz | 03:17 |
| spiv | abentley: thanks for the codez! :) | 03:20 |
| lifeless | thumper: I will be a little late, trying to get phone fixed.. | 03:29 |
| abentley | fullermd, CardinalFang: You can find the least common ancestor with "bzr find-merge-base". I don't know what the greatest would be. Presumably revno 0. You can also find this revision with bzr log BRANCHA -rancestor:BRANCHB --show-ids. | 05:11 |
| fullermd | Ooh, I forgot about ancestor:. Didn't know about find-merge-base. | 05:13 |
| lifeless | abentley: I'm trying to remember the rules for inventories and revisions | 05:13 |
| abentley | lifeless: Oh? | 05:13 |
| lifeless | abentley: like, which inventories have a revision, and what the rules are for it, is it always the creating commit etc | 05:13 |
| lifeless | for my new [de]serialiser | 05:14 |
| abentley | All inventories have revision-ids that match the revision that created them. | 05:14 |
| abentley | There were some format 5 inventories that didn't have them. | 05:14 |
| abentley | Basically there were two format 5's, one with no revision-id, and one with a revision id. | 05:15 |
| abentley | But format 6 and 7 always have them, and so should new format 5 inventories. | 05:15 |
| abentley | fullermd: find-merge-base is hidden, because I figured its only use was for debugging. | 05:17 |
| abentley | I'm thinking it might be nice to have a "revision-id" command, though. | 05:17 |
| abentley | that just prints the revision id for the revision you specify with a revision spec. | 05:18 |
| lifeless | revision-info does that | 05:18 |
| fullermd | Well, that would be revision-info | awk :) | 05:18 |
| abentley | lifeless: Perhaps it shouldn't be hidden. | 05:20 |
| lifeless | I think hidden is too big a hammer | 05:20 |
| lifeless | we kind of want degrees of usefulness ;) | 05:20 |
| abentley | mathrick: If you want a branch with a set of working files, that's called a tree. Use bzr reconfigure --tree if you want that. | 05:22 |
| abentley | lifeless: Splitting up commands by topic or tag or something would be fine with me. | 05:32 |
| abentley | lifeless: was there anything else you wanted to ask me? | 05:50 |
| lifeless | abentley: nope | 06:36 |
| mathrick | abentley: but a tree is a set of branches that don't have a hierarchical relationship, no? | 08:29 |
| mathrick | mathrick@hatsumi:~/.bazaar/plugins/bisect$ bzr nick http://bzr.licquia.org/bzr-bisect/trunk/ | 08:41 |
| mathrick | bzr: ERROR: Cannot lock LockDir(http://bzr.licquia.org/bzr-bisect/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() | 08:41 |
| mathrick | isn't that a bug? Reading the nick should be well doable | 08:41 |
| === doko_ is now known as doko | ||
| wam | mathrick: the repository is locked. If there is currently an action, this is ok. If there isn't this could be a stale lock and should be removed. | 08:44 |
| mathrick | wam: uhm, it's over HTTP, the error says something different | 08:44 |
| mathrick | it's not complaining about stale locks, and I can branch it just fine, it's trying to lock the dir (which fails over HTTP, obviously) for reading the nick | 08:45 |
| wam | mathrick: sorry - didn't read carefully enough | 08:45 |
| fullermd | I imagine it's more that nobody ever thought of it. | 08:55 |
| mathrick | fullermd: thought of what? | 08:59 |
| fullermd | Making nick try readonly when it's not writing. | 09:02 |
| mathrick | oooh, I get it now | 09:21 |
| mathrick | bzr nick http://bzr.licquia.org/bzr-bisect/trunk/ sets the nickname to "http://bzr.licquia.org/bzr-bisect/trunk/" | 09:21 |
| mathrick | and I was in a checkout directory | 09:21 |
| mathrick | so there's no way to get a nickname of a remote branch | 09:22 |
| ubotu | New bug: #180297 in bzr "no way to read the nick of a remote branch" [Undecided,New] https://launchpad.net/bugs/180297 | 09:35 |
| mathrick | is there an easy way to rewrite the authorship of committed revisions? | 10:44 |
| mathrick | ie. I didn't have whoami set properly, now I do | 10:44 |
| mathrick | and I'd like to have the previous commits to show the proper info | 10:45 |
| Peng | mathrick: I don't think so. | 10:46 |
| mwhudson | no, revisions are immutable | 10:48 |
| mathrick | meh | 10:49 |
| mathrick | I wouldn't mind getting a new repo, it's not shared with anything | 10:49 |
| Peng | mathrick: Ok, but I still don't know of a tool to do it. | 10:54 |
| zekel | I want to make a branch from a subdirectory in my repo so that it is it's own repo, which I can commit to separately, from which I can merge changes back into the main repo. Help me with the bzr vocab so I can know which method to look up? | 10:55 |
| mwhudson | mathrick: it's probably _fairly_ simple bzrlib programming then | 10:56 |
| mwhudson | maybe you could trick the rebase plugin into doing it | 10:56 |
| zekel | Coming from svn, I could check out any dir in the working tree and not have to carry around a whole repos worth of files. I'm getting confused about checking out versus branching versus I don't know what. | 10:56 |
| mwhudson | zekel: bazaar doesn't version trees in the same way svn does | 10:57 |
| zekel | That doesn't mean I can't split a subdir and work on it separately, does it? | 10:57 |
| Peng | zekel: If you really want to turn it into a separate branch which can still be merged back, this is what subtrees do. The feature has been there for a while now but it still experimental or something. | 10:58 |
| Peng | zekel: But that's a lot more than just checking out a subdirectory. | 10:58 |
| zekel | That's not the same as bzr split? | 11:02 |
| Peng | zekel: Huh. split only requires formats supporting rich roots (metadata about the root directory of the branch), but join requires subtrees. | 11:05 |
| zekel | Peng: I'm not sure I get the implication. | 11:07 |
| zekel | Also, would the split directory, since it's no longer a part of the main tree typically be moved out to be it's own tree, or should it stay there and somehow be treated differently? | 11:08 |
| Peng | zekel: I dunno. | 11:08 |
| Peng | zekel: You should only do this if you think the directory should logically be a separate branch, not just to save disk space. | 11:09 |
| zekel | Peng: It's not really to save disk space, it's more for path concerns. For example, if you have repo/work/bzr.com I might want to just get bzr.com and move that to my web server directory without it being really long. | 11:10 |
| zekel | I tend to nest stuff, but that was with the expectation I wouldn't always have to use the full paths. | 11:11 |
| * Peng shrugs. | 11:12 | |
| zekel | Maybe I should just have a separate repo for each project. | 11:12 |
| zekel | Thanks for the advice. EST calls. | 11:13 |
| === mrevell_ is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| ecognito | Is it possible to do some sort of preview of what files will be effected by a pull operation? | 12:09 |
| mwhudson | not yet; there's been talk of it | 12:10 |
| ecognito | Thanks. | 12:10 |
| Peng | Something with bzr missing? | 12:23 |
| === cprov-away is now known as cprov-out | ||
| === cprov-out is now known as cprov | ||
| CardinalFang | Moin. | 13:18 |
| === mvo_ is now known as mvo | ||
| mathrick | mwhudson: doesn't missing do the trick? | 13:43 |
| === weigon_ is now known as weigon | ||
| mwhudson | mathrick: doesn't tell you which files will be affected does it? | 14:39 |
| mwhudson | or maybe missing -v does that | 14:39 |
| CardinalFang | Hi all. I'm most of the way through my greatest("/latest")-common-ancestor plugin. I have the intersection of changeset ids of two trees, but it's a set, and so no order. How can I tell what is latest? The "-CA" part works, but I need a cmp() to find the "G-". | 15:59 |
| mathrick | CardinalFang: did you take a look at how merge does that? | 16:05 |
| CardinalFang | mathrick, Eh, I thought so. I'll look again. | 16:05 |
| CardinalFang | I hope I'm not reinventing the wheel. | 16:05 |
| mathrick | CardinalFang: don't worry, I had the same feeling when replacing diff_cmd_helper recently :) | 16:07 |
| * CardinalFang risks tearing a rip in space by putting his plugin in revision control. | 16:11 | |
| mathrick | heh | 16:11 |
| mathrick | CardinalFang: if that worked, bzr would've destroyed the universe long ago :) | 16:11 |
| mwhudson | CardinalFang: uh, what are you trying to do? | 16:14 |
| mwhudson | it sounds much like you could use 'bzr revno -r ancestor:../other' | 16:14 |
| dato | mwhudson: revno doesn't seem to accept -r | 16:16 |
| PainBank | can someone help me out? | 16:16 |
| mwhudson | ah, maybe i meant revision-info then | 16:16 |
| dato | ooh | 16:17 |
| PainBank | I uploaded a small program to test out the ability to use bzr to share code from ftp site... and was wonding if someone can try to download the code? | 16:17 |
| PainBank | and let me know if it works or not. | 16:17 |
| PainBank | c# program, simple random number generator upon a button click... or at least let me know if you see the code or not. | 16:17 |
| PainBank | here is the address: | 16:18 |
| PainBank | http://www.detroitcreativetalent.com/SSD/RandomGen/ | 16:18 |
| PainBank | with the .bzr folder in it. | 16:18 |
| dato | PainBank: http://www.detroitcreativetalent.com/SSD/RandomGen/.bzr/branch-format gives a 500 error | 16:20 |
| === AnMaster_ is now known as AnMaster | ||
| CardinalFang | mwhudson, Ooo. After a simple test, that looks like what I want. I wish it were easier to use. cd X; bzr branch ../Y -r `bzr revision-info -r ancestor:../Y |awk '{ print $2 }'` ../XY-gca I can add something to make it smaller, I think. | 16:23 |
| mwhudson | CardinalFang: sure | 16:24 |
| mwhudson | CardinalFang: basically you want the code behind the "ancestor:../some-branch" revisionspec | 16:24 |
| CardinalFang | Agreed. Looking now. | 16:25 |
| mwhudson | CardinalFang: which you definitely don't want to re-implement, it's pretty hard core | 16:25 |
| CardinalFang | I bet. | 16:25 |
| PainBank | @dato Thanks. Looks like it is a server side problem... or I didn't set something up there correctly. Will try later. | 16:32 |
| === AnMaster_ is now known as AnMaster | ||
| * CardinalFang curses Python. | 17:13 | |
| * Peng gasps. | 17:14 | |
| CardinalFang | Leakage of the iter name in a list comprehension strikes again. | 17:18 |
| Peng | Oh. | 17:25 |
| Peng | I think generator expressions are different. :D | 17:25 |
| CardinalFang | Yah. WTF, "str object not callable?" ...20 minutes... Oh, my superclass defines a function that I clobber from within a list comp. | 17:26 |
| CardinalFang | I did consider "list(yay generator expression)" | 17:27 |
| Peng | In Py3k, listcomps will (mostly?) be syntactic sugar for exactly that. | 17:28 |
| CardinalFang | I'm actually looking forward to Py3k now, instead of the grim future of retreating into the wilderness after spraypainting on my house a screed containing something about "map" and "cold, dead fingers." | 17:34 |
| * CardinalFang reluctantly lets apply() and reduce() go. | 17:35 | |
| dlee | Random minore observation re: an earlier discussion about wanting bzr progress bars: I am a blind programmer, and text progress bars tend to cuase LOTS of extra speech besides just letting me know what's happening. I sometimes mildly wish there was an option to turn those off without turning off other status announcements. | 17:45 |
| CardinalFang | That shouldn't be too hard. | 17:47 |
| beuno | dlee, have you used Launchpad before? | 17:52 |
| dlee | no | 17:52 |
| beuno | if not, I can file a bug for you | 17:52 |
| beuno | to request that option :D | 17:52 |
| dlee | I'm sure I can, but I haven't gotten to it. | 17:53 |
| beuno | dlee, https://bugs.launchpad.net/bzr/+filebug | 17:53 |
| beuno | you will need an account first though | 17:54 |
| beuno | if it gets too complicated, just give me some specifics and I'll file it for you | 17:54 |
| beuno | if you do get a Launchpad account, you can subscribe to the bug and follow it's progress, so I do recommend that | 17:54 |
| dlee | I'm actually on the road from Illinois to Virginia atm, ircing via a Virginia FreeBSDD box running IRC; pardon a likely lot of spotty aircard access :) | 17:54 |
| CardinalFang | dlee, What shell do you use? Perhaps a quick fix: alias bzr="TERM=dumb bzr" | 17:54 |
| CardinalFang | dlee, Ah! Even better: in your shell, export BZR_PROGRESS_BAR="" | 17:55 |
| beuno | dlee, ah, I see, I'll file it for you. You would just like an option for the progress bar to be removed? | 17:55 |
| dlee | CardinalFang: Intriguing idea. I use tcsh mostly under FreeBSD and under Cygwin, and I and some officemates will run bzr from DOS boxes directly in Windows as well. | 17:56 |
| dlee | CF: If there's already an envvar for this, I doubt we need an option for it too :) | 17:57 |
| beuno | is there an ennvar for this? | 17:57 |
| CardinalFang | bzrlib.progress looks for that environment variable. | 17:57 |
| dlee | cool | 17:58 |
| beuno | there ya' go, even better. It seems it's just a documentation problem | 17:58 |
| CardinalFang | all, Is there a reason why "branch" doesn't set the default location for future pulls and pushes? | 18:00 |
| dato | CardinalFang: it does for future *pulls* | 18:01 |
| dlee | Now for a perhaps bigger issue: The following just occurred when I tried to cvs-import my second project. The first line is my command (with paths generalized as will be obvious), then follows the output: | 18:06 |
| dlee | [] | 18:07 |
| dlee | bzr cvsps-import /<CVSRootPath> company/proj proj | 18:07 |
| dlee | Creating cvsps dump file: proj/staging/company_proj.dump | 18:07 |
| dlee | Read 306 patchsets (string cache hits: 0, total: 525) | 18:07 |
| dlee | Failed while processing: Patchset(17, HEAD, dlee, 2004/01/16 17:09:27) | 18:07 |
| dlee | Processed 17 patches (17 new, 0 existing) on 1 branches (1 tags) in 8.4s (2.03 patch/s) | 18:07 |
| dlee | bzr: ERROR: rrno 2] No such file or directory: '/home/Doug/proj/bzr/company/proj/tags/projcom_rel040116 **FUNKY**' | 18:07 |
| dlee | This is under Cygwin, so my first suspect is file name casing issues :P This crash leaves a .cvsps dir behind that must be deleted manually, or the next attempt will quickly die with a "not found in cache" error (that I can repro if necessary). | 18:11 |
| beuno | I can't find Feisty's .deb for 1.0 in: http://bazaar-vcs.org/releases/debs/feisty/ am I looking in the wrong place? | 18:12 |
| dlee | The tag directory complained of, though, really does not exist at this point in the process. | 18:16 |
| CardinalFang | Is it possible to set the parent branch without pulling or pushing? | 18:17 |
| Peng | CardinalFang: Edit .bzr/branch/parent or .bzr/branch/branch.conf, depending on your branch format. | 18:18 |
| CardinalFang | :\ | 18:19 |
| Peng | CardinalFang: If it's .bzr/branch/parent, you probably need to be wary of putting a \n at the end of the file. | 18:20 |
| * CardinalFang horks. | 18:21 | |
| dlee | Where should I file a bug on this? | 18:22 |
| dlee | Cancel; found it (was looking for cvsps, not just cvs); getting LP account... | 18:30 |
| dlee | Bug 180408 | 18:55 |
| ubotu | Launchpad bug 180408 in bzr-cvsps-import "["funky" crash on some Cygwin imports" [Undecided,New] https://launchpad.net/bugs/180408 | 18:55 |
| ubotu | New bug: #180408 in bzr-cvsps-import "["funky" crash on some Cygwin imports" [Undecided,New] https://launchpad.net/bugs/180408 | 18:55 |
| dlee | lol I thought I waited long enough | 18:55 |
| radix | :) | 18:56 |
| Peng | Bah, I make the most trivial commit ever, and pushing it creates a 2.4 MB pack because the remote repo is old. | 19:31 |
| fullermd | See, if you'd just made a 200 meg commit instead, you wouldn't notice these problems :p | 19:32 |
| Odd_Bloke | That's why I keep an Ubuntu ISO in all of my repos. :p | 19:33 |
| beuno | we should have a plugin for downloading the ISO when doing "bzr init" | 19:33 |
| Odd_Bloke | Perhaps we should just ship it with bzr itself, to save on bandwidth. | 19:34 |
| beuno | the bundlebuggy merge request will be fun to watch | 19:35 |
| fullermd | Yeah, you WONDERED why there was so much effort spent on repo formats that handled large commits well... now you know! | 19:40 |
| Peng | "[MERGE][trivial] Distribute Ubuntu 7.10 with Bazaar" | 19:42 |
| Peng | fullermd: I have made a couple 6 MB commits. The 120 MB autopacks over SFTP are nice... | 19:43 |
| Odd_Bloke | Heh, imagine the Bundle Buggy merge request when the next version is released. :p | 19:44 |
| Peng | Hey, hold on, I do have that ISO. | 19:44 |
| Peng | Only 2 gigs of RAM though. | 19:44 |
| Peng | Someone on a supercomputer should try it with the DVD ISO. :) | 19:47 |
| fullermd | % bzr upgrade --7.10 | 19:47 |
| beuno | I think using the Ubuntu ISO is a bit biased, we should probably have a mix of all the major distros | 19:48 |
| elmo | Peng: you'd need to distribute the source to comply with the GPL too, don't forget | 19:48 |
| elmo | ;-) | 19:49 |
| fullermd | If we could just rewrite ubuntu in python, it could ship as a plugin... | 19:49 |
| * Peng wanders off. | 19:51 | |
| mathrick | elmo: good thing bzr is a VCS then | 19:52 |
| === cprov is now known as cprov-away | ||
| jel | guys... I need to setup a pre-commit hook to update a file in my app with the version number. The docs seem to suggest putting this in the user's config directory, but I only want this one project to do it? | 22:18 |
| jel | Basically I want to dump a python version-info file in the pre-commit of one project. | 22:23 |
| CardinalFang | pre-commit hooks must not update the tree delta or future tree. I just read that. In big letters and everything. | 22:24 |
| CardinalFang | http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks | 22:25 |
| CardinalFang | jel, maybe you could make a new command that updates and then calls "commit". | 22:26 |
| jel | CardinalFang: I guess the most obvious method will be to just create a directory of helper scripts, one of which is commit. I was hoping for something more integrated -- I still miss the simplicity of rcs's $Id$ :D | 22:27 |
| CardinalFang | $Log$ was nice too. | 22:28 |
| fullermd | Ugh, $Log$ was teh efil. | 22:29 |
| fullermd | I have $Header$'s all over my files, though. | 22:29 |
| jel | Yeah, I liked log as well. No problem, at the end of a file. | 22:31 |
| db-keen | Why doesn't the apt repository for bazaar include the latest versions of some programs? | 22:45 |
| db-keen | like bzr-svn and bzr-rebase | 22:45 |
| CardinalFang | Which APT repo is that, db-keen? | 22:46 |
| db-keen | CardinalFang: http://bazaar-vcs.org/releases/debs/gutsy/ | 22:47 |
| db-keen | it includes Bazaar 1.0, but the version of bzr-svn it includes doesn't work with bzr 1.0 | 22:47 |
| db-keen | only the latest version does, which is available as a .deb package | 22:48 |
| db-keen | http://samba.org/~jelmer/debian/ | 22:48 |
| abentley | CardinalFang: Also, I tried to tell you yesterday that there's already find-merge-base. But you left like a minute before I could tell you. | 22:52 |
| db-keen | bzr-gtk (olive) is another significant package which is behind | 23:08 |
| gryc | is there any way to get a list of all contributors in a bzr branch? | 23:21 |
| beuno | gryc, bzr log and grepping through the output comes to mind | 23:22 |
| gryc | ah, good idea | 23:23 |
| beuno | or even using annotate to know how many lines each person contributed | 23:23 |
| gryc | I thought about using annotate, but I'd need some esoteric `find` that ignores .bzr and such | 23:23 |
| beuno | gryc, someone made something like that for bzr a while ago, let me check the archive to see if he made the script available | 23:24 |
| gryc | okay, thanks | 23:24 |
| beuno | gryc, seems like he didn't provide it, no | 23:27 |
| beuno | http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/31364/match=albisetti | 23:27 |
| gryc | hrm, well thanks anyway | 23:28 |
| beuno | welcome' | 23:31 |
| luks | gryc: https://launchpad.net/bzr-stats | 23:38 |
| CardinalFang | Hmm. So, what's the oh-crap-I-didn't-want-to-pull-that-much command. Remove the last N changesets? | 23:39 |
| luks | CardinalFang: uncommit | 23:39 |
| CardinalFang | and then "bzr revert"? | 23:40 |
| luks | yes | 23:41 |
| CardinalFang | I thought I remembered reading about a range to "merge", backwards. Am I nuts (about that). | 23:42 |
| CardinalFang | ? | 23:43 |
| beuno | CardinalFang, bzr revert -r X | 23:43 |
| beuno | reverts to that specific revision | 23:43 |
| luks | CardinalFang: merge backwards with revert a some changes (which means adds a new revision) | 23:44 |
| luks | er, s/with/will/ | 23:44 |
| CardinalFang | Eww. | 23:45 |
| CardinalFang | Thanks. | 23:45 |
| gryc | luks: thanks for that link to bzr-stats :D | 23:50 |
| CardinalFang | Final question for today: Suppose I work on a part of code for several days. I commit at several intervals because I want the benefits of SCM. Suppose I want to make that into one logical changeset before pushing, because my changes are really one unit of stuff, and my intermediate steps are frankly embarrassing. Is that possible? My current tool has that, but I haven't seen that for Bazaar yet. | 23:50 |
| luks | those intermediate steps are part of the history | 23:52 |
| CardinalFang | bzr collapse -r ancestor:parent -> like revert and then commit, i suppose. Hmm. | 23:52 |
| luks | hm, bzr collapse? | 23:52 |
| CardinalFang | Something I'm making up right now. | 23:52 |
| fullermd | Closest would just be doing a diff of all of them together and patch a fresh tree. | 23:53 |
| luks | you can simply make a new branch, bzr merge -r X..Y and commit | 23:53 |
| foom | what i'd like, which no tool has today, is the ability to *keep* that history for myself, but to collapse it for the consumption of others, and yet have merges know that they're the same thing. | 23:53 |
| fullermd | You'd probably want to do a revert --forget-merges in the middle there. | 23:54 |
| CardinalFang | Yeah. And the commit messages are lost with "bzr revert" also. :( | 23:54 |
| luks | bzr revert reverts only the working tree, no revisions | 23:54 |
| fullermd | revert --forget-merges doesn't touch the working tree, it just drops the pending merge revs. | 23:55 |
| CardinalFang | I'm not really trying to hide anything. I just want it one logical unit. "changeset 47" is my work for that week. | 23:55 |
| fullermd | You could also just uncommit back and then recommit the real changes. | 23:55 |
| fullermd | All pretty much equivalent under the hood, just different expressions. | 23:55 |
| luks | CardinalFang: why not just merge it? | 23:55 |
| fullermd | Well, that's why we have the special treatment of left-side history :) | 23:55 |
| CardinalFang | Oops I said "revert" a few times when I meant "uncommit". | 23:55 |
| luks | then all the revisions would be grouped under one logical unit | 23:55 |
| foom | yes, bzr automatically "hides" the intermediate commits into the merge commit | 23:56 |
| * CardinalFang is eager for "gcommit" to load the previously saved commit messages. | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!