[00:00] lifeless: do you have any plans to merge Dan's outstanding patches? [00:00] jelmer: I've looked at all the proposed branches, I thought. [00:07] morning [00:17] Morning. [00:27] good morning [01:37] lifeless: Rather than reorganizing everything we have at the moment, couldn't we just have a new "bzr-committers" group ? [01:42] jelmer: thats what I've said I'll do :P [02:08] lifeless: sorry, looks like I'm just behind on mail [02:25] mwhudson, jelmer: any ideas on bug 563118? [02:25] Launchpad bug 563118 in loggerhead "Lucid upgrade switch to serve-branches.conf without providing one" [Undecided,New] https://launchpad.net/bugs/563118 [02:26] mwhudson, jelmer: I can't even find where the configuration file name is defined [02:26] Could it be a packaging issue? [02:28] poolie: what approach should I take for 2.2b1 Windows builds? Should I use a revision on trunk or use the 2.2 branch? [02:30] igc: it might be a packaging issue i guess [02:31] mwhudson: all I can find is loggerhead.conf.example in the code [02:31] I can't see where loggerhead.conf is referenced though [02:39] igc: it's passed on the command line maybe? [02:39] i think jelmer has a packaging branch somewhere that has an initscript that mentions it [02:40] http://bzr.debian.org/pkg-bazaar/loggerhead/unstable [02:40] or deb:loggerhead for short :-) [02:41] lifeless: I'm considering moving some per_repository tests into a new per_repository_vf.test_supported, does that sound reasonable? [02:42] jlemer, mwhudson: any chance one of you can look at that bug or direct me on how to fix it? [02:42] jelmer: what are they testing ? [02:42] jelmer, mwhudson: I need to head up the hospital right now [02:42] lifeless: they are the tests that rely on .revisions/.texts/.inventories existing [02:42] igc: i'll have a look, but i think it's going to be a bit tricky [02:42] * igc out for a few hours [02:43] mwhudson: thanks [02:43] because we're deprecating the entry point that's used before lucid [02:43] jelmer: I want those to be supported on foreign repos too [02:43] jelmer: they are part of the contract [02:43] I don't think its appropriate to have them unsupported anywhere [02:45] lifeless: why? They rely on a specific serialization, and we don't always have access to that serialization [02:45] lifeless: in particular, inventories don't exist in git/hg/svn so we have to generate an inventory manually *and* serialize it [02:45] lifeless: fwiw these plugins work fine without .{texts,revisions,inventories} at the moment [02:46] jelmer: see the docstring in bzrlib.repository.Repository [02:46] jelmer: the meaning is per-format [02:46] jelmer: the interface isn't [02:46] jelmer: which is why I didn't like your mirroring onyl *part* of it last week or so [02:46] its a regression in our interface, moving away from the unified keyspace [02:47] lifeless: can you expand on "the meaning is per-format, the interface isn't" ? I don't understand what you mean. [02:48] I mean that the serialisation is specific to the format [02:48] and external code to the format knows that it doesn't know [02:48] but that the graph is intrinsic [02:48] all formats should be capable of generating graphs for revs, invs, texts [02:49] and this is the interface to talk to that [02:49] lifeless: where do we rely on graphs for invs and texts at the moment? [02:50] lifeless: providing those for foreign formats would be hard to make perform well [02:50] lifeless: I understand that's what's in the interface now, but I'd rather see that interface change.. [02:51] lifeless: ... and have vf's be part of the implementation of a particular category of repositories rather than all of them [02:52] per file log [02:52] inv graph we don't care about [02:52] jelmer: I don't see why it imposes a performance penalty; either you have to generate the data, or you don't. [02:52] if you're doing per-file log to bzr's behaviour, you need to generate the data [02:54] lifeless: ok, point taken [02:55] lifeless: that's just one function in the VF interface we use though, that justify requiring a VF imho [02:55] the point of the vf interface is a consistent graph interface that is *not on Repository* [02:56] its part of the long term fixing of repository. [02:56] which you undid some of last week :( [02:56] if you've got a better direction to take it, I'll happily support that [02:56] lifeless: and much more, I don't see how access to serialized commits/inventories should be a public part of repositories [02:57] but so far, abently's proposed 'storage' interface - a single unified graph - seems to be a likely winning contender [02:57] jelmer: its been very useful so far to have it in a consistent supported manner [02:57] jelmer: for repo-stats and other plugins [02:58] debuggability is an important feature [02:58] lifeless: I'm not saying it can't be available, just would prefer to not have it in the contract of Repository itself [02:58] we have, for instance, used access to the graph to fix stacked branches [02:59] nothing stops a VersionedFileRepository from existing [03:02] anyway, this is a blocker for me for using the standard per_repository tests for foreign repositories [03:02] jelmer: seems to me there are two positions we could take [03:03] a) that bzr-svn etc are 'complete' and the tests need to be divided [03:03] b) that they are not complete, and the tests primarily need to be tweaked to remove bzr-only assumptions [03:03] I currently hold position b [03:05] jelmer: I don't want to block you, but you seem to hold position a? [03:06] lifeless: I don't consider b to be possible, unless you're happy to strip the VersionedFiles interface down to just get_parent_map() and get_known_graph_ancestry() [03:07] jelmer: because you can't get raw data from svn ? [03:07] lifeless: nor can I get an inventory text from git [03:08] lifeless: it's also not possible to add any text [03:08] jelmer: you can get the root tree node [03:09] jelmer: I'm ok with making the _required_ support on the vf objects be very minimal [03:12] lifeless: to just revisions.{get_parent_map,get_known_graph_ancestry}, texts.get_parent_map ? [03:13] lifeless: generally the way this is structured ({revisions, texts, inventories} as serialized files) makes a lot of assumptions about the way the repository is set up that aren't true for foreign repositories [03:13] jelmer: this is why I want to move to a single unified graph! [03:14] lifeless: is that aaron's storage thingy? [03:14] jelmer: which is one of the key complaints about that merge I keep coming back to [03:14] jelmer: closely related, yes. [03:14] jelmer: CHK repositories are pretty close to git internals, and the mapping structure we have works ok for them too [03:15] jelmer: so, not, not just revisions & texts [03:15] for instance git could support chks trivially [03:18] lifeless: that doesn't mean it's easy to implement VersionedFiles on top of Git while using Bazaar file ids/revids though [03:18] lifeless: anyway, do you have pointers about the unified graph? [03:19] jelmer: I know, but revision_tree.get_texts takes the same interface [03:19] jelmer: so its no harder [03:20] lifeless: I don't have a RevisionTree.get_texts... [03:20] jelmer: mumble, I forget the exact api name [03:20] see what export uses [03:21] iter_files_bytes() ? [03:21] that doesn't return any parent keys [03:26] anyway, I'd better get some sleep [03:26] lifeless: thanks for the comments; I'll hold off on this for now, at least until the new better storage thing [03:27] jelmer: perhaps we can talk at UDS [03:27] I do want to unblock you [03:27] but we seem to be unagreed about where to go [03:27] I'm concerned that you seem to be busy undoing a good years worth of refactornig [03:28] if you weren't, I'd be much more lassez faire about stuff [03:28] lifeless: it was just one function... [03:28] jelmer: no, its more than that [03:29] the VF interface is a key part of stacking working [03:29] lifeless: I just added a wrapper in Repository, I didn't move anything [03:30] lifeless: everything else seems to be happy calling Repository.* [03:30] to be clear, I don't think you're doing bad code, but we - you and I at a minimum - havent' figured out a foreign <-> core compromise [03:30] lifeless: right [03:30] lifeless: talking about this at UDS might be a good idea indeed [03:31] * jelmer really gets some sleep now [03:31] gnight [03:36] Congratulations on bzr-git, by the way. I've been using it to browse the kernel tree's commit log, because bzr's default log format is vastly superior to anything I've found in git. “bzr log” in the kernel tree takes approximately as long as “git log” [03:36] jelmer: ^ [03:36] raof: thats awesome [03:36] and a little terrifying [03:37] :) [03:39] * raof doesn't quite get why git thinks commits should be in chronological order, interleving commits from different branches into one mixed stream [05:12] here is a mind bender [05:13] shoot [05:13] I have an existing branch that I had on the wrong revision [05:13] 'wrong' ? [05:13] I want to make a branch that is cherry pickable [05:13] but I started with production-devel [05:13] rather than the lca with devel and production-devel [05:13] so when I proposed my production devel based branch, I get conflicts galore [05:13] so... [05:13] I uncommitted and shelved [05:13] now I want to get to a good start revision [05:14] how? [05:15] bzr pull . --overwrite -r revid:`bzr find-merge-base devel prod-devel` [actually the backtick expression won't work, consider it a conceptual example] [05:16] no revisions to pull :) [05:16] then you were on the revision already? [05:16] I think deleting the branch and starting again might be faster [05:16] no [05:17] shouldn't be [05:17] actually yes it is [05:17] but the revno seems all wrong [05:20] * thumper stabs it a bit [05:21] thumper: pull --overwrite is the canonical way to just shift to a different revision [05:22] lifeless: worked with 'bzr pull ../db-devel --overwrite -r 9184' [05:22] lifeless: but giving it a revid (probably a different one) got it to 10622 [05:22] given that the branch I was pulling from has under 9300 revisions [05:22] it seemed screwy [05:22] heh [05:31] hi. trying to get bundle buggy up and running. i have turbogears2 installed and http://turbogears.org/2.0/docs/main/WhatsNew.html says tg-admin sql create –> paster setup-app development.ini but what's development.ini? [05:36] meh, i will just get turbogears 1.1 [05:58] AttributeError: 'ScopedSession' object has no attribute 'query_property' :( [05:59] and there i am stuck :( [05:59] abentley: I am trying to install bundle buggy [06:01] chx, perhaps it's a bit out of date [06:01] try googling those names [06:02] poolie: the error message? i googled the error message, there is nothing [06:02] literally nothing [06:02] Results 1 - 1 of 1 for " AttributeError: 'ScopedSession' object has no attribute 'query_property'". [06:02] and that's a chatlog [06:02] "have you seen that before? nope" [06:05] can you pastebin the traceback? [06:10] poolie: http://bzr.pastebin.com/8wRuteUF [06:16] to me this looks like a version mismatch within elixir vs turbogears [06:16] chx, suggest you send mail about it to aaron or to the bzr list [06:22] poolie: OK :( [06:22] will attempt with turbogears 1.0 as a last try [06:22] ok [06:22] most of the attention here has moved to lp reviews recently [07:12] So, I did I hear something about bzr releasing the GIL sometimes? [07:12] (Strike that first "I") [07:13] yes === radoe_ is now known as radoe [07:13] some of our C extensions know how to release the GIL [07:14] lifeless: Okay. Is there some code I can grep for to see where that happens (or a list of places where it does)? [07:15] bzrlib/*.(?i:py$) :) [07:15] lifeless: The reason that I ask is that, though I haven't fully investigated, the codebrowse deadlock may be somewhere in the python interpreter layer, and a released GIL seems like a possible culprit. [07:16] I'm not sure which modules release [07:16] I'm pretty sure the groupcompressor does [07:16] possibly diff does [07:16] The only C extension that uses Py_BLOCK_THREADS/Py_UNBLOCK_THREADS is bzrlib/_groupcompress_pyx.c, according to grep [07:16] spiv: Okay. So that would only happen on a write operation, right? So loggerhead wouldn't call that code. [07:18] look for nogil in the pyx files [07:18] lifeless: Thanks. :-) [07:19] mkanat: apply_delta does nogil [07:19] so its both compression and decompression [07:19] mkanat: no, I think it uses nogil sometimes while reading too. [07:19] mkanat: that said, I'd be a bit surprised to find that using nogil was the problem [07:20] spiv: What happens if a thread that has the GIL released gets an exception (from the launchpad-loggerhead no-activity thread killer)? [07:20] spiv: Will the GIL be reacquired? [07:20] spiv: You'll have to forgive me a little, I've actually not used much python code that releases the GIL. [07:21] mkanat: assuming no bugs in Pyrex (or Cython if that's what you're using), yes. [07:21] spiv: Okay. [07:21] Look at how the translated C code handles those conditions if you like. [07:21] mkanat: python code can't release the gil, only C code written to CPython [07:21] lifeless: Right. [07:21] well [07:22] lifeless: I was speaking loosely. :-) [07:22] I guess the python dynamic access to C code could release it [07:22] it would be hilarious [07:29] Okay, yeah, looks like only groupcompress uses nogil anyhow. [07:49] Okay, I've looked and not found this--where can I find how to get a working local instance of launchpad-loggerhead? [07:53] https://dev.launchpad.net/ ? [07:57] maxb: Thanks. [08:00] spm: What does nagios/whatever do to check whether codebrowse is alive? [08:01] mkanat: oh we gave up on that ages ago. it's kinda /dev/random > 20% - alert. otherwise is fine. [08:01] spm: lol [08:01] mkanat: /usr/lib/nagios/plugins/check_http -H bazaar.launchpad.net -u /~vcs-imports/busybox/main/changes -e " 200 OK" [08:02] spm: Okay. [08:02] basically a simply http check alive/dead against a known url [08:03] spm: Okay. Does nagios do the check more than once, or do you get paged immediately if it fails once? [08:03] 3 or 3 fails I suspect. it's very rare for any of our checks to be different to that [08:03] 3 *of* 3 [08:04] spm: Okay, thanks. [08:04] np [08:04] hi spiv, lifeless, igc, [08:04] and vila [08:04] i'm thinking it's probably best to do 2.2b2 now, off trunk, rather than recutting 2.2b1 with fixes [08:04] any problems with that? [08:05] poolie: ok by me [08:11] poolie: fbm [08:11] i feel a bit weird so i'm going to stop after that [08:12] Yeah, seems fine to me. [08:24] poolie: I merge 2.0 -> 2.1 -> 2.2 and 2.1 > bzr.dev yesterday, so both ways are fine to me, I thought that was the plan anyway [08:24] thanks [08:24] yes, it was [08:25] i just had a somewhat dopey day today [08:27] poolie, lifeless: Can we talk about https://code.edge.launchpad.net/~vila/bzr/563997-selftest-unicode-reporting/+merge/23501 ? [08:27] sure [08:27] lifeless: you r comment is terse and doesn't help me there, what's your point ? [08:28] sure [08:28] so vila, i think the main point of using them would be to synchronize with the progress bar [08:28] that might be unneccessary if self.stream is already obtained from make_output_steram [08:28] stream* [08:28] um [08:29] no its' not, it's a totally different beast [08:29] well, AFAICS [08:30] and I think the pb has already been cleared (my manual testing didn't show any problem there) [08:30] ok [08:30] What *I* like is to separate the issues there: 1) make selftest robust, 2) address unicode support in ui [08:31] so i would still say that the real problem is #2 [08:31] vila: hi [08:31] uhm [08:31] but if this is more pragmatic i don't think it's wrong [08:31] i think pb.note should be for something that kind of maps into an information dialog popup [08:31] selftest shouldn't be calling a global function, which it might be [08:31] yeah, but 1) was blocking me and trying to address 2) was more... involved [08:31] it's not clearly defined [08:31] so i don't mind removing callers [08:32] in-python gui runners mightlike the current behaviour [08:32] lifeless: yeah, part of the problem, I have no idea if there are one or several ui objects involved [08:32] OTOH they can use their own result object [08:32] vila: if it calls via module.ui_factory, it will end up calling the ui object * of tests * [08:34] lifeless: I realize that, I'm not sure how approriate it is for selftest itself (given that it's the only place and that this code path is *not* involved is you use selftest -v ! [08:34] I went with the pragmatic approach when I realized that (-v does it this way) [08:35] vila: so, I'm saying that selftest needs to be solidly isolated [08:35] I found some bugs when donig the testtools thing [08:35] where selftest was doing 'progress' but we would not see it because the test ui factory was installed [08:35] lifeless: yes, i know of them [08:35] in vila's patch it uses self.ui [08:35] lifeless: yes, I don't have the line at hand but testtools use a UnicodeOrBytesToBytesWriter for stream (or something) [08:35] ok cool [08:36] poolie: ^ [08:36] which is the outer ui, meant to be isolated from any global state changes [08:36] mm, i remember the conversation [08:36] outer ui... I missed that [08:36] anyhow, I really don't mind what is done here; self.ui is our ui abstraction, but we don't have to use it [08:36] makes sense tough [08:36] vila: the ui that's talking to the user about the progress of the test, not the ui for a particular test [08:36] sure [08:36] lifeless: my suspicion is that the problem originates in doctests [08:37] i think some isolation we do in the test base class actually needs to be done in the runner [08:37] or, similar [08:37] i mean, or in the doctest [08:37] poolie: really? That surprises me [08:37] i think doctests will see ui.ui_factory pointing to the real one [08:37] imbw [08:38] i haven't actually fixed the bug [08:38] it's only a suspicion [08:38] poolie: we can setup setup and teardown functions when we thunk doctests into unittest's api [08:38] poolie: so if thats happenning, we should create such functions [08:38] it sounds plausible [08:39] poolie: the issues I went into trying to address 1) were: ui.show_* methods doesn't encode, the only method that encodes is prompt() [08:40] vila: i suggest you merge this for now and get unblocked [08:40] i don't think it's a step back in any regard [08:40] amen & thks [08:42] poolie: I'll file a new bug for ui.note and friends then [08:42] There's a bug still open about the lack of isolation for our doctetss [08:43] https://bugs.edge.launchpad.net/bzr/+bug/321320 [08:43] Launchpad bug 321320 in bzr "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] [08:43] heya all [08:43] bialix: good evening. [08:43] spiv: yeah, and I still can't run the test suite in a bound branch :) [08:43] spiv: :-) [08:44] let's call this rainy morning an evening [08:44] bug #309309 what a lovely number... [08:44] Launchpad bug 309309 in bzr "selftest can't be run in a bound branch" [High,Confirmed] https://launchpad.net/bugs/309309 === chx is now known as chx_zZz [09:01] vila: could you please start setting commit messages in your proposals ? Thanks! [09:02] lifeless: you mean when I do the proposal or when it is approved ? [09:02] lifeless: by the way, the only thing that blocks me to always use feed-pqm is the lack of --fixes support [09:08] vila: when you do put it up [09:08] ok i might call it a day [09:08] vila: how do you mean --fixes? [09:09] poolie: I suggest "Friday" [09:09] hee hee [09:09] vila: if you mean the #TODO I have in my hydrazine cron branch, patch it :P [09:09] it's the quiet ones you've got to watch :) [09:09] poolie: if I land something in bzr.dev can I still target it at 2.2b2 ? [09:09] nup [09:09] well, not truthfully :) [09:10] poolie: ? [09:10] i've just sent a merge to pqm from trunk into the 2.2 branch that will be 2.2b2 [09:11] lifeless: I mean the ability to say that the final commit is the one that really fixes the bug [09:11] vila: I'm not sure how thats connected to feed-pqm [09:13] lifeless: if my mp has been reviewed but doesn't mark the bug as fixed, I merge it into my integration branch, commit with --fixes and pqm-submit it [09:13] vila: why don't you just commit a no-op --fixes? [09:14] vila: or even not stress about it :P [09:14] poolie: "call it a day" means EOD or long day fionished successfully? [09:14] lifeless: matter of taste I presume [09:14] more of the first in this case, but either [09:15] good weekend for you then! [09:15] you too [09:15] poolie: 2.2b3 milestone activated, let's keep 2.2b2 active for a couple of days though [09:15] yep [09:15] i haven't sent something to trunk to bump the version yet,because pqm is a bit queued [09:15] you can if you want [09:15] cheerio [09:19] poolie: enjoy your week-end [09:21] lifeless: woot ! thanks for approving/submitting my mp :-D [09:29] vila: tools are good [10:01] Hello, I'm looking at updating a python script to use LP API (instead of screen scraping) and while at it to also replace the bzr calls with using the bzrlib module. [10:01] Is there any documentation how to "translate" bzr calls to usage of bzrlib? [10:02] I've found http://doc.bazaar.canonical.com/bzr.2.1/developers/integration.html which seems to cover most what I need. [10:04] geser: often, looking builtins.py can show you a great deal about what is going on [10:13] * igc dinner [10:14] how do I translate "lp:foo" to something I can use as a branch location within bzrlib? [10:18] geser: that should work automatically if you load plugins [10:18] geser: "from bzrlib.plugin import load_plugins; load_plugins()" [10:19] ah, thanks [10:19] (The "lp:" namespace is provided by the launchpad plugin) [10:19] * spiv -> dinner [12:23] Hi! I'm looking for some system control software that fits my requirements. I would like to realize the following scenario: I and my few friend are in LAN and we have some project. We would like to have system controlling and backup at once. I.e. every would run server and commit command would send changes not only to local server but to my friends' servers too. Is it possible with bazaar? Could you point me out a piece of doc ragarding that? [12:26] putrycy: a bzr "bound" branch does exactly what you're asking for. if you have bzr installed, see `bzr help checkout` and `bzr help bind` [12:26] putrycy: also see http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/central_intro.html [12:27] jderose: thanks, I'll take a look for sure. Tell me just one thing more: If some server is turned off will it be synchronized later? [12:27] yes, but you can to do this manually (this is a feature I'd like to see in bzr) [12:28] I _can_ or I _have to_? [12:28] when you go offline, you would `bzr unbind`. when you go back online, you would `bzr bind` and then `bzr update` [12:28] yes, you can certainly flip between bound and unbound, sync later when you are online [12:28] it just doesn't happen automatically [12:29] OK, I'll dig in doc for details. Thanks a lot once more [12:29] putrycy: no problem, good luck! [12:33] I think putrycy was anticipating the changes would go *instantly* to his friends. [12:34] that would require a something on the central server pushing to the friends on, perhaps, a commit hook or similar. [12:34] there is no particular advantage to doing that [12:34] unless you expect the main server to regularly burst into flames. [12:37] putrycy: keep in mind that by being distributed you already have a backup: all your friends have a copy of all the revisisions you've shared so far [12:38] putrycy: if you add a server in the mix acting as a synchronization point, you get one more copy and a point where you can decide how you share your history [12:39] plus a place where everybody can check for new changes and push his own changes of course, but the point is that this central server is not mandatory, you can find other ways to sync [12:40] putrycy: bzr itself doesn't provide a way to push to multiple targets automatically. [12:40] putrycy: bound branches allows you to push every revision you commit to *one* server [12:44] putrycy: The "Workflows [12:44] " doc give a good overview of the options, in case I didn't understand your needs: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/bazaar_workflows.html [12:54] oh.. I'm a little confused now. Why I would like to have repository on many servers? For safety. I.e. my real environ would contain just two machines: mine and of my friend. So I think it is possible one of them 'burst into flames' === mrevell is now known as mrevell-lunch [12:55] In the of my computer corruption I would like to have a copy of my work [12:55] with all previous versions etc. [12:57] putrycy: as bzr is distributed, when you create a local checkout or branch, you have the full set of revisions and history locally... so it's always on at least each person's machine who is working on it [12:57] if you have only two hosts it's simpler, start by reading http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief , the vocabulary will be clearer [12:58] putrycy: as soon as both of you have a branch, you backup each other [12:58] vila: OK, thanks [12:58] and with 3 parts? [12:58] I don't except corruption of two servers but I'm just asking [12:59] if somebody else would like to participate in our cooperation [12:59] putrycy: the server is *another* backup, but also a potential means of synchronization [12:59] putrycy: it's the same, a branch use a repository to store revisions, as soon as you merge changes from your friends, you get a copy of their revisions [13:00] oh [13:00] I think about another scenrario [13:00] i.e. [13:00] everyone work on another project [13:01] and I don't need to explicitly obtain their branches [13:02] (of course everyone could join to each other project but it's another story) [13:03] what do you mean by "I don't need to explicitly obtain their branches" ? [13:06] I mean a situation: on every sever there is a main dir containing repository. There are three different project: ProjectA, ProjectB, ProjectC. Each project is managed by another man. I think that I can work only on ProjectA. I.e. my server of course have to have a copy of ProjectA, ProjectB and ProjectC but my local workspace would contain only ProjectA [13:06] (My english doesn't help me to explain what I mean:/) [13:07] I think about bzr like about SVN... am I wrong? [13:17] putrycy: I think so, you *can* share a repository between branches and even between projects, but you interact mainly with branches [13:17] so [13:18] so when you pull or merge from a friend's branch into your branch, you get only the revisions for his branch, not for the other projects [13:18] when I change something in my branch I would like every of my friend could see that change on his server [13:19] putrycy: they will need to pull from your branch [13:19] or merge [13:19] so, cannot I commit to many different servers? [13:20] to 3 in this case: my local and of my friends [13:20] putrycy: you can commit locally and to *one* server by using bound branches [13:20] OK [13:20] thanks for youre patient [13:20] putrycy: no worries [13:20] patience [13:21] putrycy: you can write a plugin to do so, [13:21] putrycy: keep in mind that not all servers will be online 24/7 though [13:21] I know [13:21] I know [13:22] that's why I would like they to be synchronized [13:22] putrycy: or you can have a look at multi-pull which allows one to automatically pull (not push) multiple branches [13:22] when they are on [13:22] what OS are you (plural) using ? [13:23] mainly windows but I'm going to use linux as welll [13:23] (and perhaps FreeBSD) [13:24]