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