[00:00] not all that much before though, I think? [00:00] maybe a couple of months [00:00] feb iirc [00:02] 2005-03-09 04:08:15 UTC <- selfhosting as of then [00:03] ah, cool.. so about a month before LCA [00:03] was in baz until then [00:06] * jelmer remembers meeting some baz developers back in the day.. :-) === Ursinha is now known as Ursinha-away [03:38] So I used bzr to control files in my home dir... so I could save config for when I reload. [03:39] I loaded a new system, now I'd like to use bzr to update files. [03:39] what's the proper way to set connect to the repo? [03:39] update the [03:39] files on your new system? [03:39] do you mean "check it out" [03:39] bzr get someurl [03:40] note that bzr doesn't version perms, so at least your .ssh needs fixing [03:40] I guess, though in cvs land, checkout would tell me things "are in the way" [03:40] I would imagine the already existing files are conflicted with what is in bzr [03:40] what do you want it to do then [03:41] i thought it does version perms [03:41] or is that jsut attributes? [03:41] it versions executability [03:41] +x and that's it [03:41] ah [03:41] interesting [03:41] well, I want the files to not be conflicted... so I can merge or whatever. [03:41] why only that? [03:41] well, you only want what is in the bzr repo right [03:42] you can just overwrite the old ones [03:42] I want to compare with what is in bzr and maybe merge or replace. [03:42] you can check your repo to some tmp directory [03:43] run a diff [03:43] So probably I should just checkout and then figure out from there. [03:43] yeah [03:43] checkout to ~/Desktop/tmp or whatever [03:43] diff the two directories, then merge if you want to [03:44] I guess the thing is, I want to carry on version control ... so I want the actual directory linked to bzr [03:45] then you can branch the directory into your home folder [03:45] if they conflict, then bzr will make you resolve it [03:46] still trying to wrap my head around "distributed" vcs [03:48] this part is still the same as a non distributed vcs [03:59] well, now it moved existing stuff to .moved... not what I wanted. [04:00] Conflict adding file blah. Moved existing file to blah.moved. [04:00] That's a lot of busted stuff. [04:01] thats probably because the directory wasn't empty, hmm [04:02] but you want the files that you checked out anyway? [04:02] the only stuff in .moved are the things that it tried to add buty already existed [04:03] well, I guess what I'm after is that I kind of want this virtual configuration that several different machines can reference. [04:03] I [04:03] well, if you ever update the config [04:04] files you are keeping versioned [04:04] you simply commit that, and all the other machines will get it when they do bzr update [04:05] 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] you can have a shared repo on a server, and a branch for each machine. [04:07] I do have a shared repo set up. [04:07] so, make a branch for each machine [04:08] 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] you checked out the files from that branch into your home dir right? [04:08] I wiped the system and now am trying to reconnect to the repo. [04:09] yes [04:09] so yeah, its already assosciated, you can do 'bzr bind " [04:09] and that way when you commit, it will commit to the repo branch as well [04:09] I guess it is a technicality that it made a mess by creating all those .moved files. [04:10] whats in the .moved files, the files that you are versioning? [04:10] (or the copies that were there hwen you checked out) [04:10] find . -name "*.moved" -exec rm -f {} \; [04:10] yeah, you can just delete that folder or not version it, your choice [04:10] bzr doesn't want to wipe out files that exist when you check out, so its just being safe! [04:10] 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] That's how cvs would have done it. [04:11] well it would of conflicted, but you checked out for the first time [04:11] into a directory that had non versioned files in it, so thats why it did that [04:11] now, if you update in the future, if it conflicts it will make you resolve the conflicts [04:13] I think that's not friendly at all because that can make a big mess. [04:14] i mean, would you rather have it overwrite the files losing data? [04:14] but maybe that is just me not being in the bzr mindset. [04:14] its just because you checked out data for the first time in a non empty directory [04:14] 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] 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] I think I should be able to say, don't go moving my crap for me. [04:16] 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] i see your point [04:16] not necessarily. [04:16] This is a new install. [04:16] 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] The repo might not match the new install. I'd rather deal with them one by one than the whole mess. [04:17] true [04:18] 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] there might be a way to do that [04:18] im not a super expert at bzr [04:20] 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] im not sure, maybe, maybe not, if someone else can weigh in [04:24] 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] i can for you if you don't want to [04:26] link to the stackoverflow post would be good [04:31] ah... was googling to see other people's threads that had more substance. [04:32] http://stackoverflow.com/questions/2663846/stop-bazaar-bzr-from-making-moved-files [04:33] Well, I don't want to come in a newbie and say bzr is broke without trying to think about it more. [04:33] Its just I do not get amused when something renames dozens of files and I had no say about it. [04:34] kbulgrien: I think it's a legitimite gripe, bzr could probably do better here [04:35] Although judging from past discussions on the topic finding a strategy that always works well for everyone is probably impossible. [04:36] 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] 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] There is no warning at all that if you do this, potentially hundreds of files will get renamed. [04:37] I did that in a source tree a couple of weeks ago... not realizing. What a freaking mess [04:37] Right. [04:37] It's tedious at best to fix (whether by hand or writing some sort of script) [04:38] 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] Indeed! [04:39] and sometimes, the mistakes made by an experienced person are more huge than the ones made by newbies. [04:39] :-) [04:39] Which is why ideally mistakes either shouldn't cost too much, and/or be easy to undo. [04:39] Hehe [04:39] And lots of version control features are great: you can revert, uncommit, in general look at old history etc [04:40] But the .moved behaviour really breaks you out of that [04:40] 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] 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] but I suppose there will be people who feel the reverse. [04:41] 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] well you can't really revert it becuase those files arn't in version control, but yeah [04:42] i feel bzr should warn, like the --use-existing-dir [04:42] "slows down" might be a bit of a strong claim, but it does feel like some sort of mental drag. [04:42] mgrandi: well, as a hypothetical, bzr could version them if it's worried you might lose them! [04:43] maybe, but then that means it automatically creats a branch, right, and I'm not sure about that either. [04:43] (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] 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] And has all sorts of clever code to do that nicely [04:44] I wonder how etckeeper works. [04:44] And then for this case it's like you're dropped into the stone age of version control again [04:44] I am also trying to version OS files. [04:45] Where people manually rename foo.txt to foo.txt.bak, or foo.txt.bak.bak.bak ;) [04:45] perms saved me, but it did try to move boot to boot.moved. [04:46] 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] I expect its docs would explain :) [04:46] yeah, just haven't got as far as installing it. [04:47] what is etckeeper? [04:47] didn't realize it was a front end to vcs until just the other day. [04:47] http://joey.kitenet.net/code/etckeeper/ [04:47] I wish more distributions packaged it. [04:48] more being more than fedora [04:49] 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] ah interesting. [04:51] ( I tried to rebuild the rpm from el/fedora and it wouldn't due to .spec problem I didn't figure out) [04:53] ah [04:53] debs and rpms are black magic [04:54] https://www.linux.com/learn/tutorials/512306-weekend-project-control-your-configuration-with-etckeeper [04:57] anyway, etckeeper was a bit of a rabbit trail, but .moved is related because .moved in version controlled OS files is bad. [04:58] you can try posting on the mailing list about it [04:58] im curious on what other people say about it [07:24] pre morning all [07:24] hey wgz [07:25] it is technically morning i guess [07:27] i figured out one of the problems i was having with fastimport [07:40] hi all ! [07:43] hi [07:54] 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] hi vila, hi vgz, [07:54] mgrandi [07:55] still [07:55] vila, that seem slike a really hackish workaround =P [07:56] mgrandi: it is :) But the point is to avoid generating '.moved' files ;) [07:56] i guess, i still think the workaround he said, where the files are just marked as conflicting if that happens [07:57] would be better [07:57] * vila nods [07:57] But how would you call such operation ? [07:57] poolie: hey ! [07:57] what do you mean? [07:58] checkout-in-an-existing-dir-but-please-dont-mess-it-up is a bit long ;) [07:59] I mean bzr has no idea what the status of the existing file is [07:59] well it obviously knows if there is an existing file [08:00] cause it moves it [08:00] but it cannot complete the checkout without moving it [08:00] and merging requires some knowledge about the actual tree [08:01] that knowledge is missing in this particular case [08:01] hmm [08:01] would it be possible to do a merge once it moved it to .moved? [08:01] Note that I'm explaining what is happening, not denying the usefulness of the feature [08:02] I have the same use case myself (maintaining config files across several machines), but I use a different workflow [08:03] that way it can complete the checkout [08:05] short answer: no [08:06] a checkout is a pristine copy of a given revision [08:06] bzr *does* a merge when pulling if you have uncommitted changes but in this case it knows what have been changed [08:07] s/have/has/ ? [08:07] yeah [08:08] here it doesn't because it moved the files [08:08] 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] in any case, id make the case for a option to warn before it moves the files [08:10] like --use-existing-dir [08:10] 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] yup, worth a bug [08:10] cause i got bitten by that [08:10] sometime in the past [08:11] 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] but like you said, i dunno how one would fix the problem other then having an option [08:12] Also note that the actual behavior is a legitimate use case [08:12] someone mentioned creating a temporary repository [08:12] yeah, having an option to either move files, merge them or abort seems like the ideal case [08:13] yup, warns if files are in the way an requires an option to complete sounds fine [08:14] would a temporary branch work, in some temp directry? [08:14] add the original files and then try to merge the ones that are incoming from the real branch operation? [08:15] 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] right, 'bzr add' [08:16] parallel import issues? [08:16] bzr internally use file-ids to track renames [08:17] 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] ah [08:17] if the same relative path is added in a different branch, it receives a different file-id [08:17] and that confuses things? [08:17] when both branches are merged, the file-ids conflict: parallel import [08:18] it's the weak point in the rename tracking and we haven't fixed it yet :-/ [08:19] how would it ideally be fixed? [08:20] 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] s/an/can/ [08:20] so it would be able to tell that two different file-ids came from the same path? (aka same file) [08:21] yes [08:21] ah [08:22] 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] mgrandi: 'first issue' means ? [08:24] parallel import of kbulgrien use case ? [08:24] yeah [08:24] was gonna say moving files when checking out and files conflict [08:26] sort of, in this case, the existing files probably have *no* file-ids at all so using the existing ones should do [08:26] true [08:27] its 1 am, not thinking straight haha [08:27] doing a tmp branch and 'bzr add --file-ids-from ' 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] 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] heh i guess not [08:29] on that note i head to bed. night [09:04] morning all! === Ursinha-away is now known as Ursinha [12:32] * jelmer sees a fairly scary patch to bzrlib/win32utils.py [12:40] 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] 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] 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] I still think, however, that the .moved behavior is unpleasant. [13:03] 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] 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] I agree the .moved behavior is unpleasant in your use case ;) [13:05] 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] 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] s/the '.bzr'/& directory where you want it to live/ [13:07] I will try that on for size. Thanks. [13:07] kbulgrien: but are you interested in keeping your home directory under vc or /etc ? There are different issues for each [13:07] my remarks above are for ~ [13:08] both, but I deal with both differently. [13:08] Part of my concern is for the day I switch over at work. [13:09] 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] 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] When they try to switch them over from old VCS to new VCS, bam. [13:09] right [13:10] Now I realize we probably have to checkout to different sandbox and manually merge, but that seems an unnecessary pain. [13:11] Sure, re etckeeper. I only just realized a few days ago it was a front end that used bzr underneath. [13:11] 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] I just had already started using my own process and haven't d/l and looked at it yet. [13:11] That's right. [13:12] I want to keep the pain factor low. My coworkers are going to hate moving as it is. [13:12] but their trees are not under vc right now right ? [13:12] another vc, not bzr, but I would convert the old vc repo to bzr. I tested that already. [13:13] oh, things may be a bit different in this case [13:13] 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] I'm not really sure how they would be different. [13:15] 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] http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief have a good definition of some basic concepts [13:16] ok. will look at it. right now I am late for work... too bad because this discussion is helful for work too. [13:16] and I am not allowed to use resources like this there. [13:16] :-/ [13:17] Try the mailing list may be ? [13:17] yeah, I need to do that. Besides, its more friendly that things worked out are then archived for others use. [13:17] nothing like instant gratification though, eh? [13:18] :-) [13:18] anyway... later... and thanks. [13:18] have a nice day ;) === yofel_ is now known as yofel [16:19] 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] What is the proposed way to handle such things? [16:32] you push your branch up to your namespace, and propose a merge, generally [16:34] so, `bzr branch lp:foo` `cd foo` ...fix stuff in foo and commit... `bzr push lp:~/foo/name_for_your_changes` [16:35] then can do a merge proposal via the website, or `bzr lp-propose` [16:35] mgz: okay thanks! [16:38] working on ubuntu packaging rather than directly upstream with launchpad is a little different, but same general idea === zyga is now known as zyga-food === zyga-food is now known as zyga [17:56] hallo [19:16] using bzrlib how can I find out the files changed for a particular commit if i have the revision number? [19:18] not sure, i dont know bzrlib that well, maybe someone else can answer [19:36] jelmer: ping === r0bby is now known as robbyoconnor === r0bby is now known as robbyoconnor [22:26] If I bzr shelve something, does it get saved on the server with bzr push? [22:27] I'm moving HDs and don't want to commit the current things, but do want them saved [22:33] bzrperson: nope, it's local to the tree, not the branch [22:33] OK [22:33] bzrperson: just commit and push to another branch [22:34] leaving your main branch as is [22:35] Oh [22:35] Alright [22:37] you can cherrypick merge it back to your main branch later if you like :) [22:44] hi all === mwhudson_ is now known as mwhudson