=== 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
[02:31] <lifeless> poolie: re 1.2: the launchpad tests are still broken
[02:32] <lifeless> poolie: I think this is release critical
[02:32] <lifeless> poolie: also there are other critical bugs IIRC
[03:04] <poolie> (back)
[03:05] <lifeless> poolie: see scrollback
=== poolie_ is now known as pooliex
[03:09] <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:10] <lifeless> abentley: I think lsprof islying
[03:10] <lifeless> seek shouldn't be doing IO :)
[03:12] <abentley> Well, no, but it must be doing something...
[03:13] <abentley> It's being called 14, 308 times.
[03:21] <bignose> my revspec fu is failing me
[03:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:28] <bignose> okay. someone else will need to do that, because Launchpad doesn't let me file bugs without creating an account.
[03:30] <lifeless> done
[03:30] <lifeless> neither does bugzilla, or trac, nor nearly any other bugtracker though
[03:31] <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:32] <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:33] <bignose> debbugs, roundup, gnats, ...
[03:34] <lifeless> I would never call gnats a good system.
[03:40] <lifeless> roundup I haven't used enough to comment on
[03:41] <ubotu> New bug: #191156 in bzr "bug in revision specs before:date: ?" [Undecided,New] https://launchpad.net/bugs/191156
[03:47] <abentley> lifeless: What was that memory ceiling you were suggesting for iter_files_bytes?
[03:58] <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
[04:00] <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:01] <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:02] <abentley> I'm not sure whether it would be much faster even with a much larger buffer.
[04:03] <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:04] <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:05] <lifeless> cool
[04:05] <abentley> I think lighweight is too light for a default when dealing with remote branches.
[04:06] <abentley> But when dealing with remote branches, lots of people would complain if it was too heavy, also.
[04:07] <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:08] <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:09] <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:10] <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:11] <reggie> ok, let me go look
[04:11] <abentley> lifeless: Probably.
[04:12] <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:13] <abentley> s/bound/master/
[04:14] <reggie> pack-0.92 is the latest repo format?
[04:14] <reggie> no.  rich-root is latest I guess
[04:16] <reggie> hmm.  both local and remote repo report as pack-0.92
[04:16] <abentley> reggie: Not sure what you mean by latest.
[04:17] <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:18] <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:19] <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:20] <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:22] <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:23] <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:24] <abentley> At least the 0.4 series does.  the 0.3 series didn't.
[04:25] <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:26] <abentley> You can set it to anything with pull --remember.
[04:26] <abentley> But it really shouldn't matter.
[04:27] <reggie> oh.  so branches can have their own format?  I thought that was repo wide
[04:28] <abentley> It is repo wide.  The parent has nothing to do with the format.
[04:28] <reggie> so is rich-root unstable?
[04:29] <reggie> should it be avoided currently?
[04:30] <reggie> got it.
[04:30] <reggie> abentley & lifeless: thx
[04:44] <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:45] <abentley> pooliex: that was my feeling.
[04:45] <pooliex> ok
[04:45] <pooliex> do you think it'll be reproducible
[04:46] <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.
=== reggie is now known as reggie|away
[04:49] <pooliex> so you could deterministically reproduce that interruption from a test script, but it's not certain people will hit it
[04:50] <lifeless> I think folk have on lp
[04:51] <pooliex> lifeless, would you please make a 1.2 pqm branch for me?
=== asac_ is now known as asac
[04:55] <lifeless> pooliex: done
[04:56] <pooliex> should i register it?
[05:06] <lifeless> under ~bzr yes :0
[05:08] <abentley> pooliex: The necessary ingredient is a .bzr control directory with no branch directory in it.
[05:23] <lifeless> right, patch away
[05:23] <lifeless> pooliex: I'm done for the day; any last requests ?
[05:28] <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:29] <pooliex> have just sent mail to that effect
[05:29] <pooliex> can't think of anything else
[05:35] <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:36] <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:42] <i386> lifeless: what was wrong with the old one?
[05:42] <lifeless> I'm getting a little rusty.
[05:43] <i386> lifeless: :)
[06:18] <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:42] <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
=== joabr is now known as jabr
=== jabr is now known as joabr
=== joabr is now known as jabr
[09:45] <ubotu> New bug: #191203 in bzr "Error at second commit in same dir" [Undecided,New] https://launchpad.net/bugs/191203
=== awilkins_train is now known as awilkins
[10:36] <Peng> The "0.12-release-process" blueprint depends on nested trees. Oops? :)
[11:59] <lifeless> gnight
=== mrevell is now known as mrevell-lunch
=== kiko-afk is now known as kiko
=== mrevell-lunch is now known as mrevell
[13:04] <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:05] <dato> tags are not versioned
[13:05] <Lunkwill> iow, tags aren't implemented according to the spec I just pasted?
[13:07] <dato> doesn't seem to be the case, indeed
[13:07] <jamesh> Lunkwill: there is some documentation on tags in the users guide
[13:09] <Lunkwill> jamesh: yes. basically it says "use bzr tag to tag" and "use bzr tags to list tags"
[13:12] <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
=== AfC is now known as AfC|zzz
=== kiko is now known as kiko-fud
[15:54] <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*
[16:01] <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:02] <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:16] <reggie> anyone use (or write) svn2bzr?
[16:18] <reggie> or any subversion import specialists around?
[16:22] <reggie> anyone know if there is an easy way to adjust the rev-ids on a series of revisions?
=== hexmode` is now known as hexmode
=== kiko-fud is now known as kiko
[16:29] <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:30] <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
[17:44] <ignas> hi
[17:45] <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:46] <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:47] <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:48] <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:50] <dato> ignas: bzrtools provides `bzr import`
[17:50] <dato> ignas: which does what you want
[17:51] <ignas> dato: bzrtool
[17:51] <ignas> i mean thanks
[17:51] <dato> you're welcome
[17:59] <fullermd> jam: Q for you when you have a minute...
[18:00] <jam> fullermd: go for it
[18:01] <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:02] <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:03] <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:04]  * 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:05] <fullermd> Just something I wondered about skimming the mails about it.
[18:07] <jam> ultimately, I think we'll need a cache of some sort
[18:08] <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:09] <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:10] <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:11] <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:12] <jam> aka "bzr init-repo repo; cd repo; bzr checkout a b; cd b; commit"
[18:13] <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:14] <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:16] <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:23] <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:24] <sistpoty|work> jam: however doing that checkout from a different directory solved the problem, thanks!
[18:25] <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:41] <jelmer_> reggie: hi
[18:42] <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
=== maw is now known as mw
[18:43] <jelmer_> reggie: I'll be away in a couple of minutes as well, back at ~8:30 PM (CET)
[18:51] <reggie> jelmer, bac
[18:51] <reggie> you have to leave now
[18:52] <reggie> I think you can answer my svn-import question pretty quick
[19:44] <synic> abentley: that developer is back online with information about what corrupted that branch
[20:11] <fbond> Hi, I ran out of memory trying to bzr branch an svn repo... Does svn-import handle this situation better?
=== ja1 is now known as jam
=== jelmer_ is now known as jelmer
[20:27] <bob2> fbond: upgrading your python subversion bindings might help
[20:42] <lifeless> moin
[20:42] <thatch> howdy
=== 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
[22:23] <reggie> jelmer, you back?
[22:24] <jelmer> reggie: hi
[22:30] <reggie> jelmer, my question is about the revision id mapping
[22:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:47] <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:48] <jelmer> uhm, sorry
[22:48] <jelmer> 2 revisions are
[22:48] <jelmer> argh
[22:49] <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:50] <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:51] <reggie> no that's not right.
[22:53] <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:54] <wolever> most recent -- 0.4.7
[22:54] <jelmer> is your subversion library built with ssl suppotr?
[22:55] <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:56] <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:59] <jelmer> reggie: bzr's merge should be able to deal with similar changes in both branches pretty well though
[23:02] <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:03]  * reggie needs a good conflict editor for bzr
[23:03] <chadmiller> Reggie on win32, yes?
[23:03] <bob2> ediff!
[23:04] <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:05] <chadmiller> It makes sense with "other".
[23:05] <reggie> chad, you said that approach would cause history issues
[23:07] <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:08] <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:10] <chadmiller> reggie: Beware of successful merges not being what you intend, then.
[23:11] <chadmiller> "bzr revert ." is probably better.
[23:12] <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:13] <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:14] <chadmiller> vinc456: What "url" are you specifying?
[23:15] <vinc456> C:\Program Files\Bazaar\test>bzr branch sftp://ucalgary.hopto.org:9922/var/www/4
[23:15] <vinc456> 71Project/trunk
[23:16] <vinc456> the connection is made as i can see it in the ssh logs
[23:17] <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!
=== spiv_ is now known as spiv
[23:21] <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:22] <beuno> vinc456, can't you just branch through http?
[23:23] <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:24] <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:25] <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:26] <vinc456> perfect, that is exactly what i'm looking for