=== 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
lifelesspoolie: re 1.2: the launchpad tests are still broken02:31
lifelesspoolie: I think this is release critical02:32
lifelesspoolie: also there are other critical bugs IIRC02:32
lifelesspoolie: see scrollback03:05
=== poolie_ is now known as pooliex
abentleylifeless: I profiled a launchpad checkout with my fast-iter-changes code, and index.iter_entries was only 24%.  file.seek was 31.1903:09
lifelessabentley: I think lsprof islying03:10
lifelessseek shouldn't be doing IO :)03:10
abentleyWell, no, but it must be doing something...03:12
abentleyIt's being called 14, 308 times.03:13
bignosemy revspec fu is failing me03:21
bignose'bzr diff --revision "date:2008-01-28..before:date:2008-02-03" fails03:22
bignosebzr: ERROR: Invalid revision-id {None} in KnitRepository('file:///home/benf/Projects/.bzr/repository/')03:22
bignosepresumably because it doesn't have any revisions *on* 2008-02-0303:22
bob2what a friendly error03:23
bignosebut I'm specifically asking for all revisions *before* that date, so I don't think it should spit an error03:23
bignose$ bzr --version03:23
bignoseBazaar (bzr) 1.1.0.candidate.103:23
bignosethis is being run from an automated script, that doesn't know what the last date in the branch is.03:23
bignosehow can I supply a "date:foo..before:date:bar" range without that error?03:24
lifelessbignose: strange, perhaps before:date:2008-01-29 ?03:24
bignoselifeless: I'm not sure what you're asking. the date range I have is "date foo, through to before (foo + one week)"03:25
bignoseI have no way of knowing that (foo + one week) is the last date, without a lot of mucking about03:25
bignoses/is the last date/is *past* the last date/03:25
lifelessbignose: 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 match03:25
bignoselifeless: that's exactly why the range I gave above is bounded by "..before:date:2008-02-03"03:26
lifelessbignose: you're not using before on both sides though are you?03:26
lifelesswhich is what I was suggesting03:27
bignosebut, AFAICT, it's the upper bound that causes it to fail03:27
bignosebecause the range "date:2008-01-28..-1" works fine03:27
lifelessin which case, welcome to bugs03:27
lifelessplease file one :)03:27
bignoseokay. someone else will need to do that, because Launchpad doesn't let me file bugs without creating an account.03:28
lifelessneither does bugzilla, or trac, nor nearly any other bugtracker though03:30
lifelessso its a bit of a specious argument against using it :)03:31
bignosemost good ones allow bug submission via email03:31
lifelessI just submitted that bug by email03:31
bignoseby email, without requiring specific registration with the system03:31
lifelessI'm only aware of one system that allows that - debbugs03:32
bignoseanyway: thank you for submitting the report03:32
lifelesspoolie: did you see my comments on 1.2 ?03:32
lifelessbignose: no problem03:32
bignosedebbugs, roundup, gnats, ...03:33
lifelessI would never call gnats a good system.03:34
lifelessroundup I haven't used enough to comment on03:40
ubotuNew bug: #191156 in bzr "bug in revision specs before:date: ?" [Undecided,New] https://launchpad.net/bugs/19115603:41
abentleylifeless: What was that memory ceiling you were suggesting for iter_files_bytes?03:47
lifelessabentley: 10M or something03:58
lifelesson a 100M tree thats 10-20 * latency multiplier, which is tolerable03:58
lifelessand on most trees its a tiny fraction03:58
lifelesssingle files > that have to exceed it of course03:58
abentleyYes.  Actually with a 100K ceiling, local checkouts of bzr.dev are fast.04:00
lifelessI'm thinking network to some degree. but lets say 1MB then04:00
lifelessremembering that some exceptional trees (moz) may actually need 10M or something04:00
Toksyuryelbignose: bugtrackers are a major spam magnet, requiring accounts help to limit it04:01
abentleySure.  Easily tweaked.04:01
abentleylifeless: Need it because of individual file size?  That's covered.04:01
lifelessabentley: no, file count04:01
abentleyI'm not sure whether it would be much faster even with a much larger buffer.04:02
lifelessabentley: I'm thinking sftp lightweight branches/ shallow checkouts04:03
lifelessabentley: unrelated question, when I have shallow branches working I'm thinking that 'bzr checkout foo' should create a shallow branch04:03
lifelessabentley: so the difference between that and --lightweight is whether data accumulates locally or not04:03
lifelessabentley: and have an option '--deep' or --full or something, to get the current deep copy04:04
abentleyThat sounds reasonable to me.04:04
abentleyI think lighweight is too light for a default when dealing with remote branches.04:05
abentleyBut when dealing with remote branches, lots of people would complain if it was too heavy, also.04:06
lifelessso I htink a good default is a shallow branch with one copy of each text04:07
lifelessfor pushing I think an option to say 'cheap', and then a shallow branch with unique deltas only04:07
i386lifeless: cant find the fab source code!04:08
abentleylifeless: I would consider going 10% higher than one-copy-of-each, just for the improved merging.04:08
lifelessi386: https://edge.launchpad.net/fab04:09
lifelessabentley: one copy of each will have up to 50 or so texts due to the delta chains04:09
lifelessabentley: so on merge we'll often only need to grab the revision data04:09
reggiewhy would I be getting a repo not compatible error on a bzr branch?04:09
lifeless(as inventories are delta'd too)04:09
lifelessreggie: bzr-svn has been used on one end04:10
reggielifeless, hmm.04:10
lifelessabentley: What I mean here, is yes - I've considered that, and think it'll be ok04:10
lifelessreggie: the bzr svn faq talks about this04:10
reggieok, let me go look04:11
abentleylifeless: Probably.04:11
reggielifeless, not sure that is it. let me show you the error04:12
abentleyThe issue is, what if the "bound" repo is unreachable, and the repo you're merging doesn't have those revisions.04:12
reggiepack-0.92 is the latest repo format?04:14
reggieno.  rich-root is latest I guess04:14
reggiehmm.  both local and remote repo report as pack-0.9204:16
abentleyreggie: Not sure what you mean by latest.04:16
abentleyCurrent default is pack-0.92.04:17
abentleyrich-root and rich-root-pack are newer than that.04:17
reggieabentley, well I did a svn-import on ubuntu and then did a push from that repo onto a different server04:17
reggieso far so good04:17
reggienow I'm trying to do a bzr branch from that second repo onto a windows machine and get a repo not compatible04:18
reggiethe error says something like KnitPackRespository(u'file:///<path>) is not compatible with respository RemoteRepository(bzr+ssh://...)04:19
abentleyRight.  So you don't really care what's latest, just what's compatible.04:19
abentleyrich-root-pack ought to be compatible.04:20
reggieI pushed from a rich-root to a 0.92. now I'm trying to branch from a 0.92 to a 0.9204:20
reggiehmm.  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 works04:22
abentleyWell, 0.92 is compatible with 0.92, so I can't see causing the error you're seeing.04:23
reggieI think I found the problem.  my repo still have parent set as the svn parent04:23
abentleybzr-svn requires a rich-root format.04:23
abentleyAt least the 0.4 series does.  the 0.3 series didn't.04:24
reggiecan I take a branch that is parented on svn+ssh and break the relatinoship or do Ihave to re-import?04:25
lifelessabentley: shallow branches will be unusable offline in the first instance, because they don't consider the non-local data to be ghosts.04:25
abentleyreggie: The parent is just the default pull location.04:25
abentleyYou can set it to anything with pull --remember.04:26
abentleyBut it really shouldn't matter.04:26
reggieoh.  so branches can have their own format?  I thought that was repo wide04:27
abentleyIt is repo wide.  The parent has nothing to do with the format.04:28
reggieso is rich-root unstable?04:28
reggieshould it be avoided currently?04:29
reggiegot it.04:30
reggieabentley & lifeless: thx04:30
abentleyreggie: rich-root is stable, in the sense that it will not change.04:44
pooliexlifeless, abentley, i would say bug 189757 is high, but not critical for 1.204:44
ubotuLaunchpad bug 189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/18975704:44
abentleypooliex: that was my feeling.04:45
pooliexdo you think it'll be reproducible04:45
abentleypooliex: 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
pooliexso you could deterministically reproduce that interruption from a test script, but it's not certain people will hit it04:49
lifelessI think folk have on lp04:50
pooliexlifeless, would you please make a 1.2 pqm branch for me?04:51
=== asac_ is now known as asac
lifelesspooliex: done04:55
pooliexshould i register it?04:56
lifelessunder ~bzr yes :005:06
abentleypooliex: The necessary ingredient is a .bzr control directory with no branch directory in it.05:08
lifelessright, patch away05:23
lifelesspooliex: I'm done for the day; any last requests ?05:23
pooliexlifeless, so that branch exists but is empty?05:28
pooliexlifeless, just wanted to check with you that i'm planning to fix only the launchpad plugin bug, and the dirstate bug, for 1.2rc105:28
pooliexhave just sent mail to that effect05:29
pooliexcan't think of anything else05:29
lifelesspooliex: the branch exists and I've pushed bzr's trunk into it05:35
lifelesspooliex: I would have to look to find other thins to do :)05:35
pooliexyes, i see now05:35
pooliexjust a lag in lp between mirroring and scanning05:36
pooliexhave a good night!05:36
lifelessjust ordred a new dishwasher :)05:36
i386lifeless: what was wrong with the old one?05:42
lifelessI'm getting a little rusty.05:42
i386lifeless: :)05:43
abentleylifeless: 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
lifelessabentley: I think its easier to get to checkouts that require you online; so we can and should do that first06:42
lifelessabentley: we can look at soft-handling missing-key errors later IMO06:42
=== joabr is now known as jabr
=== jabr is now known as joabr
=== joabr is now known as jabr
ubotuNew bug: #191203 in bzr "Error at second commit in same dir" [Undecided,New] https://launchpad.net/bugs/19120309:45
=== awilkins_train is now known as awilkins
PengThe "0.12-release-process" blueprint depends on nested trees. Oops? :)10:36
=== mrevell is now known as mrevell-lunch
=== kiko-afk is now known as kiko
=== mrevell-lunch is now known as mrevell
Lunkwilli'm looking at http://bazaar-vcs.org/Specs/Tagging which says this was implemented in 0.1513:04
Lunkwillyet that's the only doc I can find that mentions versioned tags13:04
datotags are not versioned13:05
Lunkwilliow, tags aren't implemented according to the spec I just pasted?13:05
datodoesn't seem to be the case, indeed13:07
jameshLunkwill: there is some documentation on tags in the users guide13:07
Lunkwilljamesh: yes. basically it says "use bzr tag to tag" and "use bzr tags to list tags"13:09
Lunkwilljust 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 to13:12
=== AfC is now known as AfC|zzz
=== kiko is now known as kiko-fud
AnMasteris there a command like git bisect for bzr? that is perform a binary search for what revision introduced a bug in a simple wway15:54
AnMasterif 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
hmelandAnMaster: See https://launchpad.net/bzr-bisect/ (which I have zero experience with)16:02
bob2bzr revert -r XXX16:02
reggieanyone use (or write) svn2bzr?16:16
reggieor any subversion import specialists around?16:18
reggieanyone 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 jelmer16:29
ubotuSorry, I don't know anything about seen jelmer - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi16:29
reggie!tz jelmer16:30
ubotuSorry, I don't know anything about tz jelmer - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi16:30
ignasis there a way to perform something analogous to "svn import" using bzr?17:45
ignasi would like to get a repository with all the files in some directory without modifying that directory in any way ...17:45
luksnot sure what exacltly svn import does, but maybe: bzr add && bzr ci -m 'Import of ...'17:46
ignaslike bzr import /path/to/my/new/repo /path/to/stuff/i/have/readonly/access/to/17:46
ignaswell bzr init + bzr add creates a repository in the original place17:46
ignasand i'd like to avoid the "cp -r" part if it's possible17:46
* luks is a bit confused17:46
luksthat sounds like a branch, not import17:47
luksor is /path/to/stuff/i/have/readonly/access/to/ not a bzr branch?17:47
ignasyes it's not17:47
luksthen I guess bzr init/cp/bzr add/bzr ci is the only way17:48
ignasi see17:48
datoignas: bzrtools provides `bzr import`17:50
datoignas: which does what you want17:50
ignasdato: bzrtool17:51
ignasi mean thanks17:51
datoyou're welcome17:51
fullermdjam: Q for you when you have a minute...17:59
jamfullermd: go for it18:00
fullermdjam: Just curious as to whether the speedups you're doing on annotate would also speed up weave/knit merges.18:01
fullermdOr if they're just local to ann.18:01
jamI think there are bits to bothe18:02
jamsorry both18:02
jamI think Aaron made a case for LCA merge which is very similar to knit merge18:02
jamwhen there are multiple ancestors18:02
jamand is otherwise 3-way18:02
jamand does a little bit better about not needing to do full annotations.18:02
jamas for my changes..... if knit merge is implemented as "give me the full annotation, and then compute the merge" then yes, it would effect it18:03
jamso probably it would help, but I wouldn't guarantee anything just yet18:03
* fullermd nods.18:04
fullermdGood 'nuff for me.  Thanks.18:04
jamfullermd: do you use knit merge often?18:04
fullermdHardly ever.  I almost never hit something 3way doesn't handle just fine (or at least, when I do, knit doesn't help)18:04
fullermdJust something I wondered about skimming the mails about it.18:05
jamultimately, I think we'll need a cache of some sort18:07
jambecause history gets longer, and any annotation algorithm is generally going to just get solwer18:08
jamI've just been pushing that down the stack, since this code should be cleaned up anyway18:08
fullermdWell, 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|workhi, 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
beunosistpoty|work, you can break the lock with:"  bzr break-lock18:11
beunosome process must of hung while pushing/commiting18:11
sistpoty|workbeuno: nope, then the same error occurs again18:11
jamsistpoty|work: it sounds like you are working on a heavy checkout in the same repository18:11
jamaka "bzr init-repo repo; cd repo; bzr checkout a b; cd b; commit"18:12
jamwhich sounds like bug #9500418:13
ubotuLaunchpad bug 95004 in bzr "commit into checkout fails when shared repository used" [High,Confirmed] https://launchpad.net/bugs/9500418:13
sistpoty|workjam: hm... might indeed be possible... I'll try s.th.18:13
jamsistpoty|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 times18:13
jamI believe you can do "bzr reconfigure --lightweight" in newer versions of bzr18:14
jamcheck "bzr help reconfigure"18:14
sistpoty|workjam: actually it was a leightweight checkout...18:14
jamI 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|workhowever 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
jama few "bzr info" calls might help sort things out18:16
sistpoty|workjam: 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 occured18:23
sistpoty|workjam: however doing that checkout from a different directory solved the problem, thanks!18:24
jamsistpoty|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 bug18:25
jamjust to remind us all that it is still present18:25
sistpoty|workjam: will do, once I'm home from work... thanks again!18:25
jelmer_reggie: hi18:41
reggiejelmer_, hey.18:42
reggiewas just about to get a bite to eat and then I had another svn-import issue for ya18: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
reggiejelmer, bac18:51
reggieyou have to leave now18:51
reggieI think you can answer my svn-import question pretty quick18:52
synicabentley: that developer is back online with information about what corrupted that branch19:44
fbondHi, 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
bob2fbond: upgrading your python subversion bindings might help20:27
=== 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
reggiejelmer, you back?22:23
jelmerreggie: hi22:24
reggiejelmer, my question is about the revision id mapping22:30
reggieI want the bzr tree to be separate.  I won't be pushing or pulling to/from the  svn tree22:31
reggiebut when my svn branch moves from trunk to branch, then the imported bzr tree uses different revision ids.  so different branches don't merge right22:31
reggiemaybe I did something wrong?22:32
jelmerreggie: how do you mean different revision ids?22:32
jelmerreggie: Every revision has its own revision id22:32
jelmerwhich should be unique22:32
reggieright.  I use the trunk scheme so I work on trunk until I release a product at which point I branch it.  pretty standard22:32
reggieso my product has branches 5.0, 5.1, 5.2, and trunk22:33
reggietrunk being what will be 5.322:33
jelmerreggie: in /trunk and /branches/5.0, /branches/5.1, etc?22:33
jelmerI don't see the problem22:33
reggieas we talked about yesterday I had to individually import the branches because my 1.0 branch shows that bug22:34
reggieso I did --prefix=branches/5 on my import22:34
reggieand it seemed to do what I wanted22:34
reggienow what I expect to be able to do is22:34
reggiewhen 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.222:35
mtaylorreggie: I expect the same thing22:35
jelmerreggie: You mean merge, not pull22:35
mtaylorreggie: hello, btw22:35
reggiejelmer, ok. I'm coming from bk so forgive my terminology ignorance22:35
reggiemtaylor, hey22:35
jelmerreggie: unless 5.0 and 5.1 contain *exactly* the same data, and22:35
reggieok, so I do a merge from 5.1 to 5.2 and it shows *lots* of changes (it shouldn't)22:36
reggieso I worked with it with chad miller (not sure if you know him)22:36
reggieand it seems that bzr thinks that the last common revision was 384 (in my case).  the last revision in 5.1 was like 49022:37
jelmerreggie: It will merge from the latest common revision between 5.1 and 5.222:37
jelmerreggie: is this a public repository?22:37
reggiejelmer, we have a public copy of it yes22:38
reggieyes, 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 match22:38
jelmerreggie: What's the URL of that repository? If I can have a look at the actual data it may be a bit easier to comment22:39
reggiebecause it was at revision 354 that 5.1 moved off trunk and into branch22:39
reggiejust a sec22:39
reggiemtaylor, feel free to stop me if you have this already figured out  :)22:40
mtaylorreggie: nope. haven't even looked at it22:40
reggiegrr.  mplayer won't play on my second monitor22:40
mtaylorreggie: is this after doing an svn-import ?22:40
mtaylorthat's annoying22:41
reggiemtaylor, yes22:41
mtaylorreggie: how did you do the merges from trunk to 5.1 while it was in svn?22:41
mtaylorlike, once you cloned off trunk to 5.1 at rev 35422:41
reggiemtaylor, never from trunk to 5.122:41
reggiealways up22:41
reggiefrom 5.0 to 5.1, 5.1 -> trunk, etc22:42
mtaylorso, you cloned 5.0 from trunk at one point... and then at a later point you cloned 5.1 from trunk22:42
reggiemtaylor, we're talking svn here so no cloning22:42
mtaylor(sorry - _really_ using all the wrong words here)22:42
reggiewith svn you work on trunk and then at some point you branch (which basically just copies your work to another dir)22:43
mtaylorright... 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
reggiesvn merge22:43
jelmerreggie: svn merge doesn't store any information22:43
jelmerreggie: merge tracking information that is22:43
reggiejelmer, I know22:43
reggiesvn merging is crap22:44
* mtaylor giggles22:44
reggieone of the reasons that I want to move to bzr even though we are not done with svn22:44
reggielet bzr do the heavy lifting regarding merges22:44
jelmerreggie: what's wrong with merge showing a lot of changes22:47
jelmerthere are a lot of revisions that are in 5.1 and not in 5.222:47
jelmeruhm, sorry22:48
jelmer2 revisions are22:48
reggieare you using bzr-svn to see that?22:49
jelmerno, svn log22:49
jelmeryes, there are *a lot* of revision that are in 5.1 and not in 5.222:49
reggiewell, svn merge allows me to cherry pick revisions.  each branch has things (deletes, renames, etc) that I don't want merged up22:50
reggieso I skip those22:50
jelmereverything between r825 and 1175 that affects /branches/5.122:50
jelmeris that what you were expecting as well?22:50
reggieno that's not right.22:51
jelmerreggie: what are you expecting it to do then? r824 is the last common ancestor of both 5.1 and 5.222:53
woleverWould 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
jelmerwolever: what version of bzr-svn are you using?22:53
wolevermost recent -- 0.4.722:54
jelmeris your subversion library built with ssl suppotr?22:54
reggieperhaps 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 116122:55
woleverYup -- I just re-built svn from trunk, and when I run "svn status" or "svn up" from the same directory, it doesn22:55
wolever't have any problem22:55
reggiesvn is saying that 824 is the last common ancestor because that is the last time they both sat on trunk22:55
jelmerreggie: 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 data22:56
woleverErr, odd -- svn up just hangs, then later fails.  Time to re-build with ssl :\22:56
jelmerreggie: bzr's merge should be able to deal with similar changes in both branches pretty well though22:59
chadmillerHi 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
reggiecould line endings be tripping it up?  I get 77 conflicts but many of them have no conflict markers23:02
* reggie needs a good conflict editor for bzr23:03
chadmillerReggie on win32, yes?23:03
reggieit must be line endings because I see no conflict markers23:04
* reggie assumes the file.this is the merge attempt23:04
chadmillerNo, just "file" is.23:04
chadmillerfoo.this is the previous version here.23:04
chadmillerIt makes sense with "other".23:05
reggiechad, you said that approach would cause history issues23:05
chadmillerIt 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
chadmillerIt's not perfect, but it may not be awful.  I bring it up again mostly to test the opinion of Bazaarkers here.23:08
reggiewait.  this is stupid.23:08
pooliehi chad23:08
jelmerreggie: Yes, it could very well be line endings23:08
reggieI need to just take the current files on all the conflicts23:08
reggieand then mark them as resolved23:08
jelmerbazaar badly needs eol support :-(23:08
chadmillerHiya poolie.23:08
jelmeruhm, eol *conversion* support23:08
reggieeewww. you mean it doesn't23:08
jelmerour lines do actually have ends :-)23:08
chadmillerreggie: Beware of successful merges not being what you intend, then.23:10
chadmiller"bzr revert ." is probably better.23:11
reggiechadmiller, right.  was about to do a svn diff to see what the successful merges actually did23:12
reggieI 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 commit23:12
reggiebzr shouldn't know the diff23:12
reggieunless it gets confused by me reverting under it's nose23:13
vinc456hi, 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 though23:13
reggiesince merge and commit are separated should be ok23:13
chadmillervinc456: What "url" are you specifying?23:14
vinc456C:\Program Files\Bazaar\test>bzr branch sftp://ucalgary.hopto.org:9922/var/www/423:15
vinc456the connection is made as i can see it in the ssh logs23:16
vinc456but something assumes that i would to log in with the username "vincent"23:17
CardinalFangYes.  Does no sftp://vinc@ucalgary  work?23:17
vinc456and no such user exists on the system23:17
vinc456ok that worked23:17
=== spiv_ is now known as spiv
vinc456i 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
beunovinc456, can't you just branch through http?23:22
vinc456i didn't think that bzr supported commits via http23:23
beunovinc456, absolutely23:23
beunohttp, sftp, ssh, bzr (it's own protocol)23:23
vinc456i will try http then, thanks23:24
jamvinc456: contrib/bzr_access is also available23:24
jambut it uses ssh keys23:24
vinc456the server only accepts ssh keys so that will not be a problem23:25
jamso you have 1 account that people can share, but it is limited to only running bzr23:25
jamso it isn't a full access shell account23:25
vinc456perfect, that is exactly what i'm looking for23:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!