[00:19] i'm following the wiki tutorial on migrating an existing project to a shared repository, but having a problem specifying an alternate port to sftp. According to the man page for sftp, it should be: sftp -oPort=, which works for the sftp command, but bzr chokes on it [00:20] can anyone tell me the correct way to do: bzr init sftp://centralhost/repo/project on a port other than 22? [00:22] is it the same thing if I ssh into the remote server, create the project directory and then run bzr init inside it? [00:29] hmm [00:30] mgrandi: what's up? [00:30] well you had a problem right [00:31] mgrandi: yes, but it didn't seem like anyone here was going to help, so I'm googling some more and testing ssh workarounds [00:32] well patience hehe [00:32] not everyone is here right now , let me see [00:32] at some point, though, i'll have to find a real solution b/c i expect that checkout and commit will probably fail, too [00:33] so you want to ssh with a different port, yes? [00:33] mgrandi: patience is not a weak point of mine, but there wasn't any activity in here at all after 10 minutes [00:33] yes [00:33] but not ssh [00:33] yeah, sftp [00:33] sftp as in: bzr init sftp://etc/etc [00:34] bzr uses paramiko [00:34] so its not the same as the sftp command you are using [00:34] ok, let me look that up [00:35] i'm looking into it too [00:35] one sec [00:38] it looks like paramiko is a python object [00:38] yeah its a library [00:38] trying to find the -O options [00:44] https://bugs.launchpad.net/bzr/+bug/146715 [00:44] Ubuntu bug 146715 in Bazaar "bzr+ssh broken for non standard ports." [High,Fix released] [00:44] says that just having the port in the URI should work fine [00:44] so...sftp://bob@example.com:23 should work? [00:44] mgrandi: thanks, i'll try it. one sec [00:45] mgrandi: it works [00:45] mgrandi: thanks [00:45] yay =) [00:45] enjoy bzr [00:46] mgrandi: that will be true for all of those options, right? [00:46] mgrandi: checkout, commit, etc [00:46] yeah [00:46] if you bind a branch to a url then all of those stuff should work [00:46] mgrandi: thanks. have a great weekend [00:46] ^v^ [00:50] by the way, running bzr init isn't exactly the same when run locally as remotely [00:51] when run locally, it created an additional dir called checkout in project/.bzr [00:52] its probably because when you are doing it remotely, it defaults to --no-trees [00:52] mgrandi: that makes sense [01:18] when i commit files to a shared repository, are the files themselves transferred to the repo or just the history? [01:21] well the history is used to create the files [01:21] so, i dont think it really matters [01:21] either way you get your files back if you need to [01:22] mgrandi: should I be able to see the files on the remote server if i run: ls /project_folder ? [01:22] mgrandi: bzr log and update are both telling me that everything is ok, but I don't see any files on the server [01:22] like i said before, its probably defaulting to no-trees [01:23] so the data is there, but inside the .pack files [01:23] inside the .bzr folder [01:23] mgrandi: ok, i just want to make sure that this is the normal state of things [01:24] yeah, if your branch is bound to the remote server [01:24] or if you commit locally then push, they should be there [01:26] the branch is bound to the remote server and all of the messages indicated that the remote site was updated. [01:26] so there you go =) [01:26] the .pack file seems to be large enough to correct [01:26] binding means it won't succeed if it can't commit to both the server and locally so you are fine [01:27] is it safer to have the repo store the tree, too? it seems like it would be easier to recover the files that way [01:28] like that in the worst case scenario, you lose the history, but still have the most recently committed files [01:28] am i just looking at this incorrectly? [01:33] can i have multiple identities in bzr? [01:35] sorry, never mind, I found it in the docs [01:43] it doesn't matter if it has the tree, you just branch it again [01:44] mgrandi: ok, thanks [18:22] Does anyone know what the differences between "bzr unknown" and "bzr st" [18:22] ? [18:23] The two commands always list what's knew, right? [18:23] *new === yofel_ is now known as yofel [19:06] evillyEvil, unknown, as I understand it, are files that haven't been versioned by bzr [19:06] status tells you what files have changes [19:07] and what unknowns there ar [19:07] *are [19:07] beuno: So [bzr st] actually covers [bzr unknowns], right? [19:09] evillyEvil, yes [23:35] jave: you can use colocated branches with no plugin installed, that's how I work some time now (bzr 2.3 I think) [23:35] 1) you create a local repo storing only metadata, not data: [23:36] bzr init-repo --no-trees . [23:36] bzr branch $BRANCH_URL [23:36] 2) you create a local lightweight checkout in another dir: [23:37] cd $CHECKOUT_DIR [23:37] bzr checkout --lightweight $LOCAL_REPO_PATH [23:39] 3) you do all your work in the $CHECKOUT_DIR, using "bzr branch -b" to create new branches and "bzr branch" to switch to existing ones. [23:40] This is a nice workflow, the whole /colocated/ terminology is unnecessary and the need to install a plug-in is false. [23:41] IMHO it should be documented in the primary documentation, the rumor a plug-in is needed is driving users away.