[00:00] lifeless: im going to build the api's of the filesystem draft pep on top of hg, svn, bzr and git for viewing revisions/building commits [00:01] to build a commit, use tree.commit() [00:01] thats what i use now [00:02] or if you like, you can use branch.get_commit_builder, which is a lower level API; under some specific circumstances it would be easier (e.g.. if you have a delta to apply) [00:02] I'm not sure what you mean when you say 'building commits' though [00:03] generally, if you have a tree on disk, its just 'tree.commit("foo")' and you're done [00:03] I don't really get why that requires /any/ bookkeeping [00:03] open a revision as a 'filesystem', do highlevel operations, commit the results [00:03] this is a repo op that doesnt involve workingtrees [00:04] for normal commits all i do is wt.commit [00:04] the workdir apis work quite well [00:04] now im dealing with creating and viewing history [00:05] ok [00:05] so for viewing history, the same readonly api as wt's have should work [00:06] unless you're doing remote operations nearly any api will be plenty fast [00:07] i plan to keep a larger distinction betwen network ops and local ops [00:08] and i need to figure what the heck to do with bzr repos, they actually do matter in some situations [00:09] if you want to be able to do arbitrary operations to create commits, MemoryTree should be fine - but it may be incomplete. Its a test helper, which, while correct, is not complete. It only does what we have needed it to do so far. [00:09] TreeTransform - I am not extremely familiar with it, but it is the core workhorse for merge/revert/checkout style operations. === verterok_ is now known as verterok [00:10] transform seemed pretty painfull to use [00:10] Using a TreeTransform on top of a revisiontree has a commit method these days, and as long as you use bzr 1.18 there are good checks that the deltas it commits will be consistent [00:11] it seems to make absolutely no sense, and the implementation is quite scarry [00:11] As I say I'm not extremely familiar with it. Its model is to assign a unique id for every operation in the transform, accumulate your changes, then check everything is consistent. [00:12] There is some confusion between fileids (inodes) and transform ids (temporary to the operation) [00:12] My tendancy, if I wanted to present a tree like interface, would be to improve MemoryTree [00:15] yeah, it seems more workable [00:42] spiv: are you around? === kiko is now known as kiko-afk [01:00] jam: I am. [01:00] hullo spiv [01:00] hey spiv [01:00] poolie: good morning [01:01] Just wanted to let you know that I'm interested in reviewing whatever you have for the inventory delta code [01:01] (as I finally got the bundle stuff finished) [01:01] I can review your last patch more thoroughly [01:01] or you can resubmit something if you've had a chance to look at why it wasn't actually being active [01:02] jam: I had a question [01:02] jam: review what I have, please. [01:02] the serializer that you use, what format does it actually output? xml? [01:02] [and if so, /which/ xml?] [01:02] spiv: ok. I still know that it doesn't actually work, but I can look over the code assuming it does :) [01:02] jam: I'm digging into why it doesn't seem to be used today, but it shouldn't make a large difference to the patch... [01:02] lifeless: xml v7 [01:02] IIRC [01:03] jam: Are you using CHKrepo._serializer.write_to_string ? [01:03] it is fairly obvious in the patch, because I had to change away from being v5 [01:03] lifeless: write_inventory_to_string, yes [01:03] I have a proposal [01:03] make that not work [01:03] and instead make CHKRepository.get_inventory_xml work [01:04] or at least, change the method to say that it gives xml [01:04] as in documentation or as in changing it to [01:05] write_inventory_to_xml_string [01:05] CHKRepository wasn't meant to output xml ever [01:05] so this is kindof a backdoor [01:05] One I understand the need for, at least until we get a semantic delta based bundle [01:06] right [01:06] I think it would be good to make it more explicit about whats going on [01:06] With spiv's code close to landing, I'd like to make a bundle which is a "GenericStream" [01:06] and the method that seems clearest to me is the repo.*inventory_xml* set of functions [01:06] which then knows how to stack on another repo, etc. [01:06] jam: I think that would be lovely; I've wanted to do that for ages too :) [01:07] lifeless: i suppose. Though the bundle code was already dealing with "target_format.serializer.write_inventory(source_format._serializer.read_inventory(bytes))" [01:07] we need a reasonably efficient generic stream implementation, which I think Andrew is getting close to [01:07] jam: its not clear that xml is involved there; I'd like it to be clear that it is xml. [01:08] so I'm a bit concerned about the deprecation dance of introducing a different name for the same function [01:08] Its up to you. [01:08] I realise its not immediately-in-scope. [01:09] that said, other folk who use this API will be surprised when huge amounts of IO are done to satisfy 'write_inventory_to_string' [01:11] well, given that it is inherently a whole-tree operation [01:11] regardless of whether it is XML or not... [01:15] jam: well, its a thought [01:15] ust trying to deter people from using it [01:16] lifeless: so what we need is a code level "did you really mean to do this check". :) [01:16] Issue a warning when vim saves the file [01:18] that would be lovely [01:18] perhaps a code test for uses of that function [01:29] We should rename get_bytes_as, I think. [01:30] to? [01:31] Something else ;) [01:31] it returns more than bytes... [01:32] it shouldn't [01:32] it should always be returning a bytestring [01:32] It already returns lists of bytes ('chunked') [01:32] mm [01:32] My inventory-delta patch further (ab)uses it to return inv deltas. [01:32] oh [01:32] I'd rather you didn't do that [01:33] doing that doesn't fit with the layering [01:35] If you'd like more bandwidth to discuss, we could have a call; I'd be extremely happy to help find a good home for the deserialisation call that is needed [01:39] Well, it wouldn't be a big deal to add a new method to just InventoryDeltaContentFactory. [01:39] spiv: so CF are meant to be just about byte storage and transport [01:39] you should pass the bytes they transfer to something that knows how to handle them [01:40] IDCF sounds like a layering mistake in the first place [01:40] But for in-process streams I don't want to serialise down to bytes and back. [01:41] right, so don't! [01:41] I'm not ;) [01:41] it sounds like you'e using a byte transport mechanism though [01:41] which is where the layers are confused. [01:42] Well, I'm using "record streams", which appear to actually be "content factory streams". [01:43] What mechanism would you expect? [01:45] may I call? [01:46] lifeless: sure, but give me a minute [01:46] record streams are for transfer of bytes [01:47] inventory deltas have a in memory representation (though I was thinking we should make an object for them, just recently) [01:48] when we stream inventory components using content factories, we are streaming ytes [01:49] and we [de]serialise on both sides [01:50] lifeless: you can call now [02:39] hihi....so what is the status of bzreclipse? [02:39] eg - what doesnt it support [02:40] (coming from a svn POV) [02:46] EricInBNE: I'm not sure [02:46] what does svn support ? :) [02:49] commit, merge, show history, revgraph, revert, etc [02:50] lifeless, BzrEclipse says: update supported (very basic) [02:50] what does that mean [02:51] I'm not sure - I don't use eclipse often [02:51] folk do use it - you could drop guilherme an email if you need more detail than the wiki page has [02:51] ah - it doesnt support authentication [02:53] cheers [03:05] Does anyone know when there is going to be an update for the bzr eclipse plugin so that it will work with the Galileo release? [03:05] Jemsquash: I don't - could you file a bug on it? [03:06] Yes I can. [03:14] it looks like the nightlies still don't have all the right extension libraries [03:14] i wonder if the releases are missing them too - that could cause some performance problems [03:14] anyhow putting head down now [03:16] time for your nap? [03:16] nice idea [03:16] i'm going to dream of long release cycles [03:16] and drool a bit onto an editor === timchen1` is now known as nasloc__ === TDJACR is now known as NotTheDJ === NotTheDJ is now known as NotADJ [04:27] \o/ very close now [04:27] dirstate children-of-removed-dirs + dirstate-C version to go, and we're golden [04:32] I've downloaded bzr 1.17-1 windows installer, but bzr version is reporting 1.17 (msising the "-1") [04:32] thats correct [04:32] the installer suffix is the installer suffix [04:32] 1.17.1 would be 1.17.1-1 [04:33] ah ok [04:33] I'd never grok that [04:35] if the installer has a bug you get 1.17-2 [04:35] if bzr has a bug you get 1.17.1-1 [04:35] ok [04:36] how to list saved locations? I know I asked this before, but I can't recall [04:37] bzr info? [04:39] thanks [04:39] now, I have a problem on applying a patch built with bzr send [04:41] ok solved [04:42] How to merge with a patch without having to commit? [04:44] I mean, imagine you commit 2 new revisions, then bzr send -o patch.diff, then in the target branch, you bzr merge patch.diff, but you get uncommitted changes. You have to commit something like "merge with xyz" [04:44] thats right [04:44] But actually you just want to put the 2 new revisions in the top of the tree [04:44] if you want that, do bzr pull [04:53] lifeless: thanks! [07:30] EODing [08:22] hi, i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch [08:22] can anyone give me some pointers in order to figure out whats happening? [08:26] from the bzr.log i can see its running bzr check --branch http://localhost:47422 and returning "ERROR no branch found at specified location" - which seems to be the point of the test? [08:32] i can see from netstat that it seems to still be listening on that port but when i try bzr check myself i get "Unable to handle http code 504: Gateway Time-out" [08:32] should it still be listening at this point? [08:49] lifeless: btw, that mysql branch with the slow get_parent_map HPSS requests is 1.9: https://code.edge.launchpad.net/~mysql/mysql-server/mysql-next [08:52] Did the dotted revno numbering scheme change recently? I know jam and others have talked about it. [08:52] AfC: I don't think so. [08:53] Then I think that loggerhead thing on your launchpad site is buggy. [08:53] Someone [else] mentioned this URL when closing a bug http://bazaar.launchpad.net/~afcowie/java-gnome/mainline/revision/654.1.3 [08:54] that web page says "This revision was merged to the branch mainline in revision 654." [08:54] Hmm, odd. [08:54] but that's not true; this revision was merged to 'mainline' later, in 655 as it happens. [08:54] http://bazaar.launchpad.net/%7Eafcowie/java-gnome/mainline/revision/655 [08:54] note appropriate commit message. [08:55] Right, that does sound like a loggerhead bug. [08:55] Care to file it? Or I can do it if you like, I'm at the bug tracker atm anyway. [08:55] [I was hoping it was a case of "Bazaar upstream has changed numbering, but my bzr / bzr viz hasn't" but the commit messages give it away (even without comparing revids] [08:55] spiv: if you would [08:55] I'm about to step out [08:55] AfC: sure. [08:56] * AfC admits that he doesn't use loggerhead [08:56] (or launchpad, for that matter) so I appreciate you confirming that this was a glitch. [08:57] Not a problem. [08:58] spiv: incidentally, now that those URLs are out there (apparently), should bzr change its dotted revno scheme, then you might want to consider changing the URL scheme in use above, perhaps to http://bazaar.launchpad.net/~afcowie/java-gnome/mainline/revno/655.1.3 or something [08:59] just something to mull over [08:59] (or put in a wizard mod_rewrite rule, or...) [09:00] lifeless: ah, the slow get_parent_map is probably the C extension regression bialix just reported! [09:00] Yeah, that's true. We'll definitely need to tread carefully if we do change the scheme to avoid too many disruptions. [09:01] Silently giving different pages would probably be worse than 404ing, too. [09:05] spiv: at the end of the day, this is what HTTP 301 Moved Permanently is for; if you had some code that understood both schemes then you could use a redirect like that (ie 301 from .../revision/654.1.3 to .../revno/655.1.3/ in this contrived example) [09:06] spiv: [we just went through that when we moved our blog] === AfC is now known as AfC|out [09:08] The revision/... scheme also allows revids, so just changing "revision" to "revno" in the URL might not be quite right. Just "rev" might do, though. [09:09] AfC|out: https://bugs.edge.launchpad.net/loggerhead/+bug/405686, btw [09:09] Launchpad bug 405686 in loggerhead "Revision page for a dotted revno has incorrect "was merged into" revision" [Undecided,New] [09:09] AfC|out: thanks for the report. [09:11] spiv: sure. Glad I noticed. Just a little glitch. [09:36] lifeless: aware of any bts for subvertpy? i have it crashing my unittests here and jelmer is missing [09:37] https://bugs.launchpad.net/subvertpy ? [09:37] ok, im blind and need coffee [09:42] i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch can anyone give me some pointers in order to figure out whats happening? [09:43] crisb: I'd love to but I'm about to log off for the day :( [09:43] crisb: hopefully someone else will turn up soon, otherwise you can file a bug or post to the list. [09:49] spiv: cheers :) [09:52] Is there an easy way to alter my whoami information based on which directory I'm in? [09:52] e.g. to have ~/work say "Daniel Silverstone " but ~/personal be "Daniel Silverstone " ? [09:53] Kinnison: yes [09:53] spiv: can I ask for a pointer to the right bit of docs, or else an example? [09:53] Kinnison: put an "email = Daniel Silverstone " line in a [/home/dsilvers/work] section of ~/.bazaar/locations.conf [09:54] And similarly for ~/personal, of course :) [09:54] thanks [09:54] I do exactly that myself. Well, with slightly different directories and identities ;) [09:54] oddly [09:55] :-) [10:40] spiv, nice catch there [10:40] :) hello kinni [10:59] i'm getting a hang running bzr selftest on AIX at bzrlib.tests.blackbox.test_check.ChrootedCheckTests.test_check_missing_branch can anyone give me some pointers in order to figure out whats happening? [11:42] abentley, hi [11:42] abentley: "bzr shell" currently repeats the previous command on empty commands, that's intentional I presume? [11:55] poolie: bialix caught it, originally. [11:55] (assuming you mean the broken C extension import) [11:57] accidentally [11:57] poolie: hihi [11:57] jelmer: found the issue [11:58] ronny, cool, what was it? [11:58] jelmer: appearantlz svn does an abort if the path in get_file starts with a / [11:58] jelmer: IIUC it's default behavior of std python cmd lib [11:58] ronny: subvertpy should be taking care of that [11:58] ronny, perhaps we don't yet in that particular situation [11:58] well, now you know, so it will get fixed [11:58] ronny: What version of subvertpy are you using? [11:59] jelmer: im tracking your bzr version [12:00] ronny, we're already canonicalizing [12:00] ronny, hence my question about what version you are running [12:01] ronny, actually, I can reproduce it now - thanks [12:11] Hello. I'm trying to push to a lp bzr repo from behind a proxy using corkscrew, and i'm getting this error : bzr: ERROR: Connection closed: please check connectivity and permissions. Any idea what this means ? :/ [12:12] SiDi: its trying to go through ssh [12:12] which is probably blocked by your proxy [12:13] I mean it doesn't try to go through the proxy, and is blocked by your firewall [12:13] SiDi: the TCP connection is being closed (or failing to connect?) on bzr [12:13] Alright [12:14] So i'm doing something wrong, i guess :/ [12:14] Push to lp is via ssh, as amanica1 says. [12:14] I'm not sure if lp supports pushing over bzr+https [12:14] SiDi: You need to ask your network admin to open port 22 for you [12:14] So if you can ssh bazaar.launchpad.net, bzr should work. [12:14] amanica1: not yet, unfortunately [12:15] if "ssh bazaar.launchpad.net" doesn't work (even with your lp username added), then bzr can't work either. [12:16] awilkins: my network admin is a guy who thinks a QoS allowing 3KB/Sec when there are 6MB available and 100 people on the network (and its a residence, not an office) is a good idea :p [12:17] ok thanks for the infos [12:17] Im gonna stab my network admin >_> [12:30] jelmer: you got twitter by any chance? [12:30] ronny, yeah, http://twitter.com/ctrlsoft [12:35] k [12:40] jelmer: wow, I've just seen the svn send format. thanks a lot for finishing that! [12:48] jelmer: Actually, I think it's the default behaviour. But I'm okay with changing it to do nothing, like bash. [12:57] luks: No problem, thanks for starting that. [12:57] luks, I've also done a "bzr send --format=git" based on the svn send format [12:58] luks, Which creates "git am"-compatible patches, although as one concatenated file at the moment rather than individual attachments. [12:58] abentley: Thanks - I'll file forward the Debian bug then. [13:03] jelmer: what does the svn send format do? [13:04] lifeless, send svn-like diffs without bzr-specific metadata [13:05] lifeless: Including mentioning the svn revision numbers that the delta's of individual files are against [13:05] cute === mrevell is now known as mrevell-lunch === abentley1 is now known as abentley [14:16] hi, is there a release of bzr-gtk somewhere for jaunty (ideally in a PPA) which works with bzr 1.17? [14:17] I get a lot of messages like """Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0)""" when using bzr from the ~bzr team ppa === mrevell-lunch is now known as mrevell === abentley1 is now known as abentley [14:38] LarstiQ, ^ === abentley1 is now known as abentley === abentley1 is now known as abentley === nevans1 is now known as nevans [15:35] Is it normal for bzr to be uploading 3000kb to commit a one character text change? === hal_away is now known as hal [16:10] * dobey pleas for help [16:10] OllieR: perhaps your commit triggers repack [16:11] bialix: what on earth does that mean? [16:11] are you aware of `bzr pack`? [16:13] current repository formats store committed data in the form of "packs" [16:13] every new commit add new "pack" [16:13] when there is many pack files in repository it should be repacked otherwise things become slower than needed [16:14] commit or push or pull can trigger automatic repack of repository === kiko-afk is now known as kiko [16:15] unfortunately in remote repo case bzr do repack on client side, i.e. it has to download big amount of data, repack it into single file and upload it back [16:15] OllieR: hth [16:16] repacking on server side should be implemented in recent bzr versions, but I don;t know for sure [16:17] dobey: if you want to ask it's better to just ask in IRC. somebody will answer or not [16:19] It repacks server side as long as you're using a smart protocol [16:20] I suppose it was fixed recently [16:20] Dumb protocols... I think it still repacks over the wire. Which is a bummer when your dumb protocol is a windows fileshare over VON [16:20] VPN [16:21] why it's bummer? [16:21] Because VPN is slow [16:21] (well, over my 512Kbit/s upload, repacking a 70MB repo is [16:21] I usually get someone in the office to do a repack locally before I touch it if I see the packing start [16:22] NEWS says the server-side autopack was in 1.9, so it's been around a while (doesn't help on dumb transports of course, but not much does) [16:22] bialix: yeah. i'm just trying to understand what to ask, because i'm not sure if it's a bzr issue or a lp issue [16:22] may be some sort of server-side daemon that repack onsite will help with VPN? [16:23] bialix: That would be a reasonable idea. I call it "users". [16:23] haha [16:23] but basically, i can't seem to push a branch to launchpad successfully that is stacked on a 2a branch [16:23] "bio-cron" :p [16:23] It would be nice.... we serve some of the branches out of an IIS box and sometimes I think it would have been nice to just have that since it has a smart server. [16:24] Neo: the Matrix has you... [16:25] bzr plugins lists blow 1.11 [16:26] Loggerhead web viewer for Bazaar branches. [16:26] but when I do bzr serve --htt[ [16:26] http evenI get errors [16:26] I'm currently racking my brains thinking about porting Mercurial pbranch to Bazaar.... there must be an easier way than reading the pbranch.py file and trying to trans-code it to bzrlib [16:26] bzr help blow does say This provides a new option "--http" to the "bzr serve" command, that ... [16:29] pbranch instead of loom? [16:32] awilkins: is not bzr-pipeline is another alternative to loom? [16:34] jelmer: what are the plans for doing all lower level workdir operations of git in dulwich? [16:36] what's the easiest way to track one particular file and see revisions only for that file? [16:37] I don't want to have to do bzr log on it, check revision, and keep doing diffs by hand. it's tedious [16:43] bzr log FILE? [16:44] as I said, bzr log only tells me that the file has changed [16:45] I'd easily like to be able to navigat the revisions and see what has changed [16:45] which means bzr log FILE ... look... bzr diff revno... bzr log FILE ... look ... bzr diff other_revno... etc [16:45] eydaimon: log can also show diffs, if you want. === abentley is now known as abentley-lunch [16:46] bialix: bzr-pipeline is stacked branches, like loom [16:46] ok, thanks [16:46] bzr log -p FILE [16:46] bialix: I have two ways to what I want ; add parallel featues to pipeine or port pbranch [16:46] or bzr qlog FILE ;-) [16:47] I have not tried pipeline yet, but from abentley announce I was under impression it's more than stacked branches [16:47] the annoying thing is I have to keep track of all the revisions since I only want to look at what's changed between them [16:48] * awilkins pulls the latest version of bzr-pipline [16:49] guess it's a lp issue mostly [16:49] Hello everyone. I've started making some changes to a program that I'd now like to work on as a branch. I've yet to commit the stuff I've changed, so was wondering what the best way would be to go about doing this. [16:50] lllama: Are you working in a free standing branch or a checkout? [16:52] awilkins: checkout [16:53] awilkins: but I can unbind if required. [16:54] lllama: If you unbind, you are now working in a branch - you might want to do `bzr nick project.fix-my-bug` or another sensible name before you commit. [16:56] lllama: I tend to work with a local no-trees repository containing all the related branches I'm working on, and use lightweight checkouts and `bzr switch` to move between them. [16:57] lllama: Other people make their parent folder a shared repository, and keep a "trunk" checkout for merging, and branch from that for work packages. [16:57] awilkins: Interesting. I've got a remote no-trees repo, so I could look into something similar. [16:58] awilkins: If I unbind though can I copy the dir (keeping the uncommited changes as a result) and then revert the existing branch to back them out? [16:59] You should be able to do that, yes [16:59] Or branch your existing folder to your new "trunk" branch [16:59] e.g. cd .. ; bzr branch work trunk ; cd work ; bzr commit -m "My Changes" [17:00] (presuming "work" is the existing folder with changes in it" === hal is now known as hal_away [17:02] I tried that but I don't get the uncommited changes in the new branch (natch). Just wondering whether there's a better procedure. I could do with a little rethink of my repo layout methinks. It's a little flat ATM.. [17:02] lllama: You keep the old folder as your work branch, and the new one is your "trunk" branch [17:03] lllama: The not-getting-the-changes is intentional in this case :-) [17:06] awilkins: of course. Thanks for the help. I'll look into 'switch' as well. [17:07] lllama: You're welcome === JamalFanaian is now known as JamalFanaian|afk [17:37] lifeless, awilkins: btw, if bzr is basically inode based, shoudn't there be a rather simple way to expose commit building/tree changing as if it was a posix fs [17:39] ronny: Not sure about that, I think Subversion is sort of like that but I have the impression that the undergarments of Bazaar are rather different [17:40] jelmer: hmm? the context of that '^' was a bit scarce [17:40] well, i'll gradually put complete in-memory filesystems on top of hg, bzr, svn and git based on the api"s of the fraft spec for the new filesystem apis [17:40] *draft [17:40] LarstiQ, sorry [17:40] LarstiQ, somebody was asking about bzr-gtk in the PPA's [17:40] LarstiQ, are you doing those or johnf? [17:41] jelmer: I haven't been doing them [17:42] jelmer: it seems you and jam have, I can pick those up [17:42] jelmer: although I'm not really a user of bzr-gtk nowadays [17:43] LarstiQ: bzr-gtk hadn't done a release in long enough, that I don't think anyone was doing them :) [17:43] hello there, does anybody know how to use the --nested options ??? [17:43] i can't find the option with 1.3 and 1.17 release (ubuntu jaunty) [17:48] * LarstiQ heads out === abentley-lunch is now known as abentley === kiko is now known as kiko-fud [18:14] franck_: I think you're talking about features that are still in the planning phase. [18:23] awilkins: I'm open to supporting parallel pipes, I just haven't really needed it. [18:24] abentley: I'm scratching my head ans starting at a pipe called "parallel" ATM :- [18:24] staring [18:25] I don't think the Mercurial lot are 100% decided on what to do either, it's clear that people want features like this but they've notarrived at the mbest way to do it yet. [18:26] I found a page where they compare 4 ways of doing it. And pbranch credits loom for inspiration! [18:27] http://mercurial.selenic.com/wiki/PatchHandlingUnificationRFC [18:28] I think the worst thing is that "get_(next|prev)_pipe" becomes a bit awkward instantly [18:28] They just resort to moving around on names only [18:39] abentley: ok it's that i've seen with more search on mailing list, by the way do you know a good method in order to merge already versionned branches within a new versioned project, i need that cause i got some libraries wich are managed via bzr, but i can't add them only if i delete .bzr folder within module... [18:40] franck_: `bzr help join` ? [18:41] awilkins: many thanks i haven't seen that, i'm gonna try it ! === hal_away is now known as hal [19:04] I'm new bazaar can i ask a question? [19:05] I've read a lot of documentation and cannot find an answer [19:06] I have a repository on a web server with a checkout that are the files actually being served as as a website, if another developer changes those files being served is there a way to commit those changes? [19:07] macinjosh: `bzr commit`? I'm not sure what you're asking [19:07] well i only have FTP access [19:08] I do not have shell access to this server [19:08] macinjosh: you can commit via FTP but it's not the ultimate in effciency [19:09] macinjosh: preferably, imo, you would not edit at the website, but only deploy to it [19:09] macinjosh: And note that this does not necessarily change the working tree on the server to match your commit [19:09] yeah I realize that, we're working with a web designer who doesn't use or want to user version control :-( [19:10] I've tried this: bzr commit ftp://josh@mywebserver.com [19:10] and i get this error bzr: ERROR: Path(s) are not versioned: "ftp:/josh@mywebserver.com" [19:11] macinjosh: Does the tree correspond to the root of the FTP home on the server? [19:12] yes the .bzr folder is at the root of the FTP home [19:12] macinjosh: Oh, hang on, you're trying to commit that file [19:12] macinjosh: You want to commit the changes to the folder, remotely, via FTP? [19:13] macinjosh: Which OS are you using as your client? [19:13] yes, but not changes to the .bzr folder if thats what you are thinking. The changes would be in versioned folders like public_html [19:13] im on mac os x, the server runs redhat [19:16] these are the files/directories in the FTP home .bzr .bzrignore public_html views www models [19:16] changes will be made in public_html views www and models [19:16] macinjosh: can you ssh into the server, and run bzr there? [19:17] macinjosh: the checkout needs to be updated anyway [19:17] in need to commit those from my machine into the repository in .bzr [19:17] no i don't have shell access (its a shared server) [19:17] macinjosh: The only other way to do it I can think of is ... i) run a smart server on the server ii) mount the folder into your local filesystem [19:18] ok, thanks [19:18] you've been helpful. bye === ja1 is now known as jam === kiko-fud is now known as kiko === hal is now known as hal_away [19:53] hey bzr devs [19:53] i just branched 4 svn branches into bzr and uploaded them to lp. now I need to inform bzr that they are fully merged [19:53] is null-merge the only way to do that? [19:54] reggie, full merged in what sense? [19:54] reggie, and what do you mean by null-merge? [19:54] well, since svn doesn't support true merging, in the sense that newer branches have the changes I want them to have from older branches [19:55] null merge meaning do the merge and then revert the changes [19:56] and since the merge from one branch to another will likely find all sorts of conflicts and I'm going to revert them anyway, I can just tell bzr to merge it "any way it can" right? [19:57] * LarstiQ blinks === JamalFanaian|afk is now known as JamalFanaian [20:17] poolie, let me know when you're around [20:21] reggie: if the branches share ancestry, then merge will know about merged changes, and not bork on lines already being added === CardinalFang is now known as Guest3645 === hal_away is now known as hal [21:16] moin [21:27] any idea when https://bugs.launchpad.net/bzr/+bug/98836 will be fixed? [21:27] Launchpad bug 98836 in bzr "[MASTER] "OS locks must die" - dirstate file write locks exclude readers and limit portability" [High,Confirmed] === hal is now known as hal_away [21:35]