[00:00] <jelmer> not all that much before though, I think?
[00:00] <bob2> maybe a couple of months
[00:00] <bob2> feb iirc
[00:02] <bob2>  2005-03-09 04:08:15 UTC <- selfhosting as of then
[00:03] <jelmer> ah, cool.. so about a month before LCA
[00:03] <bob2> was in baz until then
[00:06]  * jelmer remembers meeting some baz developers back in the day.. :-)
[03:38] <kbulgrien> So I used bzr to control files in my home dir... so I could save config for when I reload.
[03:39] <kbulgrien> I loaded a new system, now I'd like to use bzr to update files.
[03:39] <kbulgrien> what's the proper way to set connect to the repo?
[03:39] <mgrandi> update the
[03:39] <mgrandi> files on your new system?
[03:39] <bob2> do you mean "check it out"
[03:39] <bob2> bzr get someurl
[03:40] <bob2> note that bzr doesn't version perms, so at least your .ssh needs fixing
[03:40] <kbulgrien> I guess, though in cvs land, checkout would tell me things "are in the way"
[03:40] <kbulgrien> I would imagine the already existing files are conflicted with what is in bzr
[03:40] <bob2> what do you want it to do then
[03:41] <mgrandi> i thought it does version perms
[03:41] <mgrandi> or is that jsut attributes?
[03:41] <lifeless> it versions executability
[03:41] <bob2> +x and that's it
[03:41] <mgrandi> ah
[03:41] <mgrandi> interesting
[03:41] <kbulgrien> well, I want the files to not be conflicted... so I can merge or whatever.
[03:41] <mgrandi> why only that?
[03:41] <mgrandi> well, you only want what is in the bzr repo right
[03:42] <mgrandi> you can just overwrite the old ones
[03:42] <kbulgrien> I want to compare with what is in bzr and maybe merge or replace.
[03:42] <mgrandi> you can check your repo to some tmp directory
[03:43] <mgrandi> run a diff
[03:43] <kbulgrien> So probably I should just checkout and then figure out from there.
[03:43] <mgrandi> yeah
[03:43] <mgrandi> checkout to ~/Desktop/tmp  or whatever
[03:43] <mgrandi> diff the two directories, then merge if you want to
[03:44] <kbulgrien> I guess the thing is, I want to carry on version control ... so I want the actual directory linked to bzr
[03:45] <mgrandi> then you can branch the directory into your home folder
[03:45] <mgrandi> if they conflict, then bzr will make you resolve it
[03:46] <kbulgrien> still trying to wrap my head around "distributed" vcs
[03:48] <mgrandi> this part is still the same as a non distributed vcs
[03:59] <kbulgrien> well, now it moved existing stuff to .moved... not what I wanted.
[04:00] <kbulgrien> Conflict adding file blah.  Moved existing file to blah.moved.
[04:00] <kbulgrien> That's a lot of busted stuff.
[04:01] <mgrandi> thats probably because the directory wasn't empty, hmm
[04:02] <mgrandi> but you want the files that you checked out anyway?
[04:02] <mgrandi> the only stuff in .moved are the things that it tried to add buty already existed
[04:03] <kbulgrien> well, I guess what I'm after is that I kind of want this virtual configuration that several different machines can reference.
[04:03] <kbulgrien> I
[04:03] <mgrandi> well, if you ever update the config
[04:04] <mgrandi> files you are keeping versioned
[04:04] <mgrandi> you simply commit that, and all the other machines will get it when they do bzr update
[04:05] <kbulgrien> well not really, I think I want each machine to be separate, but able to merge with others selectively... don't know if that makes sense or not
[04:06] <mgrandi> you can have a shared repo on a server, and a branch for each machine.
[04:07] <kbulgrien> I do have a shared repo set up.
[04:07] <mgrandi> so, make a branch for each machine
[04:08] <kbulgrien> I have a branch for this system, but now I want to re-associate these files with that repo and I'd rather it didn't do all the .moved stuff.
[04:08] <mgrandi> you checked out the files from that branch into your home dir right?
[04:08] <kbulgrien> I wiped the system and now am trying to reconnect to the repo.
[04:09] <kbulgrien> yes
[04:09] <mgrandi> so yeah, its already assosciated, you can do 'bzr bind <url>"
[04:09] <mgrandi> and that way when you commit, it will commit to the repo branch as well
[04:09] <kbulgrien> I guess it is a technicality that it made a mess by creating all those .moved files.
[04:10] <mgrandi> whats in the .moved files, the files that you are versioning?
[04:10] <mgrandi> (or the copies that were there hwen you checked out)
[04:10] <kbulgrien> find . -name "*.moved" -exec rm -f {} \;
[04:10] <mgrandi> yeah, you can just delete that folder or not version it, your choice
[04:10] <mgrandi> bzr doesn't want to wipe out files that exist when you check out, so its just being safe!
[04:10] <kbulgrien> but then I sort of think it would have made sense to be able to keep local create a conflict without renaming all the files.
[04:11] <kbulgrien> That's how cvs would have done it.
[04:11] <mgrandi> well it would of conflicted, but you checked out for the first time
[04:11] <mgrandi> into a directory that had non versioned files in it, so thats why it did  that
[04:11] <mgrandi> now, if you update in the future, if it conflicts it will make you resolve the conflicts
[04:13] <kbulgrien> I think that's not friendly at all because that can make a big mess.
[04:14] <mgrandi> i mean, would you rather have it overwrite the files losing data?
[04:14] <kbulgrien> but maybe that is just me not being in the bzr mindset.
[04:14] <mgrandi> its just because you checked out data for the first time in a non empty directory
[04:14] <kbulgrien> No, I think it should decline to put them there and when I bzr status, it tells me that there is a conflict
[04:15] <kbulgrien> then I have to do something on a file by file basis to clear the conflict.  As it is, it moved perfectly good files out of the way.
[04:15] <kbulgrien> I think I should be able to say, don't go moving my crap for me.
[04:16] <mgrandi> well, thats true, but all of those files were files that were in the branch that you checked out, you wanted ones from the repo anyway right?
[04:16] <mgrandi> i see your point
[04:16] <kbulgrien> not necessarily.
[04:16] <kbulgrien> This is a new install.
[04:16] <mgrandi> im not an expert, but either way, you have the original and the branch version, you can manually move them back, which is almost the same as resolving a conflict
[04:16] <kbulgrien> The repo might not match the new install.  I'd rather deal with them one by one than the whole mess.
[04:17] <mgrandi> true
[04:18] <kbulgrien> sure, I know I can deal with it... I'd just rather not have a bazillion .moved files. I'd rather have some virtual indication of a conflict.
[04:18] <mgrandi> there might be a way to do that
[04:18] <mgrandi> im not a super expert at bzr
[04:20] <kbulgrien> So I guess, my question should have been... can I checkout without it moving all the preexisting files that will conflict when I checkout.
[04:21] <mgrandi> im not sure, maybe, maybe not, if someone else can weigh in
[04:24] <kbulgrien> I see I'm not the first to ask this question... stackoverflow has a post... someone said the poster could file a bug if he wanted to.
[04:26] <mgrandi> i can for you if you don't want to
[04:26] <mgrandi> link to the stackoverflow post would be good
[04:31] <kbulgrien> ah... was googling to see other people's threads that had more substance.
[04:32] <kbulgrien> http://stackoverflow.com/questions/2663846/stop-bazaar-bzr-from-making-moved-files
[04:33] <kbulgrien> Well, I don't want to come in a newbie and say bzr is broke without trying to think about it more.
[04:33] <kbulgrien> Its just I do not get amused when something renames dozens of files and I had no say about it.
[04:34] <spiv> kbulgrien: I think it's a legitimite gripe, bzr could probably do better here
[04:35] <spiv> Although judging from past discussions on the topic finding a strategy that always works well for everyone is probably impossible.
[04:36] <spiv> Scattering the .moved files everywhere without warning wouldn't be so bad if there were an easy way to get bzr to undo it
[04:36] <kbulgrien> well, even an option would help... newb is probably going to bzr help checkout... and then something in help could say or deal with that, but it doesn't
[04:37] <kbulgrien> There is no warning at all that if you do this, potentially hundreds of files will get renamed.
[04:37] <kbulgrien> I did that in a source tree a couple of weeks ago... not realizing.  What a freaking mess
[04:37] <spiv> Right.
[04:37] <spiv> It's tedious at best to fix (whether by hand or writing some sort of script)
[04:38] <kbulgrien> I realize once I have experience hopefully I will know better, but then I also know even when I am experienced I make mistakes.
[04:38] <spiv> Indeed!
[04:39] <kbulgrien> and sometimes, the mistakes made by an experienced person are more huge than the ones made by newbies.
[04:39] <kbulgrien> :-)
[04:39] <spiv> Which is why ideally mistakes either shouldn't cost too much, and/or be easy to undo.
[04:39] <spiv> Hehe
[04:39] <spiv> And lots of version control features are great: you can revert, uncommit, in general look at old history etc
[04:40] <spiv> But the .moved behaviour really breaks you out of that
[04:40] <spiv> Because while in principle all your precious bytes are still intact somewhere it's a PITA to get them back in the shape you want them.
[04:40] <kbulgrien> cvs screams at me... there is a file in the way... and it does nothing except scream about a conflict until I resolve it.  I kind of like that.
[04:41] <kbulgrien> but I suppose there will be people who feel the reverse.
[04:41] <spiv> So I find that fear of .moved really slows me down because I have to anticipate when it might happen so I can avoid it :(
[04:42] <mgrandi> well you can't really revert it becuase those files arn't in version control, but yeah
[04:42] <mgrandi> i feel bzr should warn, like the --use-existing-dir
[04:42] <spiv> "slows down" might be a bit of a strong claim, but it does feel like some sort of mental drag.
[04:42] <spiv> mgrandi: well, as a hypothetical, bzr could version them if it's worried you might lose them!
[04:43] <kbulgrien> maybe, but then that means it automatically creats a branch, right, and I'm not sure about that either.
[04:43] <spiv> (Perhaps in a separate temp repo to avoid polluting your main one if you want to be finicky etc, my point is the tool could be better)
[04:44] <spiv> I mean, here we have a tool that's all about saving history, that you can rely on to not lose old revisions
[04:44] <spiv> And has all sorts of clever code to do that nicely
[04:44] <kbulgrien> I wonder how etckeeper works.
[04:44] <spiv> And then for this case it's like you're dropped into the stone age of version control again
[04:44] <kbulgrien> I am also trying to version OS files.
[04:45] <spiv> Where people manually rename foo.txt to foo.txt.bak, or foo.txt.bak.bak.bak ;)
[04:45] <kbulgrien> perms saved me, but it did try to move boot to boot.moved.
[04:46] <spiv> IIRC etckeeper writes out the extra metadata about perms to a file and gets bzr to version that, and probably has a bunch of policy layered on top to give nicer merge defaults for config files
[04:46] <spiv> I expect its docs would explain :)
[04:46] <kbulgrien> yeah, just haven't got as far as installing it.
[04:47] <mgrandi> what is etckeeper?
[04:47] <kbulgrien> didn't realize it was a front end to vcs until just the other day.
[04:47] <kbulgrien> http://joey.kitenet.net/code/etckeeper/
[04:47] <kbulgrien> I wish more distributions packaged it.
[04:48] <kbulgrien> more being more than fedora
[04:49] <kbulgrien> oh, i see debian and ubuntu package it but they are .deb.  I think there are repackagers that can convert to .rpm and the like.
[04:50] <mgrandi> ah interesting.
[04:51] <kbulgrien> ( I tried to rebuild the rpm from el/fedora and it wouldn't due to .spec problem I didn't figure out)
[04:53] <mgrandi> ah
[04:53] <mgrandi> debs and rpms are black magic
[04:54] <kbulgrien> https://www.linux.com/learn/tutorials/512306-weekend-project-control-your-configuration-with-etckeeper
[04:57] <kbulgrien> anyway, etckeeper was a bit of a rabbit trail, but .moved is related because .moved in version controlled OS files is bad.
[04:58] <mgrandi> you can try posting on the mailing list about it
[04:58] <mgrandi> im curious on what other people say about it
[07:24] <wgz> pre morning all
[07:24] <mgrandi> hey wgz
[07:25] <mgrandi> it is technically morning i guess
[07:27] <mgrandi> i figured out one of the problems i was having with fastimport
[07:40] <vila> hi all !
[07:43] <mgrandi> hi
[07:54] <vila> kbulgrien: I think what is you're after is getting your branch in some tmp dir *then* moving the '.bzr' directory (and only it) to '~' and *finally* do a 'bzr status'
[07:54] <poolie> hi vila, hi vgz,
[07:54] <poolie> mgrandi
[07:55] <mgrandi> still
[07:55] <mgrandi> vila, that seem slike a really hackish workaround =P
[07:56] <vila> mgrandi: it is :) But the point is to avoid generating '.moved' files ;)
[07:56] <mgrandi> i guess, i still think the workaround he said, where the files are just marked as conflicting if that happens
[07:57] <mgrandi> would be better
[07:57]  * vila nods
[07:57] <vila> But how would you call such operation ?
[07:57] <vila> poolie: hey !
[07:57] <mgrandi> what do you mean?
[07:58] <vila> checkout-in-an-existing-dir-but-please-dont-mess-it-up is a bit long ;)
[07:59] <vila> I mean bzr has no idea what the status of the existing file is
[07:59] <mgrandi> well it obviously knows if there is an existing file
[08:00] <mgrandi> cause it moves it
[08:00] <vila> but it cannot complete the checkout without moving it
[08:00] <vila> and merging  requires some knowledge about the actual tree
[08:01] <vila> that knowledge is missing in this particular case
[08:01] <mgrandi> hmm
[08:01] <mgrandi> would it be possible to do a merge once it moved it to .moved?
[08:01] <vila> Note that I'm explaining what is happening, not denying the usefulness of the feature
[08:02] <vila> I have the same use case myself (maintaining config files across several machines), but I use a different workflow
[08:03] <mgrandi> that way it can complete the checkout
[08:05] <vila> short answer: no
[08:06] <vila> a checkout is a pristine copy of a given revision
[08:06] <vila> bzr *does* a merge when pulling if you have uncommitted changes but in this case it knows what have been changed
[08:07] <vila> s/have/has/ ?
[08:07] <mgrandi> yeah
[08:08] <mgrandi> here it doesn't because it moved the files
[08:08] <vila> yeah, I didn't check the code but roughly I suspect it consider them unknown and as such cannot merge their content with the ones that are checked out
[08:10] <mgrandi> in any case, id make the case for a option to warn before it moves the files
[08:10] <mgrandi> like --use-existing-dir
[08:10] <vila> Note that a 'bzr resolve --take-this' should restore some sanity by getting the .moved files back but will record a deletion of the versioned files (which is not what kbulgrien want I'm pretty sure)
[08:10] <vila> yup, worth a bug
[08:10] <mgrandi> cause i got bitten by that
[08:10] <mgrandi> sometime in the past
[08:11] <vila> yeah, I suspect most of bzr users don't fall into the trap which is why no bugs (that I know of) was ever filed
[08:12] <mgrandi> but like you said, i dunno how one would fix the problem other then having an option
[08:12] <vila> Also note that the actual behavior is a legitimate use case
[08:12] <mgrandi> someone mentioned creating a temporary repository
[08:12] <mgrandi> yeah, having an option to either move files, merge them or abort seems like the ideal case
[08:13] <vila> yup, warns if files are in the way an requires an option to complete sounds fine
[08:14] <mgrandi> would a temporary branch work, in some temp directry?
[08:14] <mgrandi> add the original files and then try to merge the ones that are incoming from the real branch operation?
[08:15] <vila> ha, you'll run into the 'parallel import' issues I think (I can never remember which command allows one to use existing file-ids...)
[08:15] <vila> right, 'bzr add'
[08:16] <mgrandi> parallel import issues?
[08:16] <vila> bzr internally use file-ids to track renames
[08:17] <vila> a file-id is associated to a relative path in the tree when the file is added, then the file can be renamed but keeps its file-id
[08:17] <mgrandi> ah
[08:17] <vila> if the same relative path is added in a different branch, it receives a different file-id
[08:17] <mgrandi> and that confuses things?
[08:17] <vila> when both branches are merged, the file-ids conflict: parallel import
[08:18] <vila> it's the weak point in the rename tracking and we haven't fixed it yet :-/
[08:19] <mgrandi> how would it ideally be fixed?
[08:20] <vila> roughly by keeping track of aliases between file-ids so when looking at the history of a given file bzr an decide how to join/split the histories of different file-ids
[08:20] <vila> s/an/can/
[08:20] <mgrandi> so it would be able to tell that two different file-ids came from the same path? (aka same file)
[08:21] <vila> yes
[08:21] <mgrandi> ah
[08:22] <mgrandi> sounds like a lot of internal hacking to get that to work, but it would pay off if just to fixed the first issue
[08:24] <vila> mgrandi: 'first issue' means ?
[08:24] <vila> parallel import of kbulgrien use case ?
[08:24] <mgrandi> yeah
[08:24] <mgrandi> was gonna say moving files when checking out and files conflict
[08:26] <vila> sort of, in this case, the existing files probably have *no* file-ids at all so using the existing ones should do
[08:26] <mgrandi> true
[08:27] <mgrandi> its 1 am, not thinking straight haha
[08:27] <vila> doing a tmp branch and 'bzr add --file-ids-from <tmp branch>'  and then 'bzr merge' should also give better results but is almost as hackish as moving the '.bzr' directory and probably even scarier ;)
[08:28] <vila> mgrandi: well, parallel import is not something you want to think about without the clearest mind and a good understanding of the bzr merge internals ;-)
[08:29] <mgrandi> heh i guess not
[08:29] <mgrandi> on that note i head to bed. night
[09:04] <mgz> morning all!
[12:32]  * jelmer sees a fairly scary patch to bzrlib/win32utils.py
[12:40] <mgz> hm, it's not really as bad as it looks, but I'm not sure Alexander's suggestion to add specific detection for argument skew was really the right thing
[13:00] <kbulgrien> vila: I don't mind hearing your workflow.  I am just doing things the way I do them with the other vcs I use a lot.
[13:01] <kbulgrien> I also am not entirely opposed to idea given regarding moving of .bzr folder.  It's not like I didnt do hackish stuff at times with the other vcs.
[13:02] <kbulgrien> I still think, however, that the .moved behavior is unpleasant.
[13:03] <kbulgrien> Anyway, work beckons and I have to go use my old vcs for a while until I get them to jump over to bzr (which I intend to do).
[13:03] <vila> my workflow involves a script that creates a bunch of symlinks (based on a textual description mapping a tree kept under version control  ans symlinks under my home directory). The script makes backups when it encounters files or directories where it want to install the symlinks
[13:03] <vila> I agree the .moved behavior is unpleasant in your use case ;)
[13:05] <kbulgrien> I created a big script called os2cvs a long time ago.  i have a very short os2bzr script that deals only with perms.  I was hoping to not write my own big front end again.
[13:05] <vila> but really checkout doesn't expect anything in its way so what you may do is cheat: create a clean branch and working tree somewhere, move the '.bzr' and do 'bzr st' and/or 'bzr diff'
[13:05] <vila> s/the '.bzr'/& directory where you want it to live/
[13:07] <kbulgrien> I will try that on for size.  Thanks.
[13:07] <vila> kbulgrien: but are you interested in keeping your home directory under vc or /etc ? There are different issues for each
[13:07] <vila> my remarks above are for ~
[13:08] <kbulgrien> both, but I deal with both differently.
[13:08] <kbulgrien> Part of my concern is for the day I switch over at work.
[13:09] <kbulgrien> When I convert the big giant repositories to bzr... everyone will have workspaces that are not in bzr, but are current works in progress
[13:09] <vila> right, etckeeper is probably what you want for etc (I have a completely different workflow for /etc myself coping with all OSes I had to admin and etckeeper didn't exist when I started)
[13:09] <kbulgrien> When they try to switch them over from old VCS to new VCS, bam.
[13:09] <vila> right
[13:10] <kbulgrien> Now I realize we probably have to checkout to different sandbox and manually merge, but that seems an unnecessary pain.
[13:11] <kbulgrien> Sure, re etckeeper.  I only just realized a few days ago it was a front end that used bzr underneath.
[13:11] <vila> right, what you want is a way to say: here is a non-versioned tree, how does it compare to some versioned tree and how can I converge. Right ?
[13:11] <kbulgrien> I just had already started using my own process and haven't d/l and looked at it yet.
[13:11] <kbulgrien> That's right.
[13:12] <kbulgrien> I want to keep the pain factor low.  My coworkers are going to hate moving as it is.
[13:12] <vila> but their trees are not under vc right now right ?
[13:12] <kbulgrien> another vc, not bzr, but I would convert the old vc repo to bzr.  I tested that already.
[13:13] <vila> oh, things may be a bit different in this case
[13:13] <kbulgrien> I realize having used old vc, I may have a different world view that I am willing to adjust, except that one reason bzr made the cut was because of all the new vc, it let me change my worldview the least.
[13:14] <kbulgrien> I'm not really sure how they would be different.
[13:15] <vila> right, that's nice to say, and yes, some things are the same, others are different or new, so indeed your have some work/experiments to do to feel at ease
[13:15] <vila> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief have a good definition of some basic concepts
[13:16] <kbulgrien> ok.  will look at it.  right now I am late for work... too bad because this discussion is helful for work too.
[13:16] <kbulgrien> and I am not allowed to use resources like this there.
[13:16] <vila> :-/
[13:17] <vila> Try the mailing list may be ?
[13:17] <kbulgrien> yeah, I need to do that.  Besides, its more friendly that things worked out are then archived for others use.
[13:17] <kbulgrien> nothing like instant gratification though, eh?
[13:18] <kbulgrien> :-)
[13:18] <kbulgrien> anyway... later... and thanks.
[13:18] <vila> have a nice day ;)
[16:19] <dakira> hi. i'm new to collaborating so I have a question. I just pulled a project (which I'm not a member of) from launchpad and fixed a bug. Is there an automatic way to get my fix to the dev or do I have to manually create a patch, file a bugreport and attach the patch to the bugreport?
[16:20] <dakira> What is the proposed way to handle such things?
[16:32] <mgz> you push your branch up to your namespace, and propose a merge, generally
[16:34] <mgz> so, `bzr branch lp:foo` `cd foo` ...fix stuff in foo and commit... `bzr push lp:~/foo/name_for_your_changes`
[16:35] <mgz> then can do a merge proposal via the website, or `bzr lp-propose`
[16:35] <dakira> mgz: okay thanks!
[16:38] <mgz> working on ubuntu packaging rather than directly upstream with launchpad is a little different, but same general idea
[17:56] <mgrandi> hallo
[19:16] <m4n1sh> using bzrlib how can I find out the files changed for a particular commit if i have the revision number?
[19:18] <mgrandi> not sure, i dont know bzrlib that well, maybe someone else can answer
[19:36] <m4n1sh> jelmer: ping
[22:26] <bzrperson> If I bzr shelve something, does it get saved on the server with bzr push?
[22:27] <bzrperson> I'm moving HDs and don't want to commit the current things, but do want them saved
[22:33] <wgz> bzrperson: nope, it's local to the tree, not the branch
[22:33] <bzrperson> OK
[22:33] <wgz> bzrperson: just commit and push to another branch
[22:34] <wgz> leaving your main branch as is
[22:35] <bzrperson> Oh
[22:35] <bzrperson> Alright
[22:37] <wgz> you can cherrypick merge it back to your main branch later if you like :)
[22:44] <poolie> hi all