| === emgent is now known as enJoy | ||
| === enJoy is now known as emgent | ||
| === emgent is now known as enJoy | ||
| === enJoy is now known as emgent | ||
| === emgent is now known as enjoy | ||
| === enjoy is now known as enJoy | ||
| === enJoy is now known as emgent | ||
| lifeless | poolie: re 1.2: the launchpad tests are still broken | 02:31 |
|---|---|---|
| lifeless | poolie: I think this is release critical | 02:32 |
| lifeless | poolie: also there are other critical bugs IIRC | 02:32 |
| poolie | (back) | 03:04 |
| lifeless | poolie: see scrollback | 03:05 |
| === poolie_ is now known as pooliex | ||
| abentley | lifeless: I profiled a launchpad checkout with my fast-iter-changes code, and index.iter_entries was only 24%. file.seek was 31.19 | 03:09 |
| lifeless | abentley: I think lsprof islying | 03:10 |
| lifeless | seek shouldn't be doing IO :) | 03:10 |
| abentley | Well, no, but it must be doing something... | 03:12 |
| abentley | It's being called 14, 308 times. | 03:13 |
| bignose | my revspec fu is failing me | 03:21 |
| bignose | 'bzr diff --revision "date:2008-01-28..before:date:2008-02-03" fails | 03:22 |
| bignose | bzr: ERROR: Invalid revision-id {None} in KnitRepository('file:///home/benf/Projects/.bzr/repository/') | 03:22 |
| bignose | presumably because it doesn't have any revisions *on* 2008-02-03 | 03:22 |
| bob2 | what a friendly error | 03:23 |
| bignose | but I'm specifically asking for all revisions *before* that date, so I don't think it should spit an error | 03:23 |
| bignose | $ bzr --version | 03:23 |
| bignose | Bazaar (bzr) 1.1.0.candidate.1 | 03:23 |
| bignose | this is being run from an automated script, that doesn't know what the last date in the branch is. | 03:23 |
| bignose | how can I supply a "date:foo..before:date:bar" range without that error? | 03:24 |
| lifeless | bignose: strange, perhaps before:date:2008-01-29 ? | 03:24 |
| bignose | lifeless: I'm not sure what you're asking. the date range I have is "date foo, through to before (foo + one week)" | 03:25 |
| bignose | I have no way of knowing that (foo + one week) is the last date, without a lot of mucking about | 03:25 |
| bignose | s/is the last date/is *past* the last date/ | 03:25 |
| lifeless | bignose: I'm saying that if you don't know of a commit that will match, you should ask for the first commit before the date you want it to match | 03:25 |
| bignose | lifeless: that's exactly why the range I gave above is bounded by "..before:date:2008-02-03" | 03:26 |
| lifeless | bignose: you're not using before on both sides though are you? | 03:26 |
| bignose | no. | 03:27 |
| lifeless | which is what I was suggesting | 03:27 |
| bignose | but, AFAICT, it's the upper bound that causes it to fail | 03:27 |
| bignose | because the range "date:2008-01-28..-1" works fine | 03:27 |
| lifeless | oh | 03:27 |
| lifeless | in which case, welcome to bugs | 03:27 |
| lifeless | please file one :) | 03:27 |
| bignose | okay. someone else will need to do that, because Launchpad doesn't let me file bugs without creating an account. | 03:28 |
| lifeless | done | 03:30 |
| lifeless | neither does bugzilla, or trac, nor nearly any other bugtracker though | 03:30 |
| lifeless | so its a bit of a specious argument against using it :) | 03:31 |
| bignose | most good ones allow bug submission via email | 03:31 |
| lifeless | I just submitted that bug by email | 03:31 |
| bignose | by email, without requiring specific registration with the system | 03:31 |
| lifeless | I'm only aware of one system that allows that - debbugs | 03:32 |
| bignose | anyway: thank you for submitting the report | 03:32 |
| lifeless | poolie: did you see my comments on 1.2 ? | 03:32 |
| lifeless | bignose: no problem | 03:32 |
| bignose | debbugs, roundup, gnats, ... | 03:33 |
| lifeless | I would never call gnats a good system. | 03:34 |
| lifeless | roundup I haven't used enough to comment on | 03:40 |
| ubotu | New bug: #191156 in bzr "bug in revision specs before:date: ?" [Undecided,New] https://launchpad.net/bugs/191156 | 03:41 |
| abentley | lifeless: What was that memory ceiling you were suggesting for iter_files_bytes? | 03:47 |
| lifeless | abentley: 10M or something | 03:58 |
| lifeless | on a 100M tree thats 10-20 * latency multiplier, which is tolerable | 03:58 |
| lifeless | and on most trees its a tiny fraction | 03:58 |
| lifeless | single files > that have to exceed it of course | 03:58 |
| abentley | Yes. Actually with a 100K ceiling, local checkouts of bzr.dev are fast. | 04:00 |
| lifeless | I'm thinking network to some degree. but lets say 1MB then | 04:00 |
| lifeless | remembering that some exceptional trees (moz) may actually need 10M or something | 04:00 |
| Toksyuryel | bignose: bugtrackers are a major spam magnet, requiring accounts help to limit it | 04:01 |
| abentley | Sure. Easily tweaked. | 04:01 |
| abentley | lifeless: Need it because of individual file size? That's covered. | 04:01 |
| lifeless | abentley: no, file count | 04:01 |
| abentley | I'm not sure whether it would be much faster even with a much larger buffer. | 04:02 |
| lifeless | abentley: I'm thinking sftp lightweight branches/ shallow checkouts | 04:03 |
| lifeless | abentley: unrelated question, when I have shallow branches working I'm thinking that 'bzr checkout foo' should create a shallow branch | 04:03 |
| lifeless | abentley: so the difference between that and --lightweight is whether data accumulates locally or not | 04:03 |
| lifeless | abentley: and have an option '--deep' or --full or something, to get the current deep copy | 04:04 |
| abentley | That sounds reasonable to me. | 04:04 |
| lifeless | cool | 04:05 |
| abentley | I think lighweight is too light for a default when dealing with remote branches. | 04:05 |
| abentley | But when dealing with remote branches, lots of people would complain if it was too heavy, also. | 04:06 |
| lifeless | so I htink a good default is a shallow branch with one copy of each text | 04:07 |
| lifeless | for pushing I think an option to say 'cheap', and then a shallow branch with unique deltas only | 04:07 |
| i386 | lifeless: cant find the fab source code! | 04:08 |
| abentley | lifeless: I would consider going 10% higher than one-copy-of-each, just for the improved merging. | 04:08 |
| lifeless | i386: https://edge.launchpad.net/fab | 04:09 |
| lifeless | abentley: one copy of each will have up to 50 or so texts due to the delta chains | 04:09 |
| lifeless | abentley: so on merge we'll often only need to grab the revision data | 04:09 |
| reggie | why would I be getting a repo not compatible error on a bzr branch? | 04:09 |
| lifeless | (as inventories are delta'd too) | 04:09 |
| lifeless | reggie: bzr-svn has been used on one end | 04:10 |
| reggie | lifeless, hmm. | 04:10 |
| lifeless | abentley: What I mean here, is yes - I've considered that, and think it'll be ok | 04:10 |
| lifeless | reggie: the bzr svn faq talks about this | 04:10 |
| reggie | ok, let me go look | 04:11 |
| abentley | lifeless: Probably. | 04:11 |
| reggie | lifeless, not sure that is it. let me show you the error | 04:12 |
| abentley | The issue is, what if the "bound" repo is unreachable, and the repo you're merging doesn't have those revisions. | 04:12 |
| abentley | s/bound/master/ | 04:13 |
| reggie | pack-0.92 is the latest repo format? | 04:14 |
| reggie | no. rich-root is latest I guess | 04:14 |
| reggie | hmm. both local and remote repo report as pack-0.92 | 04:16 |
| abentley | reggie: Not sure what you mean by latest. | 04:16 |
| abentley | Current default is pack-0.92. | 04:17 |
| abentley | rich-root and rich-root-pack are newer than that. | 04:17 |
| reggie | abentley, well I did a svn-import on ubuntu and then did a push from that repo onto a different server | 04:17 |
| reggie | so far so good | 04:17 |
| reggie | now I'm trying to do a bzr branch from that second repo onto a windows machine and get a repo not compatible | 04:18 |
| reggie | the error says something like KnitPackRespository(u'file:///<path>) is not compatible with respository RemoteRepository(bzr+ssh://...) | 04:19 |
| abentley | Right. So you don't really care what's latest, just what's compatible. | 04:19 |
| abentley | rich-root-pack ought to be compatible. | 04:20 |
| reggie | I pushed from a rich-root to a 0.92. now I'm trying to branch from a 0.92 to a 0.92 | 04:20 |
| reggie | hmm. it has to have something to do with svn since I now attempted a branch of a non-svn import between the same repos and it works | 04:22 |
| abentley | Well, 0.92 is compatible with 0.92, so I can't see causing the error you're seeing. | 04:23 |
| reggie | I think I found the problem. my repo still have parent set as the svn parent | 04:23 |
| abentley | bzr-svn requires a rich-root format. | 04:23 |
| abentley | At least the 0.4 series does. the 0.3 series didn't. | 04:24 |
| reggie | can I take a branch that is parented on svn+ssh and break the relatinoship or do Ihave to re-import? | 04:25 |
| lifeless | abentley: shallow branches will be unusable offline in the first instance, because they don't consider the non-local data to be ghosts. | 04:25 |
| abentley | reggie: The parent is just the default pull location. | 04:25 |
| abentley | You can set it to anything with pull --remember. | 04:26 |
| abentley | But it really shouldn't matter. | 04:26 |
| reggie | oh. so branches can have their own format? I thought that was repo wide | 04:27 |
| abentley | It is repo wide. The parent has nothing to do with the format. | 04:28 |
| reggie | so is rich-root unstable? | 04:28 |
| reggie | should it be avoided currently? | 04:29 |
| reggie | got it. | 04:30 |
| reggie | abentley & lifeless: thx | 04:30 |
| abentley | reggie: rich-root is stable, in the sense that it will not change. | 04:44 |
| pooliex | lifeless, abentley, i would say bug 189757 is high, but not critical for 1.2 | 04:44 |
| ubotu | Launchpad bug 189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/189757 | 04:44 |
| abentley | pooliex: that was my feeling. | 04:45 |
| pooliex | ok | 04:45 |
| pooliex | do you think it'll be reproducible | 04:45 |
| abentley | pooliex: In the sense that I can write a test case for it, sure. But it will only happen if the interruption happens at the right time. | 04:46 |
| === reggie is now known as reggie|away | ||
| pooliex | so you could deterministically reproduce that interruption from a test script, but it's not certain people will hit it | 04:49 |
| lifeless | I think folk have on lp | 04:50 |
| pooliex | lifeless, would you please make a 1.2 pqm branch for me? | 04:51 |
| === asac_ is now known as asac | ||
| lifeless | pooliex: done | 04:55 |
| pooliex | should i register it? | 04:56 |
| lifeless | under ~bzr yes :0 | 05:06 |
| abentley | pooliex: The necessary ingredient is a .bzr control directory with no branch directory in it. | 05:08 |
| lifeless | right, patch away | 05:23 |
| lifeless | pooliex: I'm done for the day; any last requests ? | 05:23 |
| pooliex | lifeless, so that branch exists but is empty? | 05:28 |
| pooliex | lifeless, just wanted to check with you that i'm planning to fix only the launchpad plugin bug, and the dirstate bug, for 1.2rc1 | 05:28 |
| pooliex | have just sent mail to that effect | 05:29 |
| pooliex | can't think of anything else | 05:29 |
| lifeless | pooliex: the branch exists and I've pushed bzr's trunk into it | 05:35 |
| lifeless | pooliex: I would have to look to find other thins to do :) | 05:35 |
| pooliex | yes, i see now | 05:35 |
| pooliex | just a lag in lp between mirroring and scanning | 05:36 |
| pooliex | have a good night! | 05:36 |
| lifeless | just ordred a new dishwasher :) | 05:36 |
| i386 | lifeless: what was wrong with the old one? | 05:42 |
| lifeless | I'm getting a little rusty. | 05:42 |
| i386 | lifeless: :) | 05:43 |
| abentley | lifeless: I'm off to bed, but what would you think of the old-style shallow checkouts (with lots of ghosts) as a default? | 06:18 |
| lifeless | abentley: I think its easier to get to checkouts that require you online; so we can and should do that first | 06:42 |
| lifeless | abentley: we can look at soft-handling missing-key errors later IMO | 06:42 |
| === joabr is now known as jabr | ||
| === jabr is now known as joabr | ||
| === joabr is now known as jabr | ||
| ubotu | New bug: #191203 in bzr "Error at second commit in same dir" [Undecided,New] https://launchpad.net/bugs/191203 | 09:45 |
| === awilkins_train is now known as awilkins | ||
| Peng | The "0.12-release-process" blueprint depends on nested trees. Oops? :) | 10:36 |
| lifeless | gnight | 11:59 |
| === mrevell is now known as mrevell-lunch | ||
| === kiko-afk is now known as kiko | ||
| === mrevell-lunch is now known as mrevell | ||
| Lunkwill | i'm looking at http://bazaar-vcs.org/Specs/Tagging which says this was implemented in 0.15 | 13:04 |
| dato | yes | 13:04 |
| Lunkwill | yet that's the only doc I can find that mentions versioned tags | 13:04 |
| dato | tags are not versioned | 13:05 |
| Lunkwill | iow, tags aren't implemented according to the spec I just pasted? | 13:05 |
| dato | doesn't seem to be the case, indeed | 13:07 |
| jamesh | Lunkwill: there is some documentation on tags in the users guide | 13:07 |
| Lunkwill | jamesh: yes. basically it says "use bzr tag to tag" and "use bzr tags to list tags" | 13:09 |
| Lunkwill | just looking into different DVCSes and some devs I know tried to convince me bzr had versioned tags, but the above mentioned url was the only "doc" they could refer to | 13:12 |
| === AfC is now known as AfC|zzz | ||
| === kiko is now known as kiko-fud | ||
| AnMaster | is there a command like git bisect for bzr? that is perform a binary search for what revision introduced a bug in a simple wway | 15:54 |
| AnMaster | way* | 15:54 |
| AnMaster | if there is nothing like git bisect then is there at least any way to change the working tree to reflect another revision temporarily than HEAD? | 16:01 |
| hmeland | AnMaster: See https://launchpad.net/bzr-bisect/ (which I have zero experience with) | 16:02 |
| bob2 | bzr revert -r XXX | 16:02 |
| AnMaster | ah | 16:02 |
| reggie | anyone use (or write) svn2bzr? | 16:16 |
| reggie | or any subversion import specialists around? | 16:18 |
| reggie | anyone know if there is an easy way to adjust the rev-ids on a series of revisions? | 16:22 |
| === hexmode` is now known as hexmode | ||
| === kiko-fud is now known as kiko | ||
| reggie | !seen jelmer | 16:29 |
| ubotu | Sorry, I don't know anything about seen jelmer - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 16:29 |
| reggie | !tz jelmer | 16:30 |
| ubotu | Sorry, I don't know anything about tz jelmer - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi | 16:30 |
| ignas | hi | 17:44 |
| ignas | is there a way to perform something analogous to "svn import" using bzr? | 17:45 |
| ignas | i would like to get a repository with all the files in some directory without modifying that directory in any way ... | 17:45 |
| luks | not sure what exacltly svn import does, but maybe: bzr add && bzr ci -m 'Import of ...' | 17:46 |
| ignas | like bzr import /path/to/my/new/repo /path/to/stuff/i/have/readonly/access/to/ | 17:46 |
| luks | hmm | 17:46 |
| ignas | well bzr init + bzr add creates a repository in the original place | 17:46 |
| ignas | and i'd like to avoid the "cp -r" part if it's possible | 17:46 |
| * luks is a bit confused | 17:46 | |
| luks | that sounds like a branch, not import | 17:47 |
| luks | or is /path/to/stuff/i/have/readonly/access/to/ not a bzr branch? | 17:47 |
| ignas | yes it's not | 17:47 |
| luks | then I guess bzr init/cp/bzr add/bzr ci is the only way | 17:48 |
| ignas | i see | 17:48 |
| ignas | thanks | 17:48 |
| dato | ignas: bzrtools provides `bzr import` | 17:50 |
| dato | ignas: which does what you want | 17:50 |
| ignas | dato: bzrtool | 17:51 |
| ignas | i mean thanks | 17:51 |
| dato | you're welcome | 17:51 |
| fullermd | jam: Q for you when you have a minute... | 17:59 |
| jam | fullermd: go for it | 18:00 |
| fullermd | jam: Just curious as to whether the speedups you're doing on annotate would also speed up weave/knit merges. | 18:01 |
| fullermd | Or if they're just local to ann. | 18:01 |
| jam | I think there are bits to bothe | 18:02 |
| jam | sorry both | 18:02 |
| jam | I think Aaron made a case for LCA merge which is very similar to knit merge | 18:02 |
| jam | when there are multiple ancestors | 18:02 |
| jam | and is otherwise 3-way | 18:02 |
| jam | and does a little bit better about not needing to do full annotations. | 18:02 |
| jam | as for my changes..... if knit merge is implemented as "give me the full annotation, and then compute the merge" then yes, it would effect it | 18:03 |
| jam | so probably it would help, but I wouldn't guarantee anything just yet | 18:03 |
| * fullermd nods. | 18:04 | |
| fullermd | Good 'nuff for me. Thanks. | 18:04 |
| jam | fullermd: do you use knit merge often? | 18:04 |
| fullermd | Hardly ever. I almost never hit something 3way doesn't handle just fine (or at least, when I do, knit doesn't help) | 18:04 |
| fullermd | Just something I wondered about skimming the mails about it. | 18:05 |
| jam | ultimately, I think we'll need a cache of some sort | 18:07 |
| jam | because history gets longer, and any annotation algorithm is generally going to just get solwer | 18:08 |
| jam | slower | 18:08 |
| jam | I've just been pushing that down the stack, since this code should be cleaned up anyway | 18:08 |
| fullermd | Well, better a cache to speed up a fundamentally slow operation, than a cache to speed up a fundamentally slow operation with a pessimized implementation :) | 18:09 |
| sistpoty|work | hi, when I want to commit, bzr tells me that I would already hold a lock (with the pid of the very bzr process, that tries to commit)... any clues? | 18:10 |
| beuno | sistpoty|work, you can break the lock with:" bzr break-lock | 18:11 |
| beuno | some process must of hung while pushing/commiting | 18:11 |
| sistpoty|work | beuno: nope, then the same error occurs again | 18:11 |
| jam | sistpoty|work: it sounds like you are working on a heavy checkout in the same repository | 18:11 |
| jam | aka "bzr init-repo repo; cd repo; bzr checkout a b; cd b; commit" | 18:12 |
| jam | which sounds like bug #95004 | 18:13 |
| ubotu | Launchpad bug 95004 in bzr "commit into checkout fails when shared repository used" [High,Confirmed] https://launchpad.net/bugs/95004 | 18:13 |
| sistpoty|work | jam: hm... might indeed be possible... I'll try s.th. | 18:13 |
| jam | sistpoty|work: so one workaround is to use a"lightweight" checkout, since that actually shares the branch and doesn't try to open the repo 2 times | 18:13 |
| jam | I believe you can do "bzr reconfigure --lightweight" in newer versions of bzr | 18:14 |
| jam | check "bzr help reconfigure" | 18:14 |
| sistpoty|work | jam: actually it was a leightweight checkout... | 18:14 |
| jam | I don't know why a lightweight checkout would do that... Are you sure the branch it is a checkout of isn't bound to another branch in the repository? | 18:16 |
| sistpoty|work | however there might be s.th. wrong in the first place, since I've got a .bzr directory at /srv/revu.repo and my checkout was lying in /srv/revu.repo/sistpoty (from /srv/revu.repo/production) | 18:16 |
| jam | a few "bzr info" calls might help sort things out | 18:16 |
| sistpoty|work | jam: hm... so /srv/revu.repo/production is a branch from shared repository: /srv/revu.repo... and I had a leigthweight checkout in /srv/revu.repo/sistpoty from /srv/revu.repo/production, when the error occured | 18:23 |
| sistpoty|work | jam: however doing that checkout from a different directory solved the problem, thanks! | 18:24 |
| jam | sistpoty|work: I'm glad you got it sorted out. Though I'm guessing you might want to post a bit of a comment on the bug | 18:25 |
| jam | just to remind us all that it is still present | 18:25 |
| sistpoty|work | jam: will do, once I'm home from work... thanks again! | 18:25 |
| jelmer_ | reggie: hi | 18:41 |
| reggie | jelmer_, hey. | 18:42 |
| reggie | was just about to get a bite to eat and then I had another svn-import issue for ya | 18:42 |
| === maw is now known as mw | ||
| jelmer_ | reggie: I'll be away in a couple of minutes as well, back at ~8:30 PM (CET) | 18:43 |
| reggie | jelmer, bac | 18:51 |
| reggie | you have to leave now | 18:51 |
| reggie | I think you can answer my svn-import question pretty quick | 18:52 |
| synic | abentley: that developer is back online with information about what corrupted that branch | 19:44 |
| fbond | Hi, I ran out of memory trying to bzr branch an svn repo... Does svn-import handle this situation better? | 20:11 |
| === ja1 is now known as jam | ||
| === jelmer_ is now known as jelmer | ||
| bob2 | fbond: upgrading your python subversion bindings might help | 20:27 |
| lifeless | moin | 20:42 |
| thatch | howdy | 20:42 |
| === Gwaihir_ is now known as Gwaihir | ||
| === asak_ is now known as asak | ||
| === kiko is now known as kiko-afk | ||
| === doko_ is now known as doko | ||
| reggie | jelmer, you back? | 22:23 |
| jelmer | reggie: hi | 22:24 |
| reggie | jelmer, my question is about the revision id mapping | 22:30 |
| reggie | I want the bzr tree to be separate. I won't be pushing or pulling to/from the svn tree | 22:31 |
| reggie | but when my svn branch moves from trunk to branch, then the imported bzr tree uses different revision ids. so different branches don't merge right | 22:31 |
| reggie | maybe I did something wrong? | 22:32 |
| jelmer | reggie: how do you mean different revision ids? | 22:32 |
| jelmer | reggie: Every revision has its own revision id | 22:32 |
| jelmer | which should be unique | 22:32 |
| reggie | right. I use the trunk scheme so I work on trunk until I release a product at which point I branch it. pretty standard | 22:32 |
| reggie | so my product has branches 5.0, 5.1, 5.2, and trunk | 22:33 |
| reggie | trunk being what will be 5.3 | 22:33 |
| jelmer | reggie: in /trunk and /branches/5.0, /branches/5.1, etc? | 22:33 |
| reggie | right | 22:33 |
| jelmer | I don't see the problem | 22:33 |
| reggie | as we talked about yesterday I had to individually import the branches because my 1.0 branch shows that bug | 22:34 |
| reggie | so I did --prefix=branches/5 on my import | 22:34 |
| reggie | and it seemed to do what I wanted | 22:34 |
| reggie | now what I expect to be able to do is | 22:34 |
| reggie | when I make a change in 5.0, I expect to be able to commit it and then pull that change up into 5.1 and then pull from 5.1 into 5.2 | 22:35 |
| mtaylor | reggie: I expect the same thing | 22:35 |
| jelmer | reggie: You mean merge, not pull | 22:35 |
| mtaylor | reggie: hello, btw | 22:35 |
| reggie | jelmer, ok. I'm coming from bk so forgive my terminology ignorance | 22:35 |
| reggie | mtaylor, hey | 22:35 |
| jelmer | reggie: unless 5.0 and 5.1 contain *exactly* the same data, and | 22:35 |
| reggie | ok, so I do a merge from 5.1 to 5.2 and it shows *lots* of changes (it shouldn't) | 22:36 |
| reggie | so I worked with it with chad miller (not sure if you know him) | 22:36 |
| reggie | and it seems that bzr thinks that the last common revision was 384 (in my case). the last revision in 5.1 was like 490 | 22:37 |
| jelmer | reggie: It will merge from the latest common revision between 5.1 and 5.2 | 22:37 |
| jelmer | reggie: is this a public repository? | 22:37 |
| reggie | jelmer, we have a public copy of it yes | 22:38 |
| reggie | yes, I know what the merge will do but bzr is trying to merge > 100 changes. months and months of work mainly because the revision ids don't match | 22:38 |
| jelmer | reggie: What's the URL of that repository? If I can have a look at the actual data it may be a bit easier to comment | 22:39 |
| reggie | because it was at revision 354 that 5.1 moved off trunk and into branch | 22:39 |
| reggie | just a sec | 22:39 |
| reggie | http://svn.mysql.com/svnpublic/connector-net/ | 22:39 |
| reggie | mtaylor, feel free to stop me if you have this already figured out :) | 22:40 |
| mtaylor | reggie: nope. haven't even looked at it | 22:40 |
| reggie | grr. mplayer won't play on my second monitor | 22:40 |
| mtaylor | reggie: is this after doing an svn-import ? | 22:40 |
| mtaylor | that's annoying | 22:41 |
| reggie | mtaylor, yes | 22:41 |
| mtaylor | reggie: how did you do the merges from trunk to 5.1 while it was in svn? | 22:41 |
| mtaylor | like, once you cloned off trunk to 5.1 at rev 354 | 22:41 |
| reggie | mtaylor, never from trunk to 5.1 | 22:41 |
| reggie | always up | 22:41 |
| reggie | from 5.0 to 5.1, 5.1 -> trunk, etc | 22:42 |
| mtaylor | so, you cloned 5.0 from trunk at one point... and then at a later point you cloned 5.1 from trunk | 22:42 |
| mtaylor | right? | 22:42 |
| reggie | mtaylor, we're talking svn here so no cloning | 22:42 |
| mtaylor | (sorry - _really_ using all the wrong words here) | 22:42 |
| mtaylor | sure | 22:42 |
| reggie | with svn you work on trunk and then at some point you branch (which basically just copies your work to another dir) | 22:43 |
| mtaylor | right... but when you made a change in the 5.0 branch in svn... how did you propagate that to the 5.1 branch? | 22:43 |
| reggie | svn merge | 22:43 |
| mtaylor | hm | 22:43 |
| jelmer | reggie: svn merge doesn't store any information | 22:43 |
| jelmer | reggie: merge tracking information that is | 22:43 |
| reggie | jelmer, I know | 22:43 |
| reggie | svn merging is crap | 22:44 |
| * mtaylor giggles | 22:44 | |
| reggie | one of the reasons that I want to move to bzr even though we are not done with svn | 22:44 |
| reggie | let bzr do the heavy lifting regarding merges | 22:44 |
| jelmer | reggie: what's wrong with merge showing a lot of changes | 22:47 |
| jelmer | there are a lot of revisions that are in 5.1 and not in 5.2 | 22:47 |
| jelmer | uhm, sorry | 22:48 |
| jelmer | 2 revisions are | 22:48 |
| jelmer | argh | 22:48 |
| reggie | are you using bzr-svn to see that? | 22:49 |
| jelmer | no, svn log | 22:49 |
| jelmer | yes, there are *a lot* of revision that are in 5.1 and not in 5.2 | 22:49 |
| reggie | well, svn merge allows me to cherry pick revisions. each branch has things (deletes, renames, etc) that I don't want merged up | 22:50 |
| reggie | so I skip those | 22:50 |
| jelmer | everything between r825 and 1175 that affects /branches/5.1 | 22:50 |
| jelmer | is that what you were expecting as well? | 22:50 |
| reggie | no that's not right. | 22:51 |
| jelmer | reggie: what are you expecting it to do then? r824 is the last common ancestor of both 5.1 and 5.2 | 22:53 |
| wolever | Would anyone happen to know why I'm getting "SubversionException: ("Unrecognized URL scheme for 'https://example.com/svn/project'", 170000)" using bzr-svn to get the 'svn status' of a repository? | 22:53 |
| jelmer | wolever: what version of bzr-svn are you using? | 22:53 |
| wolever | most recent -- 0.4.7 | 22:54 |
| jelmer | is your subversion library built with ssl suppotr? | 22:54 |
| reggie | perhaps I've used svn merge wrong but you can see that revision 1165 is a commit to 5.2 that is the merging of revision 1104 to 1161 | 22:55 |
| wolever | Yup -- I just re-built svn from trunk, and when I run "svn status" or "svn up" from the same directory, it doesn | 22:55 |
| wolever | 't have any problem | 22:55 |
| reggie | svn is saying that 824 is the last common ancestor because that is the last time they both sat on trunk | 22:55 |
| jelmer | reggie: yes, and that is what bzr will do as well. That's the last common ancestor. I don't see how it can be more intelligent than that without extra cherrypicking tracking data | 22:56 |
| wolever | Err, odd -- svn up just hangs, then later fails. Time to re-build with ssl :\ | 22:56 |
| jelmer | reggie: bzr's merge should be able to deal with similar changes in both branches pretty well though | 22:59 |
| chadmiller | Hi reggie. If you're happy with the states of both trees right now, then you /could/ "cd higher; bzr merge ../lower;" and then "bzr revert .; bzr commit -m 'scorched-earth terrible idea from cmiller'" , which (IIRC) should prepare the higher tree so that it can accept merging patches from here on. | 23:02 |
| reggie | could line endings be tripping it up? I get 77 conflicts but many of them have no conflict markers | 23:02 |
| * reggie needs a good conflict editor for bzr | 23:03 | |
| chadmiller | Reggie on win32, yes? | 23:03 |
| bob2 | ediff! | 23:03 |
| reggie | it must be line endings because I see no conflict markers | 23:04 |
| * reggie assumes the file.this is the merge attempt | 23:04 | |
| chadmiller | No, just "file" is. | 23:04 |
| reggie | ahh | 23:04 |
| chadmiller | foo.this is the previous version here. | 23:04 |
| chadmiller | It makes sense with "other". | 23:05 |
| reggie | chad, you said that approach would cause history issues | 23:05 |
| chadmiller | It would duplicate the history, yes. "log" would be much longer. "vizualize" (from the GTK plugin) would have one more parallel line up to now, where it would rejoin the trunk. | 23:07 |
| chadmiller | It's not perfect, but it may not be awful. I bring it up again mostly to test the opinion of Bazaarkers here. | 23:08 |
| reggie | wait. this is stupid. | 23:08 |
| poolie | hi chad | 23:08 |
| jelmer | reggie: Yes, it could very well be line endings | 23:08 |
| reggie | I need to just take the current files on all the conflicts | 23:08 |
| reggie | and then mark them as resolved | 23:08 |
| jelmer | bazaar badly needs eol support :-( | 23:08 |
| chadmiller | Hiya poolie. | 23:08 |
| jelmer | uhm, eol *conversion* support | 23:08 |
| reggie | eewww. you mean it doesn't | 23:08 |
| jelmer | our lines do actually have ends :-) | 23:08 |
| chadmiller | reggie: Beware of successful merges not being what you intend, then. | 23:10 |
| chadmiller | "bzr revert ." is probably better. | 23:11 |
| reggie | chadmiller, right. was about to do a svn diff to see what the successful merges actually did | 23:12 |
| reggie | I wonder if I could avoid the history problem by using svn revert to revert all the successful merges, take the current file on all conflicts, and then bzr commit | 23:12 |
| reggie | bzr shouldn't know the diff | 23:12 |
| reggie | unless it gets confused by me reverting under it's nose | 23:13 |
| vinc456 | hi, i'm trying to connect to my bzr repository from a windows machine. The ssh server is configured to only and i have configured my settings as per "http://bazaar-vcs.org/Bzr_and_SSH". I'm unable to specify my login/username though | 23:13 |
| reggie | since merge and commit are separated should be ok | 23:13 |
| chadmiller | vinc456: What "url" are you specifying? | 23:14 |
| vinc456 | C:\Program Files\Bazaar\test>bzr branch sftp://ucalgary.hopto.org:9922/var/www/4 | 23:15 |
| vinc456 | 71Project/trunk | 23:15 |
| vinc456 | the connection is made as i can see it in the ssh logs | 23:16 |
| vinc456 | but something assumes that i would to log in with the username "vincent" | 23:17 |
| CardinalFang | Yes. Does no sftp://vinc@ucalgary work? | 23:17 |
| vinc456 | and no such user exists on the system | 23:17 |
| vinc456 | ok that worked | 23:17 |
| vinc456 | thanks! | 23:17 |
| === spiv_ is now known as spiv | ||
| vinc456 | i believe there was a script to configure so that users would not necessary need a shell account on the host machine to check out from the repository. Does anybody remember what it was called off hand? | 23:21 |
| beuno | vinc456, can't you just branch through http? | 23:22 |
| vinc456 | i didn't think that bzr supported commits via http | 23:23 |
| beuno | vinc456, absolutely | 23:23 |
| beuno | http, sftp, ssh, bzr (it's own protocol) | 23:23 |
| vinc456 | i will try http then, thanks | 23:24 |
| beuno | np | 23:24 |
| jam | vinc456: contrib/bzr_access is also available | 23:24 |
| jam | but it uses ssh keys | 23:24 |
| vinc456 | the server only accepts ssh keys so that will not be a problem | 23:25 |
| jam | so you have 1 account that people can share, but it is limited to only running bzr | 23:25 |
| jam | so it isn't a full access shell account | 23:25 |
| vinc456 | perfect, that is exactly what i'm looking for | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!