| lifeless | what do CVS users do? their version ids are N-length - e.g. 1.1.1.1.1.1.1.1.1 | 00:00 |
|---|---|---|
| lifeless | this can't be a new challenge | 00:00 |
| pattern | "For the purposes of this module, a version "number" is a sequence of positive integer values separated by one or more decimal points and optionally a single underscore." http://search.cpan.org/~jpeacock/version-0.74/lib/version.pod | 00:01 |
| pattern | however, the standard is to just have three digits, separated by decimal points | 00:01 |
| lifeless | heh | 00:01 |
| lifeless | you could just do MAJOR.revno | 00:02 |
| lifeless | for use case 1). | 00:02 |
| pattern | but i'm not going to want to release a new minor version every time i do a commit | 00:03 |
| lifeless | so | 00:03 |
| pattern | and skipping minor version numbers might be confusing for users | 00:03 |
| lifeless | you were talking about tagging every commit | 00:04 |
| lifeless | this would have had the same behaviour | 00:04 |
| pattern | yes, but they'd be tagged with X.Y.revno | 00:04 |
| lifeless | A branch might be a better way to tackle this. | 00:04 |
| pattern | not with X.revno | 00:04 |
| lifeless | if you have two branches | 00:05 |
| lifeless | one branch, call it 'releases' | 00:05 |
| lifeless | every commit there is a release you are doing. | 00:05 |
| lifeless | another branch, your trunk or mainline | 00:06 |
| lifeless | every commit there is just a commit | 00:06 |
| pattern | hmm | 00:06 |
| lifeless | then, to do a release, merge to the release branch and commit | 00:06 |
| pattern | i actually haven't worked with multiple branches of a single project in bazaar | 00:06 |
| lifeless | X.Y.revno in the release branch will go up slowly | 00:06 |
| pattern | so i'm not sure i understand how this would work exactly | 00:06 |
| lifeless | or even X.revno | 00:06 |
| lifeless | well, have a play | 00:07 |
| lifeless | make a scratch project, follow the tutorials | 00:07 |
| lifeless | get a feel for it | 00:07 |
| pattern | ok | 00:07 |
| pattern | thanks for your help, lifeless | 00:08 |
| lifeless | np | 00:08 |
| pattern | what you're describing might be something like what's on this page... https://www.fmios.org/wiki/Discussions/BzrLayout | 00:09 |
| pattern | under the "Package Versioning" section near the bottom of the page | 00:09 |
| pattern | "The hope is that future development for each package will follow a milestone path, where milestones are set for a specific release, and when the milestones have been achieved in dev, the branch will then be copied off to the release version for that package. At that point the package is considered released and no further enhancements will be allowed to the release branch, only bug fixes. Enhancements and such will be allowed to continue in the dev branc | 00:10 |
| pattern | h of the package." | 00:10 |
| pattern | so, would i do something like this? "mkdir myproject/dev ; cd myproject/dev ; bzr init ; vi my_perl_module ; bzr add my_perl_module ; bzr commit" etc... and work in "myproject/dev" and then when i have a build ready for release do "cd myproject ; bzr branch dev 1.0" to create a copy of the dev branch? | 00:21 |
| pattern | or i guess that's what that fmios.org page is suggesting | 00:23 |
| pattern | you seem to be suggesting doing "cd myproject ; bzr branch myproject releases ; cd releases ; bzr commit" | 00:24 |
| pattern | i'm not sure what advantage either of these approaches gives over simply tagging revisions with "X.Y.revno" | 00:25 |
| pattern | that seems much more efficient... why have these superfluous copies of the main development branch sitting around when all the important information in the copies would already be in the main development branch to begin with? | 00:26 |
| lifeless | well | 00:30 |
| lifeless | they are not superfluous; and a shared repo means you don't have copies either | 00:30 |
| pattern | when the files are checked out, isn't the information copied? | 00:30 |
| lifeless | depends | 00:31 |
| pattern | i guess i could delete the files after the release, but then that would defeat the purpose of having a separate release branch | 00:31 |
| lifeless | what info you mean. your working files yes. | 00:31 |
| pattern | yes, the working files | 00:32 |
| lifeless | the historical data base - optionally no. See bzr help init-repo. | 00:32 |
| lifeless | and you could use zap-tree to remote teh release tree temporarily. | 00:32 |
| lifeless | still, if you haven't actually sat down and simulated with a trial project, I urge you to do so | 00:32 |
| pattern | well, i did just try it | 00:32 |
| lifeless | things become much clearer when you have actually worked with 'bzr merge' and multiple branches etc | 00:33 |
| pattern | with very basic files | 00:33 |
| pattern | i haven't tried merging them | 00:33 |
| pattern | but if i'm only going to be using a separate branch for release purposes, i shouldn't need to merge branches | 00:33 |
| pattern | and i'm still not sure what advantage i'd get from having a separate release branch | 00:33 |
| pattern | over and above what i'd get from simply tagging the development branch with a version number | 00:34 |
| lifeless | I think you just need to choose something and run with it | 00:34 |
| lifeless | if it turns out not to work, change your mind | 00:34 |
| pattern | good idea | 00:35 |
| lifeless | the only thing you should do right now is to make sure that you will be able to change your mind without too much trouble | 00:35 |
| lifeless | e.g. by how you allocate x.y and z. | 00:35 |
| pattern | yep.. that makes sense | 00:37 |
| pattern | thanks again, lifeless | 00:37 |
| * ig1 food | 02:13 | |
| AfC | I've been noticing `bzr serve` instances staying in CLOSE_WAIT a long time. | 02:15 |
| ig1 | abentley:ping | 02:57 |
| abentley | ? | 02:57 |
| ig1 | let's try that again - ping abentley | 02:57 |
| ig1 | hi | 02:57 |
| abentley | Hi. | 02:57 |
| ig1 | re switch ... | 02:58 |
| ig1 | looking at cmd_update ... | 02:58 |
| ig1 | is it appropriate to refactor most of that into a module ... | 02:58 |
| ig1 | that switch uses instead of its own update function? | 02:58 |
| abentley | I don't know. | 02:58 |
| ig1 | in particular, jameinel had some feedback re pending merges ... | 02:59 |
| ig1 | that seem to be better thought though in cmd_update | 02:59 |
| abentley | I've advocated that there should be no "switch" command. Update should just take a branch, like it already takes a revision. | 02:59 |
| ig1 | also, I'm thinking about future -r support for update | 02:59 |
| ig1 | interesting | 03:00 |
| abentley | Okay, maybe it doesn't already. | 03:00 |
| abentley | But people think it's counterintuitive. | 03:00 |
| ig1 | conceptually, I've always thought of switch as bind+update | 03:01 |
| abentley | OTOH, update has some pretty weird behavior, if the working tree is out of date with the branch, and the branch is out-of-date with the master branch. | 03:01 |
| ig1 | but there is next to no code from bind or update used in switch currently | 03:02 |
| abentley | Switch isn't bind at all. | 03:02 |
| abentley | So that part makes sense. | 03:02 |
| abentley | The implementation of bzrtools.switch.switch and bzrtools.switch._update is reasonably short, but if we can get more code reuse, that's usually a good thing. | 03:04 |
| ig1 | ok, so bind sets the master branch attribute ... | 03:04 |
| ig1 | which switch ties a tree to a branch, yes? | 03:05 |
| ig1 | s/which/while/ | 03:05 |
| abentley | Right. | 03:06 |
| ig1 | any thoughts on pending merge handling? | 03:06 |
| abentley | I don't remember John's comments. | 03:06 |
| ig1 | is it ok for switch to fail and tell the user to revert pending merges before switching? | 03:07 |
| ig1 | or commit of course | 03:07 |
| ig1 | i.e. tell them to commit or revert | 03:08 |
| abentley | Yes, I think that would be fine. | 03:08 |
| ig1 | thanks | 03:09 |
| poolie | hello ig1, abentley | 03:27 |
| ig1 | hi poolie | 03:27 |
| ubotu | New bug: #72227 in bzr "bzr fails when run within certain Python code trees" [Medium,In progress] https://launchpad.net/bugs/72227 | 04:06 |
| === keir_ is now known as keir | ||
| === Verterok is now known as Verterok_ | ||
| lifeless | I's back | 07:21 |
| beuno | mornin' lifeless | 07:21 |
| === m_stone is now known as m_stone|home | ||
| * ig1 food | 08:08 | |
| vila | pattern: regarding perl modules version numbers, notice that 'version' itself has always used X.Y revions numbers (as most of packages on CPAN do) | 08:16 |
| vila | then, if you use MakeMaker, there is a dist target in the makefile, use it to define your version when you produce a new release (Module::Build certainly provides the same target) | 08:17 |
| vila | finally if you look at various packages you will see that the revisions are not always consecutive so using X.<bzr revno> will be perfectly acceptable and understood by users | 08:22 |
| pattern | vila, when you say "'version' itself", what are you referring to? | 08:24 |
| pattern | the version module? | 08:25 |
| vila | the 'version' package which is now part of perl itself | 08:25 |
| pattern | ah | 08:25 |
| vila | http://search.cpan.org/~jpeacock/version-0.74/ | 08:25 |
| pattern | yes, it uses an X.Y version string | 08:25 |
| pattern | some modules use X.Y and others X.Y.Z | 08:26 |
| vila | so X.Y.Z is *not* mandatory | 08:26 |
| pattern | that's true | 08:26 |
| pattern | but the point is that it's not just a single integer version string | 08:26 |
| pattern | it's either X.Y or X.Y.Z | 08:26 |
| pattern | but bazaar only provides a single integer | 08:26 |
| pattern | so i have to create at least X.Y myself | 08:27 |
| vila | as long as you provides monotonically increasing numbers you'll be fine | 08:27 |
| === me_too is now known as too_short | ||
| vila | you can use 0.<bzr revno> | 08:27 |
| pattern | well, nothing will break if i do that | 08:27 |
| === too_short is now known as me_too | ||
| vila | that's the point | 08:27 |
| pattern | but it might be a bit confusing for the users when i jump from 0.23 to 0.198 | 08:27 |
| vila | kiss principle | 08:27 |
| vila | hmmm, you'll have to check that but if you add you own code to create the release (dist target in makefiles) you can address that | 08:29 |
| pattern | it's not just a matter of having the dist target being numbered correctly | 08:29 |
| vila | and most package writers handle their release numbers manually anyway | 08:29 |
| pattern | an internal version number for the perl module itself is also necessary | 08:30 |
| pattern | so that module users can check and request particular versions of my module | 08:30 |
| pattern | so that version number needs to go in to the perl module itself | 08:30 |
| pattern | i'm probably going to do that using a templating system (probably Template Toolkit) | 08:31 |
| pattern | so i'll just have "$VERSION = [% VERSION %]" in the perl module, and in Makefile.PL i'll run some command to fetch the version number from bzr and substitute it in to the perl module | 08:33 |
| vila | fine | 08:34 |
| pattern | so the development will be on mymodule.pm.in and Makefile.PL will turn that in to mymodule.pm | 08:34 |
| pattern | and only mymodule.pm.in will be versioned | 08:35 |
| vila | you may also look at creating your own template for bzr version-info | 08:36 |
| pattern | i don't understand | 08:37 |
| pattern | what kind of template? | 08:37 |
| pitti | hi | 08:38 |
| pitti | first, congrats for knitpacks! I just did some experiments, and it cut down the initial push time from 80 seconds to 46 | 08:38 |
| pitti | but I have troubles with pushing some additional revisions | 08:39 |
| pitti | bzr: ERROR: Could not understand response from smart server: ('error', "<bound method KnitPackRepository.leave_lock_in_place of KnitPackRepository('chroot--1218286772:///tmp/pack800/.bzr/repository/')>") | 08:39 |
| pitti | (both sides are running bzr 0.92.0 final) | 08:39 |
| pitti | is this known? | 08:39 |
| vila | pattern: look at bzrlib/cmd_version_info.py | 08:39 |
| lifeless | pitti: check the packs tag on malone :_ | 08:39 |
| pitti | ah, good hint; seems to be https://bugs.edge.launchpad.net/bzr/+bug/156546 | 08:40 |
| ubotu | Launchpad bug 156546 in bzr "unable to push to packs-based smart server" [High,Triaged] | 08:40 |
| pattern | vila, ah, you mean some kind of script that will interface with bazaar to get the version information i want to use in my perl module? | 08:41 |
| vila | yes | 08:41 |
| pattern | unfortunately, i don't know python | 08:41 |
| pattern | does bazaar have a perl interface? | 08:41 |
| vila | not yet :) | 08:41 |
| pattern | i mean to learn python someday | 08:41 |
| vila | try bzr version-info --format=python | 08:41 |
| vila | pattern: python has good surprises for you coming from perl :) | 08:42 |
| lifeless | or write a perl formatter :) | 08:42 |
| pattern | yep :) | 08:43 |
| bignose | How do I undo a 'bzr pull'? | 10:13 |
| bignose | I mistakenly pulled from foo to bar, and now I want bar to go back to its revision level before the pull | 10:13 |
| bignose | similar to 'bzr uncommit' | 10:13 |
| fullermd | If you know what revision used to be the head, you can just pull it. | 10:14 |
| bignose | and that will cause the current branch to lose the revisions after that point? | 10:15 |
| bignose | 'bzr pull -r82 .' => "No revisions to pull." | 10:16 |
| fullermd | You need --overwrite since it's not going strictly forward. | 10:16 |
| bignose | (current branch is at r87, I want to lose everything after r82 because they came in from the mistaken pull) | 10:16 |
| fullermd | The revs will still be in its repository, of course. But the branch won't refer to them, so... | 10:17 |
| bignose | that's fine, I'm using a central repository. | 10:17 |
| bignose | okay, that seems to have done the trick | 10:18 |
| bignose | fullermd: thanks. | 10:18 |
| bignose | next question: | 10:18 |
| bignose | the reason I wanted to undo it was because I wanted to pull only *some* changes from foo into bar | 10:19 |
| bignose | eventually, all of foo will be pulled in, but not yet | 10:19 |
| bignose | so how can I pull specific revisions? | 10:19 |
| fullermd | Well, you can pull up to a given rev rather than the head with -r... | 10:20 |
| bignose | right, but that's exactly the situation I wanted to undo | 10:20 |
| bignose | I want to specify "pull revision 87 and no other revision from foo into bar" | 10:21 |
| fullermd | You can approximate it by gettings its changes with a cherry-picked merge. But there's no way to get rev 87 itself without getting its antecedents. | 10:22 |
| fullermd | That may or may not lead to extra fun down the line when you merge the rest of the revs. | 10:23 |
| bignose | mmm. a cherrypicked merge will result in forever-divergent history, won't it? I want to be able to later align the histories fully with a pull. | 10:23 |
| fullermd | Well, if you don't make changes other than the equivalent of r87, you can later just do a pull --overwrite and discard that new rev you made. | 10:24 |
| bignose | I hear the spectral voices of my darcs friends laughing and pointing... | 10:24 |
| fullermd | (as long as nothing else is based on it, of course) | 10:24 |
| fullermd | They're not laughing and pointing. They will though, as soon as their history finishes resolving itself. Might want to budget some time in 2015 to deal with the embarassment. | 10:25 |
| bignose | I don't fully understand that, but I assume it's a comment on the performance speed of darcs merges. | 10:25 |
| bignose | fullermd: by "discard that new rev you made", do you mean the rev created by the cherrypicked merge? Discard it because, with a 'pull --overwrite', the change will effectively be made anyway? | 10:27 |
| fullermd | Well, you're wanting code that does a certain thing. After you do the cherrypick, that code will be in both r87, and your newly-created cherrypick r83. | 10:28 |
| fullermd | So if you then want to re-duplicate the other branch, a --overwrite will toss away your cherry-83, but since you'll have that 87 anyway at the point, it doesn't matter. | 10:28 |
| fullermd | Assuming no work is ever based off that cherry-83, that is. | 10:29 |
| bignose | fullermd: thanks, you've at least improved my understanding of what I'm asking :-) | 10:40 |
| keir_ | http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/ | 10:42 |
| lifeless | night all | 10:54 |
| lifeless | keir_: be good to find out what the date: thing they hate is | 10:54 |
| keir_ | yes | 10:58 |
| keir_ | lifeless, we need to get some big projects on board! | 10:59 |
| fullermd | Packs for local and more SS for remote are probably 2 of the biggest steps to take there. | 11:12 |
| === cprov-away is now known as cprov | ||
| === othermaciej_ is now known as othermaciej | ||
| wam | Hi, is it possible to branch / merge / push / pull to/from not-mounted samba shares? | 13:17 |
| === mrevell-lunch is now known as mrevell | ||
| mwhudson | wam: you mean push smb:///whatever ? | 13:17 |
| mwhudson | wam: i'm not aware of anything that would let you do that | 13:18 |
| wam | mwhudson: would it be easy to write a plugin for that? | 13:18 |
| wam | mwhudson: bzr is python-only, so maybe I could look at this. | 13:18 |
| wam | (as I know python ;)) | 13:18 |
| mwhudson | wam: it's probably possible, yes | 13:19 |
| mwhudson | i mean, there's a webdav plugin that mostly works and samba can't be that painful :) | 13:19 |
| wam | mwhudson: ok, thanks. So I'll see if I have a use for it and maybe code it. A customer of mine works on windows and the working-dir is smb only. So I'd like to install a branch there and have merges as smoothly as possible ;) | 13:20 |
| === bac_afk is now known as bac | ||
| mwhudson | wam: good luck :) | 13:22 |
| === jamesh_ is now known as jamesh | ||
| === bac_afk is now known as bac | ||
| === bac_afk is now known as bac | ||
| === bac is now known as bac_afk | ||
| === bac_afk is now known as bac | ||
| === cprov is now known as cprov-lunch | ||
| vila | hi all | 14:19 |
| vila | abentley: is BB down ? Firefox timeouts trying to connect | 14:19 |
| vila | or is it times out ? ;) | 14:19 |
| fullermd | You trying to connect via htpps? | 14:21 |
| vila | fullermd: not even :) | 15:00 |
| === jam-laptop is now known as jam | ||
| ubotu | New bug: #163849 in bzr-eclipse "display revision log on uncommit" [Undecided,New] https://launchpad.net/bugs/163849 | 16:05 |
| jelmer | sigh | 16:31 |
| jam | jelmer: ?? | 16:31 |
| jelmer | where are the days when you could hit Ctrl+C to abort the commit if you changed your mind | 16:31 |
| jam | I do that now | 16:31 |
| jelmer | now I have to use uncommit all the time :-) | 16:31 |
| jam | the commit happens to fast? | 16:32 |
| jelmer | yup, somewhat like that :-) | 16:32 |
| jam | the price of progress, I guess | 16:33 |
| jam | You could not use "-m" so that you can cancel without saving from your text editor | 16:33 |
| jelmer | yeah, I may give that a try - thanks | 16:35 |
| jam | personally, I would just 'bzr uncommit --force" | 16:36 |
| mwhudson | good reason not to use checkouts, that | 16:38 |
| mwhudson | less embarrassing | 16:38 |
| jam | mwhudson: bzr uncommit removes it from the bound location, too | 16:38 |
| jam | as long as nobody goes spelunking with "bzr heads" | 16:38 |
| mwhudson | jam: true, but it might send email, etc | 16:38 |
| jam | mwhudson: yeah, but my client always sends email | 16:38 |
| jam | even for local stuff :) | 16:38 |
| jam | well, I have a .../private/* directory | 16:39 |
| jam | for stuff I don't advertise | 16:39 |
| ubotu | New bug: #163860 in bzr "feature request: script to generate consistent copy of shared repository ('hot-backup.py in svn terminology)" [Undecided,New] https://launchpad.net/bugs/163860 | 17:01 |
| woei | I'm playing around a bit with bzr and I'm wondering if this error is expected behavior ? : http://pastebin.com/d24d654d5 | 17:03 |
| Kinnison | woei: blergh, even if it were an error to try and do that, you shouldn't get that kind of report | 17:05 |
| woei | indeed | 17:05 |
| mwhudson | does anyone know a way of doing this: http://paste.ubuntu-nl.org/45128/ without requiring a checkout ? | 17:21 |
| jam | mwhudson: I don't believe the Merge code works without a limbo directory from a WT | 17:28 |
| mwhudson | jam: what i want to avoid is the lengthy tree-building process for launchpad | 17:29 |
| jam | mwhudson: have you tried it with an empty WT? | 17:30 |
| jam | ah, but that wouldn't work either | 17:30 |
| jam | wait a second | 17:30 |
| jam | why are you doing a 'show_diff_trees' of revtree versus basis_tree | 17:31 |
| mwhudson | jam: won't that take all the history of merge_source_branch? | 17:31 |
| jam | don't you want the diff of the on-disk tree ? | 17:31 |
| jam | (after the merge) | 17:31 |
| jam | to its basis? | 17:31 |
| mwhudson | jam: that's what i'm getting, it seems | 17:32 |
| mwhudson | basis may not be a good name here | 17:32 |
| jam | ah | 17:32 |
| jam | ok | 17:32 |
| jam | yeah, basis_tree is usually: tree.basis_tree() | 17:32 |
| jam | which is the last committed version | 17:32 |
| mwhudson | oh | 17:32 |
| jam | I would just call it "tree" | 17:33 |
| mwhudson | so revtree = basis_tree.basis_tree() is shorter and equivalent? | 17:33 |
| mwhudson | jam: let me rename somethings and repaste :) | 17:33 |
| jam | mwhudson: and for DirState working trees is faster | 17:33 |
| mwhudson | jam: fine, but the slow part is create_checkout | 17:34 |
| jam | because it has already written things down for faster comparisons | 17:34 |
| jam | mwhudson: sure. | 17:34 |
| jam | I understand your difficulty | 17:34 |
| jam | I'm pretty sure the merge code doesn't have a way to work "lazily" and only extract texts for files that it is going to think of as modified | 17:35 |
| jam | It might be possible to patch it in | 17:35 |
| jam | as a "LazyWorkingTree" or something like that | 17:35 |
| mwhudson | jam: http://paste.ubuntu-nl.org/45130/ | 17:35 |
| mwhudson | jam: right, i wondered about that | 17:35 |
| mwhudson | jam: TreeTransform seems to hit the disk reasonably directly though, which worried me for this approach | 17:36 |
| jam | yeah, but I think you could hide the real working files | 17:37 |
| jam | Let me look at the code for a bit | 17:37 |
| mwhudson | jam: thanks | 17:38 |
| jam | mwhudson: it depends on how much you want to spend writing up a LazyWorkingTree, but it seems possible | 17:40 |
| jam | you would still need to hit disk | 17:40 |
| jam | but the idea is you would create an object that doesn't extract text contents until it needs to | 17:41 |
| jam | and it could track the list of files which were modified | 17:41 |
| mwhudson | i don't care about hitting the disk | 17:41 |
| jam | mwhudson: I could certainly help walk you through it if you want. | 17:41 |
| mwhudson | i care about doing O(changes) rather than O(changes+tree) work | 17:41 |
| jam | sure | 17:42 |
| mwhudson | jam: how much work would you expect this to be? | 17:42 |
| jam | I'm saying more: how much time do you want to spend coding this up :) | 17:42 |
| jam | I'm actually thinking it wouldn't be that much effort | 17:42 |
| jam | You only need to override a few key places | 17:43 |
| mwhudson | i dunno, i don't want to spend a week on it | 17:43 |
| mwhudson | but a day is probably just about reasonable | 17:43 |
| jam | so some quick pointers... | 17:43 |
| jam | you wouldn't use "target_branch.create_checkout()" obviously | 17:43 |
| jam | instead you would init a new WT type | 17:43 |
| jam | on that branch | 17:43 |
| jam | and then you would override WT.get_lines() or it looks like you might need to also do WT.get_file() | 17:44 |
| jam | (I don't know for sure why TT uses get_file().readlines() rather than get_lines() | 17:44 |
| jam | might just be hysterical raisons) | 17:44 |
| mwhudson | i should subclass WorkingTree ? | 17:44 |
| jam | mwhudson: I think subclassing WT4 might be a good way to go | 17:45 |
| jam | bzrlib.workingtree_4.WorkingTree4 | 17:45 |
| jam | as it has better "diff" code | 17:45 |
| jam | All you are really adding is a list of things that have been modified | 17:45 |
| jam | so your 'get_lines()' implementation knows to read from disk | 17:45 |
| jam | rather than going to the repository. | 17:45 |
| jam | (and get_file_sha1() also needs to be overridden) | 17:46 |
| jam | and probably get_file_size() | 17:46 |
| jam | mwhudson: If you want, I could probably try hacking something together | 17:46 |
| mwhudson | jam: that would be cool | 17:48 |
| jam | I'll give it an hour or so and see where I get | 17:48 |
| mwhudson | jam: awesome | 17:48 |
| jam | actually, it almost fits in with an idea Robert had | 17:49 |
| jam | to make commit/diff/etc extra fast | 17:49 |
| jam | by requiring the user to explicitly mark things changed | 17:49 |
| jam | It just goes an extra step and doesn't bother creating the other files | 17:49 |
| === cprov-lunch is now known as cprov-away | ||
| lifeless | mwhudson: so you want a tree where the user can't introduce changes, only merges can. | 18:26 |
| mwhudson | lifeless: what i want is described by the docstring of the function | 18:26 |
| mwhudson | lifeless: but yes, something like that sounds like a reasonable approach | 18:27 |
| lifeless | mwhudson: which function? | 18:27 |
| mwhudson | lifeless: http://paste.ubuntu-nl.org/45130/ | 18:27 |
| lifeless | jam: I think a working tree is the wrong approach for mwhudson's request; I'd look at subclassing merger myself | 18:32 |
| lifeless | jam: then passing in two revtrees | 18:32 |
| lifeless | so the output instead of being back into a working tree would go forward as iterable output | 18:32 |
| jam | lifeless: you would have to keep the contents of all modified files in memory for the full length of the merge | 18:32 |
| lifeless | jam: nope | 18:33 |
| jam | i think I see where you are going with it | 18:33 |
| jam | but I don't think Merger is really cleanly capable of it | 18:34 |
| lifeless | This is a design I prepared earlier FWIW :) | 18:34 |
| mwhudson | which reminds me | 18:34 |
| mwhudson | what's the relationship between Merge3Merger and Merger ? | 18:34 |
| lifeless | merge logic | 18:34 |
| jam | what to do when you have files that need to be combined (merged) | 18:34 |
| mwhudson | i am perpetually surprised by the fact that there is no subclass relationship here | 18:35 |
| lifeless | mwhudson: me too looking at it | 18:35 |
| lifeless | still; patches kthxcontribute | 18:35 |
| jam | I believe Merger is the 'metaprocess' | 18:36 |
| jam | and it takes a merge_type as a helper class | 18:36 |
| jam | which at the least are poorly named | 18:36 |
| mwhudson | lifeless: i don't feel competent in this code | 18:36 |
| lifeless | ok, time for some pb luv | 18:39 |
| jml | hi everybody. | 18:43 |
| lifeless | LarstiQ: ping | 18:44 |
| lifeless | hi jml | 18:44 |
| jml | I think I am going to spend some time making Trial able to run the bzr tests. | 18:45 |
| lifeless | aren't you on leave ? | 18:50 |
| jml | lifeless: yes. | 18:50 |
| jml | ok, so if you can trick trial into running on the return value of bzrlib.tests.test_suite(), rather than doing discovery then it works quite well. | 19:07 |
| jml | modulo our TestResult objects not supporting TestSkipped and TestNotApplicable. | 19:07 |
| bagueros | hello. is there a way to push just individual files into other branches? | 19:08 |
| LeoNerd | Not really.. "individual files" don't really exist in discrete form. | 19:09 |
| LeoNerd | A branch isn't a collection of files. It's a collection of revisions. | 19:09 |
| LeoNerd | Revisions contain changes to (additions/modifications/renames/deletes) files. | 19:09 |
| bagueros | well | 19:09 |
| bagueros | i have a bunch of different branches and in each one, i want to take some files out of those | 19:10 |
| LeoNerd | (As compared to the RCS/CVS/SVN view of the world, that says files exist, and revsisions exist within files) | 19:10 |
| bagueros | and put them into a branch called stable | 19:10 |
| bagueros | because a bunch of different developers have all been working on different things | 19:10 |
| LeoNerd | Do you want to preserve all the history so far, or just "carry on" from here? | 19:10 |
| bagueros | and each of them have *some* files which i want | 19:10 |
| lifeless | 'bzr merge branch/FILE' will merge just hat file. | 19:11 |
| bagueros | lifeless: ah! interesting | 19:11 |
| lifeless | we don't currently remember later that we did that. But it will work. Also works for directories. | 19:11 |
| bagueros | well i mean, how is this "done right" ? | 19:11 |
| bagueros | i got a bunch of different people who are working on different branches.. | 19:12 |
| bagueros | the guy doing Feature A has old files for Feature B | 19:12 |
| bagueros | the guy doing Feature B has new files for Feature B and old files for Feature A | 19:12 |
| bagueros | so in stable, i want the new files for Feature B from the Feature B guy | 19:12 |
| bagueros | and the files for Feature A from the Feature A guy | 19:13 |
| dato | bagueros: oh, but you want to merge the full FeatureA and FeatureB branches, one after another, or just specific changes from them? | 19:13 |
| bagueros | I don't want Feature B guy's old Feature A files to overwrite Feature A guy's new Feature A files | 19:13 |
| bagueros | you know what i mean? | 19:13 |
| dato | yes | 19:13 |
| lifeless | bagueros: oh, just bzr merge | 19:14 |
| dato | if you merge FeatureA, and then merge FeatureB, all changes will get merged. | 19:14 |
| lifeless | we clearly need some documentation improvements here | 19:14 |
| bagueros | indeed | 19:14 |
| bagueros | and merge will figure out who has the latest version for each file | 19:15 |
| bagueros | and use that one? | 19:15 |
| dato | yep. even if both developers touched the same file, but different parts of it, will do an intelligent merge and combine both changes. | 19:16 |
| lifeless | bagueros: it will integrate the changes made. | 19:16 |
| jml | and trial misses exactly 777 tests. hmm. | 19:17 |
| bagueros | ok | 19:17 |
| dato | jml, what's trial? | 19:18 |
| jml | dato: a unit testing framework that twisted uses. | 19:19 |
| dato | ah, okay. | 19:19 |
| jml | which is the number of tests that I have in my various plugins :) | 19:23 |
| jam | jml: do you know about "bzr selftest --list-only" ? | 19:36 |
| jam | It might make it easier to figure out what is and isn't being found | 19:36 |
| jam | You could use "bzr selftest --list-only | sort" and compare the output | 19:36 |
| jml | jam: I didn't know about that -- thanks. | 19:37 |
| RainCT | hi | 19:41 |
| RainCT | wasn't there a «bzr cdiff» option some time ago, or did I dream that? :P | 19:41 |
| jam | RainCT: from bzrtools | 19:41 |
| RainCT | ah ok, thanks | 19:41 |
| lifeless | jam: ping | 20:02 |
| lifeless | jam: I'd like to sanity check a refactoring goal with you. | 20:02 |
| lifeless | I want to make pb a bit simpler. heres how I think it might look | 20:02 |
| lifeless | firstly, I want to decouple 'progress' and 'display'. Nesting is about progress not display. So I'm thinking of adding a Task concept | 20:05 |
| lifeless | this will have message, current, total. | 20:05 |
| lifeless | now, I don't think we care about estimating time for all tasks. Only the overall one. So there will be a subclass TimedTask that adds in the eta calculations etc. | 20:06 |
| lifeless | now, our pb abstraction for users really needs __init__, update, clear, message and finished | 20:08 |
| lifeless | oh, and tick | 20:09 |
| lifeless | which is 'doing stuff' | 20:10 |
| lifeless | having a trivial display-a-task as *ProgressBar is the goal, but throttling makes this a little hard | 20:10 |
| lifeless | if we show the message from e.g. the bottom task as well as the top, that may thrash | 20:11 |
| lifeless | but we do want to always show a top level message change. | 20:11 |
| lifeless | and to complicate things, some commands will have a top level task that goes e.g. 0->2, where the first level is really the one that we want to change reasonably often. | 20:12 |
| lifeless | the reason throttling doesn't hide messages, IIRC, is that we have a message that indicates the start of a slow operation, and it then sits for ages. | 20:13 |
| lifeless | so I'm proposing to change it to ignore message, and add in a 'force' parameter to update if needed | 20:15 |
| lifeless | so anyhow the big picture rapidly: | 20:15 |
| lifeless | Task tracks tasks | 20:15 |
| lifeless | TaskStack is a stack of tasks | 20:15 |
| lifeless | TimedTask is a timed task | 20:16 |
| lifeless | TaskStack is a Task itself. | 20:16 |
| lifeless | _BaseProgressBar is for display logic only, it displays a Task | 20:17 |
| lifeless | bars that want to dispaly many bars concurrently can expect/require a stack and work with the stack | 20:17 |
| lifeless | nested_progress_bar stays, it returns a Task though | 20:18 |
| lifeless | Task has update/clear/message/tick/finished, because task changes trigger display changes | 20:18 |
| lifeless | fini | 20:18 |
| lifeless | hmm | 20:30 |
| lifeless | actually I think there is a differnet concept in there | 20:30 |
| lifeless | which is progress | 20:31 |
| lifeless | so a Progress object -> update/clear/tick/finished. Calling these delegates as appropriate to either the Bar for UI, or the Task for tracking. | 20:31 |
| Vantage | hi, is there a way in bzr to take two repos and merge them into one (including history)? | 20:33 |
| Vantage | I know there's split to separate a repo, but what about bring them together? | 20:33 |
| lifeless | e.g. update is 'if self.task.update(message, current, total): self.bar.tick()' | 20:33 |
| lifeless | Vantage: repositories are just a history database | 20:33 |
| lifeless | Vantage: perhaps you mean 'branch' ? | 20:33 |
| Vantage | lifeless: right, and I'd like to merge the history databases :) | 20:34 |
| lifeless | Vantage: just branch into the repository then, it will bring in any needed history. | 20:34 |
| lifeless | Vantage: 'split' does /not/ affect repositories. I really think you are confused about something. | 20:34 |
| Vantage | lifeless: so if I had a repo called frontend and a repo called backend (because I thought it'd be better to keep them separate) and later I decide it's better to have it as one project | 20:34 |
| Vantage | lifeless: I'm always confused about something :) | 20:35 |
| lifeless | Vantage: repositories don't have names. I *really* think you mean 'branch'. | 20:35 |
| lifeless | Vantage: if you can run 'log' on it it is a branch. | 20:35 |
| Vantage | lifeless: sure, at their essence they are branches, but of different code bases | 20:36 |
| lifeless | then just merge them. | 20:36 |
| Vantage | lifeless: even if they never shared any history before? (or even files) | 20:36 |
| lifeless | you'll need to tell bzr you really want to do this - 'bzr merge -r 0..-1 otherbranch' | 20:36 |
| Vantage | lifeless: so if I have two code trees in bzr that I initialized separately into two directrories (a/ and b/) I could just cd a/ bzr merge ../b ? | 20:38 |
| lifeless | Vantage: of course. try it - you'll need the -r parameters I gave you | 20:39 |
| Vantage | lifeless: very cool. btw what do those paramters actually mean? | 20:40 |
| lifeless | Vantage: for future reference, 'Repository' is just the database. Its like asking 'how do you merge two mysql databases' - its a no-op, theres nothing to do, they are just data. | 20:40 |
| lifeless | if you want to talk about your projects or your code, its *always* 'Branch'. | 20:40 |
| lifeless | Vantage: the -r 0..-1 says 'merge from the beginning of time (0) to the most recent commit (-1)' | 20:41 |
| Vantage | lifeless: cool. I knew that they were branches, but I thought that they had separate repositories was an issue. i guess not :) | 20:41 |
| thumper | lifeless: do you know about bug 152746? | 20:41 |
| ubotu | Launchpad bug 152746 in bzr "bzr commit to bzr+ssh hangs on 'No handlers could be found for logger "bzr"'" [Undecided,Confirmed] https://launchpad.net/bugs/152746 | 20:41 |
| lifeless | Vantage: nearly all branches have separate repositories, even when the code in them is the same. | 20:41 |
| thumper | lifeless: I'm trying to help someone in #launchpad, but I don't really know what is going on | 20:42 |
| lifeless | Vantage: e.g. bazaar-vcs.org's bzr.dev has a repository. I have a separate repository here that has a copy of bzr.dev. | 20:42 |
| Vantage | lifeless: good point. Does it make a difference if you're using a shared repo? | 20:42 |
| lifeless | Vantage: dealing with separate repositories is a back-end data transfer problem, not a user-task problem. | 20:42 |
| lifeless | Vantage: nope. | 20:42 |
| lifeless | thumper: I don't, no. | 20:42 |
| thumper | lifeless: ok | 20:42 |
| lifeless | I can peek, one sec | 20:42 |
| Vantage | lifeless: nice. So if I have two projects that happen to share *some* files, can I merge changes in files between them? | 20:43 |
| lifeless | Vantage: yes. It will try to merge the whole projects though, as normal. | 20:44 |
| lifeless | Vantage: you can merge branch/FILE-OR-DIR too though, once you've done the initial sync-up merge. | 20:44 |
| Vantage | lifeless: anyway to only merge changes to a particular file? | 20:44 |
| lifeless | thumper: it looks like there is a patch for lp | 20:44 |
| lifeless | thumper: they might try break-lock I guess | 20:44 |
| lifeless | thumper: or sftp | 20:45 |
| thumper | lifeless: it has stalled in review | 20:45 |
| thumper | lifeless: break-lock didn't help (break-lock done over sftp) | 20:45 |
| lifeless | thumper: try pushing over sftp then | 20:45 |
| thumper | lifeless: pushing over SFTP worked for him | 20:45 |
| lifeless | ok | 20:45 |
| bagueros | hey so | 20:47 |
| bagueros | i had one of these developers do the merge | 20:47 |
| bagueros | and it found 12 conflicts | 20:47 |
| bagueros | what does he do with these conflicts? | 20:48 |
| bagueros | is there something automatic he can do? | 20:48 |
| lifeless | that means that two people made different changes to the same region of those files. He needs to integrate the two pieces of work. | 20:49 |
| lifeless | and then commit the result | 20:49 |
| bagueros | hmm | 20:50 |
| bagueros | what about this bzr resolve ? | 20:50 |
| bagueros | does he have to run that ? | 20:50 |
| lifeless | after integrating the work, yes. I thought this was all in the tutorials. | 20:50 |
| bagueros | well, i'm just making sure | 20:51 |
| bagueros | because http://doc.bazaar-vcs.org/bzr-0.8/tutorial.html this tells me that there are automatic utilities for doing that | 20:51 |
| bagueros | kdiff or something | 20:51 |
| lifeless | sure; I want to make sure this is discoverable without having to come and ask ;) | 20:51 |
| lifeless | wow, are you using 0.8 ? | 20:51 |
| lifeless | what bzr version are you using (bzr --version) | 20:52 |
| bagueros | no, i'[m using 0.16 | 20:53 |
| lifeless | http://doc.bazaar-vcs.org/bzr.0.16/tutorial.htm is more applicable then | 20:53 |
| lifeless | I encourage you to upgrade to 0.92 though | 20:53 |
| bagueros | so, when he did this merge, it had 12 conflicts | 21:00 |
| bagueros | and when i go look in stable, i dont see some of the files he has in his branch that i hoped would be merged into stabl | 21:00 |
| bagueros | *stable | 21:01 |
| bagueros | is it because the conflicts are holding up the merge? | 21:01 |
| Odd_Bloke | bagueros: Merges have to be committed. | 21:03 |
| bagueros | oh. but he is just working out of his branch | 21:04 |
| bagueros | when he does the commit, it will also update stable? | 21:04 |
| Odd_Bloke | Only if committing to his branch would normally update stable. | 21:10 |
| lifeless | bagueros: you should go to stable, then merge his branch | 21:12 |
| lifeless | bagueros: or you can merge from him after he commits. | 21:13 |
| ubotu | New bug: #163908 in bzr "upgrade should tell you where to upgrade" [Undecided,New] https://launchpad.net/bugs/163908 | 21:16 |
| bagueros | lifeless: i see | 21:29 |
| james_w | vila: It seems to me that the .debs of bzr should depend on ca-certificates, otherwise there is no CA to allow https access to launchpad. Does that seem sane to you? | 21:30 |
| james_w | vila: or, I can't access https://code.launchpad.net/ as it complains about a CA cert error, and I don't have that package installed. | 21:30 |
| poolie | james_w, ah, does that fix it? | 21:33 |
| poolie | forcing use of urllib seems to also fix it, though that's a bit clumsy | 21:34 |
| james_w | hi poolie | 21:35 |
| james_w | you are seeing it to? | 21:35 |
| poolie | i did see that the other day | 21:35 |
| poolie | well, a week ago | 21:35 |
| james_w | maybe its a widerspread problem then | 21:36 |
| james_w | I haven't installed that package yet, just working it around it currently to try and get that code. | 21:36 |
| james_w | poolie: yeah, that fixes it. | 21:38 |
| poolie | would you file a high-priority bug on the package, if there isn't one? | 21:44 |
| james_w | poolie: filing it now. | 21:46 |
| lifeless | poolie: would like a reply - doesn't need to be deeply considered, surface reaction is fine - to my just sent pb redesign mail | 21:57 |
| lifeless | also, quick call ? | 21:58 |
| keir_ | I just had a very frustrating experience because bzr lacks universal newline support. lets please get that fixed :( | 22:04 |
| vila | james_w: .debs for ubuntu or debian ? Also, depends may be a bit strong, can't you use recommands ? | 22:06 |
| james_w | vila, yeah, that would be better of course, thanks. | 22:07 |
| vila | using urllib is a workaround for now, implementing proper certificate verification is on my TODO list though, so it will ultimately fails too | 22:07 |
| vila | james_w: in what kind of config do you see that ? | 22:10 |
| james_w | vila: with no CA certificates in /etc/ssl/certs I think. | 22:11 |
| james_w | or at least not whatever issues lp's. | 22:11 |
| vila | :) I meant, all my ubuntu had ca-certificates installed why yours doesn't ? | 22:12 |
| james_w | vila: I don't know, let me see. | 22:12 |
| james_w | any of mutt, fetchmail, openssl, sendmail-base, w3m libcurl3-gnutls will install it, but it doesn't appear to be part of gutsy default install. | 22:14 |
| vila | Ha ! I did an update... that explains it. | 22:15 |
| james_w | yeah, must have been dropped. | 22:15 |
| siretart | james_w: I think a recommends on the ca-package is the way to go | 22:15 |
| james_w | siretart: yeah, me too. | 22:19 |
| lifeless | poolie: 1.0 branch up | 22:25 |
| Odd_Bloke | What's the best way to get a list of files that were touched by a given revision? | 22:39 |
| lifeless | repository.find_fileids_altered_by_revision_ids(revid) | 22:43 |
| lifeless | this gives file ids which have lines ascribed to them by annotation, | 22:43 |
| lifeless | the difference between that and e.g. log -v is that log -v will show things that were not altered in the revision but merged into a branch in a revision. | 22:43 |
| lifeless | i386: ping - give me a ring ? | 22:43 |
| i386 | lifeless: yep | 22:44 |
| i386 | could you message me your no? | 22:44 |
| i386 | lifeless: cool | 22:46 |
| i386 | Ill call in a sec | 22:46 |
| lifeless | thanks | 22:48 |
| igc | morning all | 22:58 |
| lifeless | hi igc | 22:58 |
| igc | hi lifeless | 22:58 |
| lifeless | igc: leslie hawthorn says 'come to her soc talk' | 22:58 |
| igc | I'm planning to | 22:58 |
| lifeless | :) | 22:59 |
| lifeless | man, enough of the russian spam | 22:59 |
| abentley | vila: I'm not aware of it going down today. | 23:05 |
| keir_ | did you guys see the post from the intel engineer on the bzr list? | 23:16 |
| jam | which one would that be? | 23:17 |
| keir_ | there are two posts from wichmann, who is from intel | 23:17 |
| keir_ | he's having big performance problems | 23:17 |
| keir_ | and the 2nd msg is about a corrupted repository | 23:18 |
| keir_ | i feel like someone should respond to the performance complaints. it looks bad when messages like this go unanswered on the ml... | 23:26 |
| lifeless | thank you for pointing it out | 23:27 |
| abentley | mwhudson: Are you sure that diffing against the least common ancestor isn't good enough for your purposes? That's what I use for the preview patches of merge directives, for example. | 23:29 |
| lifeless | abentley: yes; showing the result of the merge shows up conflicts | 23:34 |
| lifeless | abentley: and for assessing whether something is ready to merge, and in good shape, this is very useful. | 23:34 |
| abentley | Ah, I assumed he didn't care about conflicts because he was ignoring the conflict count. | 23:36 |
| abentley | Yeah, it seems like you would want to subclass either Merger or TreeTransform. | 23:36 |
| abentley | The idea of true "undo" has also pushed me at the idea of generating Trees from Transforms without hitting disk. | 23:39 |
| abentley | Because Transforms are our most detailed representation of changes. | 23:43 |
| === jamesh__ is now known as jamesh | ||
| Peng | Wow, you have an official IANA-registered port. Cool. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!