igcpoolie: ok. I actually think it's pretty straight forward to add deep history support to usertest so I'll do that today after kicking off a conversion00:00
lifelesspoolie: I think its interesting to have deep linear too; because many conversions will be like that00:00
lifelessand in the short term, most huge histories will be conversions00:01
foomyes, my repo came from svn, so it's essentially linear00:01
pooliei guess for ease of understanding the results we need to pick one main case to graph00:10
lifelessI would say rather that we should be repeating on the same graph00:11
lifelesswe might have N big graphs to test, all different00:11
poolietesting N could be good, i'm just a bit concerned that if we produce too much output data it will not be read00:11
lifelesswell whats the audience00:12
lifelesswill the audience read 1, or N, or none ?00:12
lifelessright now I don't look at usertest daily00:14
lifelessI only look at such things when I'm a) deciding what to put in my pipe, and b) evaluating how I'm doing with my current changes00:15
lifelessif you have someone who is trying to do a) on any of a number of scales, N graphs is little harder to read that 1, and better at detect regressions caused while operating on code for the case of b)00:16
lifelessI'll wager that you have a similar use pattern00:16
lifelessbut that Ian, who is focusing on a) in a broad sense, daily, looks at it quite frequently.00:17
lifelesshttp://www.smh.com.au/articles/2008/02/05/1202090393959.html <- hmm00:28
pooliei'm fixing a merge conflict to merge, and jam has a todo asking for the trace file to be line buffered so you can more easily read it00:29
poolieshould i do a trivial change to have a debug option to turn that on, or yagni?00:29
lifelessthe trace file is buffered right now right?00:30
lifelessfor performance00:30
poolieup to several kb, whatever is the python default00:30
lifelessI've had no trouble tailing it00:30
lifelessbut if we change it yes, it should be a flag00:31
poolieoh, actually the comment is wrong, it is always line buffered00:32
pooliewhich is fine00:32
pooliethanks Teddy! :)00:32
mattimustanghi, i'm looking at converting from svn to bzr. Does bzr support svn style properties?00:35
lifelessmattimustang: I answered your question before; did you not see the answers ?00:35
mattimustangsorry i missed it and lost it in scollback :(00:35
mattimustangso it doesn't support arbitrary properties like svn?00:36
lifeless10:39 < lifeless> some yes00:36
lifeless10:40 < lifeless> is this for 3rd party extension, or for file-ending support on windows etc?00:36
lifeless10:40 < lifeless> (that is are you asking about 'generic stuff' or specific features)00:36
lifeless10:41 < foom> it doesn't support keywords or eol-style00:36
lifeless10:41 < lifeless> foom: yet; I have a plan.00:36
mattimustangI have custom properties aside from what svn uses (keywords eol-style etc)00:37
lifelessper file or per commit ?00:37
mattimustangper file00:37
mattimustangfile metadata like unix permissions, owner, group00:37
lifelesswell I'm designing a plugin to store those precise attributes00:38
lifelesswith a lookaside structure from the core00:38
* jelmer wakes up00:39
lifelesswe have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}00:39
lifelessthis isn't entirely ideal, but making arbitrary properties DTRT all the time is rather tricky, when you have to consider performance-at-alarge00:40
mattimustangi really need the metadata to stay with the file it belongs to00:40
lifelessyes, what I describe does that00:40
lifelessfiles have uuid00:40
mattimustangif files move I don't want to have to update some other manifest elsewhere00:40
lifelessa rename does not change the uuid (which we call file_id)00:40
jelmerlifeless: wouldn't it make more sense to store it in a . file in the root of the tree?00:42
lifelessjelmer: that makes it a user file00:43
jelmerI wouldn't want to check out a 30000-revision branch with several thousand files that each have a couple of properties set00:43
lifelessjelmer: remember the trouble with altering the representation of .bzrignore00:43
foomso store it in a \0 file in the root of the tree? :)00:43
lifelessa) we reject that filename, b) its the same problem00:44
jelmerlifeless: .bzr/repository/fileprops.knit would be ok as well00:44
lifelessjelmer: a knit? wtf00:45
jelmerthat's also how i'd like to see .bzrignore support00:45
jelmerwell, a knit or a pack or whatever00:45
jelmerit can be in the pack file as well, depending on your repository type00:45
lifelessjelmer: in the broad sense you are saying 'this should be in the core'00:45
jelmerlifeless: Yes, I am.00:45
lifelessjelmer: and thats fine, I want to get something up and working as a plugin, then when its stable, design an appropriate extension to core to do it well.00:46
jelmerlifeless: ah, ok. I hadn't seen you say that anywhere yet. That makes sense though.00:46
lifelessas a plugin the goal is to work and be decoupled from repository format00:46
lifelessfigure out all the data needed, how it changes, what it needs. then design good storage.00:47
lifelessso I'm thinking it will be slowish as a plugin, but easy to tweak00:47
jelmerI would really like to avoid a "bzr setprop" kind of UI for setting these things btw00:48
lifelessoh I cannot tolerate that ui00:48
lifelessnever happen00:48
jelmerok :-)00:49
lifelessI mean, see my comments re the shell hook stuff00:49
mattimustangwhat would propose then?00:49
jelmerlifeless: I think being able to write python should not be a requirement for being able to write bzr hooks.00:50
lifelessmattimustang: well I made a suggestion, or do you mean about how to activate this feature for a branch ?00:50
lifelessjelmer: I think our hooks and hg/svn hooks are different beasts.00:51
jelmerlifeless: For commonly used hooks, those should definitely be in python.00:51
lifelessjelmer: our hooks are gateways into the core library; like svn's baton passing.00:51
mattimustangwell my original question was does bzr support it and it seems that it doesn't00:51
lifelessthe stuff you want should be done by specific adapters00:51
lifelessmattimustang: it has arbitrary properties that can be set per commit; you can build out what you want easily there00:51
mattimustanghow would you do that per file then?00:52
jelmerlifeless: For example, we check whether a commit message contains a specific line here at a svn repository00:52
lifelessmattimustang: I already described it; you seem to think it wouldn't work.00:52
jelmerlifeless: most people know shell and can write a two-line shell script that checks a commit message is valid.00:53
lifelessjelmer: thats fine; do an adapter like I posted to the list for running make check. Then most users can write such a two line shell script00:53
lifelessjelmer: this is entirely different from trying to write a FFI to shell for our hooks.00:53
mattimustangso that is still using svn main repo for checkins and hook script. ok that is fine i can understand that approach but what about going purely bzr?00:54
lifelessmattimustang: huh? what I described was using bzr00:54
foommy 2 line shell script for doing that exact function is actually a 116 line python script. :)00:54
jelmerlifeless: Which thread was this? I don't think I've seen that.00:54
foom43 lines of which are a function called "get_cmd_output" which I use to call "svnlook log" and "svnlook changed", since the server doesn't have python 2.4 (and thus the subprocess module), and popen.* are terrible00:56
jelmeryou mention posting a pre-commit-check hook in the "Enhancing hooks" thread, but I can't find it00:56
lifelessjelmer: 1202182868.659.14400:56
lifelessConfig.get_user_section api00:56
mattimustang"(11:39:13 AM) lifeless: we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}" is that what you are talking about?00:57
lifelessmattimustang: yes00:57
jelmerlifeless: I don't see how that is all that different from my shell hooks plugin00:58
jampoolie: I did intend to have bzr-log-rss as part of the bzr project. I just wanted to allow someone else to have access aswell. I did the same thing for bzr-pqm-devel since James didn't want to be in ~bzr00:58
pooliegot it00:58
lifelessjelmer: I didn't claim it was.00:59
lifelessjelmer: Ian posted work to create a generic FFI for our python hooks.00:59
lifelessjelmer: I think that that is a bad idea.00:59
jelmerlifeless: ahhh, ok. I see your point.01:00
lifelessin short - some hooks that work well available for shell - great.01:01
lifelessall hooks in shell - are you insane?01:01
jameshyou think multiple fork+exec's for common operations would be a performance problem?01:03
* fullermd is insane.01:03
lifelessjamesh: we'll only pay that when someone has chosen to use a shell hook01:03
jelmerlifeless: right, and there's not always an obvious conversion between python types and shell types..01:03
lifelessjamesh: so no, because we can and should also make it really easy to write absolutely trivial python hooks - by providing base class hook implementations that do most of the grunt work01:04
jameshlifeless: one thing that would be nice would be to centralise the hook registration APIs01:04
jameshlifeless: rather than doing some on SmartTCPServer.hooks, some on Branch.hooks, etc01:04
jelmerjamesh: even when done centrally, those hooks would still only apply to some objects01:04
lifelessjamesh: like the two like 'check a regex in the commit message' should be in python, about 8 lines - import regex, import a currier that takes a plugin name and looks for config stuff with that prepended, and then a simple 'get regex, execute it, return'01:05
jameshjelmer: I realise that.01:05
lifelessjamesh: I don't actually like a single global registry; what is better about it ?01:05
jameshlifeless: well, the current system kind of works against lazy_import01:06
jameshlifeless: if I want my plugin to hook the SmartTCPServer, then every invocation of bzr is going to import bzrlib.smart.server once my plugin is installed01:07
lifelessOTOH we wouldn't need lazy_import if python imports didn't suck so much01:07
lifelessso I have on my todo list to fix that for bzr01:07
lifelessand a pretty good idea about how01:07
lifelesswhat else?01:08
foomthere's already packages which implement lazy module importing01:08
jameshlifeless: I guess that's my main complaint.  A central hooks registry was a solution to that, but you've obviously thought of some alternatives that might be better01:08
yaccpkg_resources entry points?01:09
jameshlifeless: actually, the other one is discoverability of hooks01:09
lifelessjamesh: I'd like bzr help plugins/hooks to dump them all01:10
lifelessjamesh: I think thats thats nicer because it allows plugins to add hooks themselves too01:10
lifeless(not that a central place prohibits that, but because it doesn't lend it self to it quite as nicely if you think about it this way)01:11
jameshat the moment you have to dig through the code to find out where to register your hook, what the name of the hook is, and what arguments it should expect01:11
lifelessyes, that sucks01:11
lifelessalso debug.debug_flags has the same problem01:11
=== jam_ is now known as jam
* igc food02:39
=== mw is now known as mw|out
* spiv -> late lunch04:04
abentleyCan I not join ~bzr-log-rss-devel please?  I get enough spam from Launchpad as is.04:13
abentleyby spam, I mean bugs on bzr-eclipse, bugs on bzr-webserve, branchfeed, etc.04:15
abentleyThese are not projects I have ever been interested in.04:15
Alohawhen i "man bzr" i get this weird output http://www.pastebin.ca/89350604:35
beunoAloha, that's wierd, me too04:35
beunobut if I have my terminal maximized, it doesn't happe04:36
beunoAloha, you should report the bug to the Ubuntu package (might also happen in Debian, dato?)04:37
beunoAloha, that would be https://bugs.launchpad.net/ubuntu/+source/bzr/04:38
Alohabeuno, thnx04:38
beunoI'm going to bed now, I swear  :D   g'night all04:39
beunoAloha, thanks for filing it!04:39
mtaylorabentley: I've got a question about the bundlebuggy workflow... that's the pqm, right? so once a merge is approved there, it gets merged to the tree?04:39
abentleymtaylor: No, they are separate systems.04:39
mtaylorok. so what happens once a merge is approved on bb?04:40
abentleymtaylor: A person with clearance submits it to PQM.04:40
mtaylorabentley: so there's still a manual step there then04:41
abentleymtaylor: Indeed, and frequently more.04:41
abentleyBecause many patches need to have conflicts fixed before they can merge cleanly.04:41
mtaylorand then the PQM system is the one that runs the unit tests before pushing to the tree, no?04:42
Alohabug filed04:42
abentleyYes.  Technically it merges, runs unit tests, then commits.04:42
mtaylorcool. makes sense04:42
abentleyThe conflict issue has gotten a lot better since we started doing NEWS alphabetically, though.04:43
abentleySo submit-from-bb isn't completely out of the question.04:44
mtaylorI tell you what, changelogs and news files really screw with merges in general :)04:44
abentleymtaylor: Someone should write a merge algorithm for NEWS and CHANGELOG files.04:44
mtayloryou could almost have bb submit and then ask for a re-submit if the merge didn't work.04:44
mtaylorabentley: I totally agree. I'd be in favor of that!04:44
mtaylorabentley: my debian/changelog files are always a problem04:45
abentleymtaylor: Great.  Let me know when you have something >;)04:45
mtaylorso bzr-pqm is just the submit-to-pqm plugin though, right? Is pqm itself released?04:45
abentleyYes it's an open project.04:45
mtaylorabentley: awesome. thanks04:48
bob2is there any support for plugging file-type-specific merge algorithms into bzr?04:49
=== asac_ is now known as asac
abentleybob2: No, but you can write your type-specific merge so that it falls back to merge3.04:50
abentleyGeneral merge algorithms are pluggable.04:50
mtaylorabentley: so what if bob2 wrote a file-type merge algorithm, and I wrote a debian/changelog algorithm, and I had both file types in my tree?04:52
abentleymtaylor: Obviously, it doesn't scale.04:52
abentleyI did some work on per-file merge algorithms, but I didn't nearly finish it.04:53
mtaylorI'd say I'd think about it further, but I'm like 12 deep on my stack of non-essential work at the moment anyway04:53
spivpoolie: a fix for bug 185394 is on the list, if you'd like to review it06:07
ubotuLaunchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,Fix committed] https://launchpad.net/bugs/18539406:07
fullermdOooh.  Purdy.06:09
pooliethanks spiv06:32
=== jam_ is now known as jam
mazzanethow do you get a diff of the local tree and the repository that includes any new files added locally?10:21
mtaylormazzanet: have you commited those files ?10:22
mazzaneti don't have commit access to the repository10:23
mazzanetie. i'm making a patch10:23
fullermddiff should do it just fine in general (though it won't for binary files).10:24
bob2"bzr diff" will show the difference between your current checkout and the main thing10:24
fullermdThe usual answer, though, is jut to commit in a local branch.  Then you can send a merge directive and keep all your metadata.10:24
bob2but this new-fangled distributed thing means you can create your own branch ;)10:25
mazzanetbzr diff isn't including the new files10:25
fullermdDid you 'bzr add' them?10:25
bob2(bzr add will work even if you can't commit)10:25
fullermdjblack: Oh, hey there.  Didn't see you come in.10:31
jblackI came in on tippy-toes. ;)10:31
jblackcprov too! wow11:35
cprovjblack: hi James. Good to see you again.11:36
* jblack gets amazed by the people he sees when he crawls out from under his rock11:36
jameshhi jblack11:36
jblackHey jamesh11:36
jameshjblack: and bob2 still has the hair ...11:38
jameshand denies that he plays goon of fortune11:38
=== mrevell is now known as mrevell-lunch
=== doko_ is now known as doko
abentleyjblack: Hi.12:47
abentleyWhat colour rock have you been hiding under?12:51
jblackA black one, of course12:52
jblackit sounded funnier in my head.12:52
kikohey jblack how's it going?13:01
=== mrevell-lunch is now known as mrevell
jblackPretty good.13:29
ubotuNew bug: #189567 in bzr "output to a terminal should default to using /usr/bin/pager" [Undecided,New] https://launchpad.net/bugs/18956713:31
=== zmanuel is now known as z-man
=== mw|out is now known as mw
=== _emgent is now known as emgent
=== brilliantnu1 is now known as brilliantnut
=== kiko is now known as kiko-fud
=== weltende is now known as welterde
=== statik` is now known as statik
synicanyone awake?15:12
synichow can I get bzr to mark files with the current revision number?15:12
Parker-hmmhh... like $rev$ or something?15:13
jamsynic: short answer, no15:14
jamlonger answer... http://bazaar-vcs.org/KeywordExpansion15:14
jamyou might look at "bzr version-info"15:14
jamBut it is more about putting it into another file15:14
jamATM we don't change files for you on commit15:14
Parker-hmmhh... in future... is it possible to lock files?15:15
Parker-if branch is checkouted15:16
Parker-(or binded)15:19
SpadsSo I once had infinity rattle off a zillion commands at me explaining how to do this, but short term memory's always the first to go...15:36
SpadsI've got a tree where I maintain an internal patch to upstream sources.  new tarballs appear periodically, and I want to just incorporate that stuff and keep my set of changes on top.15:37
Spadsinfinity said there was a "maintaining a patch" section in the docs, but I can't find it15:37
Spadshe mumbled about doing lots of imports from tarballs, but that seems to blat the whole tree out with the upstream files.15:37
SpadsHI!  I always swap "infinity" and lifeless in my head15:39
Spadshi lifeless15:39
Spadsthey're both so eternal15:39
jamSpads: there is http://bazaar-vcs.org/TrackingUpstream15:40
jamAnd I know there is "bzr import" provided by bzrtools15:41
jamGenerally, I would say you want to have a pristine branch of upstream15:41
jamwhich your work is derived from in another branch15:41
jamand then you go to upstream15:41
jamupdate to the latest tarball15:41
jamthen go to your branch15:41
jammerge in the changes15:41
jamgo on with your life15:42
jamalso describes that workflow15:42
jamonly with "upstream" being in svn15:42
Spadsokay, this is close to what we were doing already.  I may have misheard him as it sounded like he was talking about everything in-place15:42
jamSpads: he has a plugin to do that15:42
jambut I don't think it is fully released yet15:43
jamLast I read was that it needed a bit of polish, and should be released within the next month or so15:43
=== kiko-fud is now known as kiko
muszekhi... I have a local branch binded with a branch on a remote server.  I'm using bzr+ssh URI.  When commiting, I'd like the remote working directory to be updated at the same time... is it possible?  Right now I have to issue commit locally, wait till it's finished and issue "bzr update" command on the remote server (I want to skip that 2nd part)16:19
jelmermuszek: you can use the push-and-update plugin for that16:22
muszekjelmer: thanks16:25
muszekcan I specify the path that I want to run bzr commant at?  something like "ls -A /var/www" shows me stuff in a specified directory (not the one I'm currently at).  Say I'd like to run something like "bzr update /var/www/myapp"16:48
jelmerbzr update /var/www/myapp should work16:50
pygimuszek, yes, you can ;)16:50
muszekdamn... It does work... I must have messed up something before.  thanks and sorry guys.16:51
WonkoHi guys, I have a noob Q: I have a project on two machines that has a settings file that differs for these machines. Everything else is the same and needs to be kept in sync.16:51
pygimuszek, no worries ;)16:51
pygiWonko, you can ignore that settings file16:51
pygiWonko, bzr ignore [file]16:52
WonkoBut the settings file might change in the non-specific parts , is there a better way maybe?16:52
Wonkothought about ignoring, but it seemed unelegant ;)16:52
pygiWonko, perhaps you might want to split settings file to two separate files? One common, and one specific?16:53
pygiWonko, and just ignore the common one? :)16:53
Wonko@pygi: that sounds like a good idea. Mercurial has something called "Mercurial Queues" that allow me to "plug in" patches, which would sound ideal for my case. Does bzr have something like that?16:54
Wonko( Hg stuff: -> http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 )16:55
pygiWonko, gimme a moment to read it pls16:55
WonkoI'm still thinking about where to move to from CVS, bzr or Hg (or maybe darcs) ..16:55
Wonkosure, take your time, and THANKS!16:55
pygiWonko, per-se, I don't think bzr has something similar, however I believe a plugin like that could be written16:59
Wonkok, thanks so far!17:00
pygiWonko, thank you, and dont hesitate to ask if you have more questions :)17:01
foomi wish there was a way to have both, at once.17:01
fooma revision history of the changes i actually made, *and* a sensible split into patches of the same changes17:02
pygifoom, that approach doesnt scale .... i.e. see darcs :)17:02
foompygi: ...just because darcs doesn't scale doesn't mean what i want is impossible. :)17:02
pygitrue that foom :P17:03
pygifoom, you could write a bzr plugin that does that, anyway17:03
foomno i couldn't17:03
foommaybe someone could17:03
pygihehe :)17:03
foombut i don't even have a precise enough idea of what I want it to do to start.17:04
batomsis there a quick fix for a corrupted dirstate?17:08
batomsmine appears to be corrupt and i can't do anything on my tree17:08
luksa quick fix would be "bzr branch <broken> <fixed>"17:10
luksbut filing a bug report about that is probably a good idea, too17:10
pygiand we'd appreciate it :)17:10
batomsbranching doesn't work17:12
batomsBug #18601417:12
ubotuLaunchpad bug 186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/18601417:12
luksbranch fails with the same error as e.g. diff?17:13
batomspretty much everything fails17:14
batomsexcept for bzr info17:14
batomsand bzr log17:14
luksumm, I'm pretty sure branch used to work17:14
batomsthe last comment on that bug give the traceback17:14
batomsfor branch17:15
luksrm -r broken/.bzr/checkout && bzr branch broken fixed17:16
luksbut obviously backup the broken one before17:17
batomsbut then i lose track of the my recent uncommitted changes on the tree17:19
abentleybatoms: after that, you can move the .bzr/checkout from the new tree into the old one.17:20
batomsthat did the trick, thanks17:21
luksmaybe there should some hidden command to regenerate the dirstate from scratch17:21
foomjelmer: so i ran bzr svn-push, and it's been running for about 20 minutes so far, and I have no idea what it's doing or if it's going to work; is there any way to have it print some debugging info about what it's doing?17:22
jelmerfoom: If you run it with -Dcommit, it should write debug info to .bzr.log17:22
jelmersorry, ~/.bzr.log17:22
abentleyluks: The reason why branch breaks here now is that branch uses the local tree if it can to accelerate the process.17:22
abentleyluks: Perhaps we could hang it off 'reconcile'.17:23
muszekanyone knows some good article with arugments for using version control systems?17:59
abentleyluks, foom: push should work fine with a broken dirstate, so we didn't have to delete .bzr/checkout (though we would have had to replace it).18:11
Parker-hmmhh... trying to get bzr-svn work... and windows stuff is not aynmore located in http://home.comcast.net/~klight/bzr/18:24
=== abadger1999 is now known as abadger_afk
orospakrWhat is the proper way to migrate from git to bzr?  The git plugin throws a scary traceback when I try to branch a local git repo.  Tailor adds a gross SHA1 hash to the beginning of the commit messages.19:11
orospakrah, bzr-git has a separate branch with pull support.19:12
orospakrmarked "VERY EXPERIMENTAL", though...19:12
luksshould be fine for one-time conversion, I guess19:13
luks(that is, not incrementally sync the git branch)19:13
luislavenahello everybody19:15
luislavenaanyone knows why the smart server reports format unnamed when asked for info?19:15
luislavenabzr info . (pack-0.92)19:16
luislavenabzr info bzr://localhost => format: unnamed19:16
orospakrluks, yikes, it won't even load.19:35
orospakrAttributeError: 'GitRepository' object has no attribute 'base'19:35
beunoluislavena, you must have a pre 1.0 version of bzr, probably 0.919:36
beuno(on the smart server)19:36
luislavenabeuno: nop, both 1.119:36
luislavenaanyway, i'm running on the same machine :P19:37
luislavenaoh, btw, windows... :D19:37
beunoluislavena, does "bzr version" output the same in both?19:37
beunoluislavena, oh, and you probably have to provide a full path to the smart server19:38
luislavenabeuno: mmm, I chdir to the path I want to share... and all the other information it returns seems ok...19:40
luislavena(shared repository, branch info, even the push location)19:40
luislavenabeuno: nop, still the same, even with --directory pointing the same location.19:43
luislavenaweird, but it works.19:43
mtaylorum... wtf?20:06
mtaylorso, he did a bzr merge from a merge directive... then did a bzr revert, then a bzr pull, then a bzr commit20:07
mtaylorand this is the resulting change20:07
mwhudsonmtaylor: looks like the pull only brought in revision data, not text data20:11
=== kiko is now known as kiko-afk
=== Gwaihir_ is now known as Gwaihir
ubotuNew bug: #189709 in bzr "added-but-not-commited files which are removed go into weird limbo" [Undecided,New] https://launchpad.net/bugs/18970920:45
=== jam_ is now known as jam
johnnyhi, anybody familiar with the cvsps-import tool?21:15
johnnyi'm not sure if i have enough to make it happen, or i'm missing something21:15
johnnymy cvs fu is weak after years of not using it21:15
lifelessjohnny: sure what problem are you having though ?21:36
johnnyexactly how much access to the cvs tree do i need?21:36
johnnysince it doesn't seem to support :ext: or :pserver:21:36
lifelessAIUI a copy of it21:37
lifelessit needs to extract the ,v files21:37
lifelessbecause you are converting history21:37
fullermdI think you can use the non-local protocols if you --use-cvs or something.21:37
johnnyso, not just a checkout ?21:37
fullermdProbably a lot slower, though.21:38
lifelessjohnny: you can try --use-cvs as fullermd says21:39
lifelessand no, it does not operate off of a checkout, it operates off of the repo21:39
=== mw is now known as mw|food
johnnysyntax ?21:40
lifelessI've always used it on local paths21:43
johnnywell, i am working with a codecoop repository21:44
johnnya sf clone kinda thing21:44
johnnythe nightly does seem to have a CVSROOT dir in it21:44
fullermdDoesn't, you mean?21:45
johnnyit does21:45
lifelessuntar that backup somewhhere then :)21:45
johnnyyeah.. lemme try again21:45
fullermdOh.  Yeah, working off that would be a lot quicker than trying to do it remote   :)21:45
johnnyi had problems with it21:45
johnnywe're only talking less than 1000 revs, so either way.. no big deal21:45
johnnyno complicated branching21:45
johnnytime is not an issue21:46
johnnyhere's what i have21:48
johnnyohnny@beep ~/projects/redemmas $ ls infoshopkeeper-scm-2008-02-06/21:48
johnnyCVS  CVSROOT  infoshopkeeper21:48
johnnyi musta got the command sequence wrong before when trying this21:49
johnnyso this should be enough?21:49
johnnyohnny@beep ~/projects/redemmas $ bzr cvsps-import infoshopkeeper-scm-2008-02-06/ infoshopkeeper isk21:49
elmois there anyway to diff without a working tree?21:50
lifelesselmo: upgrade your bzr ;)21:51
johnnylifeless, is that good?21:51
lifelessjohnny: that looks right to me21:51
elmolifeless: >> 1.0 ?21:51
lifelesselmo: 1.1 I think - unless your 1.0 supports --old and --new21:51
elmolifeless: mmk21:51
mwhudsonit needs > 1.021:52
johnnythat's what i see21:52
lifelesswhats in CVSROOT ?21:57
johnnyCVS dir and a bunch of scripts it seems : commitinfo,checkoutlist,config,cvswrappers,loginfo,modules,rcsinfo , etc21:58
lifelessok its legit21:58
lifelesswhats in infoshopkeeper ?21:58
johnnyCVS, and the normal files21:59
lifeless,v ?22:00
lifelesssay you have NEWS22:00
lifelessis it NEWS22:00
lifelessor NEWS,v ?22:00
johnnyaha.. just NEWS22:00
lifelessso ,v is what CVS puts after its database files22:01
johnnyso it's not the full thing then22:01
lifelessthe CVSROOT files - commitinfo etc should also have commitinfo,v for the history of them22:01
lifelessindeed it does not look like your history22:01
lifelessthere should be some sort of backup tarball you can get22:01
johnnysuprised it even included the CVSROOT then22:01
johnnyi wonder if i can bug them for the whole thing22:01
johnnyit'd prolly be easier to just do it remotely tho22:02
lifelessjam: ^ can you advise ?22:02
=== mw|food is now known as mw
ubotuNew bug: #189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/18975722:46
jamlifeless, johnny: It certainly sounds like you are just getting a checkout, and not the actual repository22:50
jamIt is *close* to supporting :pserver: I just never took the time to actually do it22:51
jamas most people who are converting have access to their source22:51
jamand it is faster that way anyway22:51
johnnywell, i guess i could email the codecoop people for the source22:52
johnnybut.. then how can i later sync branches22:52
lifelesssoft failures for the lose:22:59
lifelessUnable to test plugin "launchpad": cannot import name test_lp_registration22:59
jamjohnny: well, you just ask them for another code drop :)22:59
lifelessour test suite is passing on pqm but the lp plugin tests are not running.22:59
jamjohnny: though if you want ongoing conversions, Launchpad does a pretty good job of it22:59
lifelessjam: ^ an example of why I don't like the dynamic test stuff you want to do :(22:59
johnnyi'd prefer not to rely on launchpad23:00
johnnyi'd like xmpp notices of commits , and other such things23:00
johnnyand i'd have to wait on them to provide it23:01
johnnythe whole point of this operation is to get a package that is relatively bigger than any of the other code stuff that we have23:01
jamlifeless: you just make them hard-failures if you have something which looks like "test_*" and doesn't actually load23:02
johnnyso i can test out bzr on it23:02
johnnyto see if it will work for us23:02
jamjohnny: well if that is all you want, the bzr source code is certainly available23:02
jamif you only have 1k commits, bzr is a lot bigger than that23:02
johnnyi mean with one of our own projects23:02
johnnyto test working with it in real life, with real commits :)23:02
jamjohnny: true, all of the bzr commits are faked :)23:03
jamanyway, I understand your point23:03
jamas for testing converting and then converting future work23:03
jamit should just amount to getting another copy of the ,v files, and running it again23:03
jamas long as you keep the conversion directory around23:03
johnnyi'll be happy when pserver happens23:04
johnnythen i can just pull into it23:04
lifelessjam: IMO anything we try to load must load or the tests must fail.23:04
johnnyok, i'm going to to get admin access to the project until pserver works23:07
jamjohnny: i don't expect to have time to work on ;pserver: for quite a while, but it shouldn't be hard if you want to play with it23:08
jamAnd I'm happy to give answer questions23:08
johnnyi'm still learning python23:08
johnnyi don't work in a software job except php web devel23:08
johnnybut our coffeehouse has about 5 projects we want to manage23:09
johnnyyes.. a coffeehouse with folks who write code for it :)23:09
johnnybookstore/coffeehouse really..23:09
lifelesssounds cool23:09
ubotuNew bug: #189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/18977123:31
abentleylifeless: Any luck with the index stuff?23:42
lifelessabentley: in progress23:49
pooliei'm going to read spiv's network patch now23:49
lifelessdon't byte off more ... groan sorry23:49
=== jam_ is now known as jam

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