[00:04] <kbulgrien> interesting... bzr status sometimes fails to report status if the file happens to not have read perms for the user.
[00:05] <kbulgrien> ie `bzr add this; bzr status` shows added.
[00:05] <kbulgrien> `bzr add this; chmod a-r this; bzr status` shows nothing
[00:06] <kbulgrien> `bzr add this; chmod a-r this; bzr status this` shows status
[00:06] <kbulgrien> really, there's a good reason I'd like status in this case...
[00:07] <kbulgrien> but I guess that's kind of wierd.  oh well.
[00:07] <kbulgrien> hmm. I wonder if that is true for both heavy and light checkouts.  I'm in a light checkout.
[00:10] <kbulgrien> hmm. something happened.  maybe I was crosseyed.  It's now showing status.
[00:11] <kbulgrien> I was crosseyed.
[00:25] <kbulgrien> hum. somehow I have made things so bzr status hangs.
[00:27] <kbulgrien> strace is unhelpful
[00:29] <kbulgrien> I guess I am hosed.  I don't know how to fix.
[00:31] <kbulgrien> bzr check shows nothing bad.
[01:00] <kbulgrien> afaict, only bzr status is messed.
[01:02] <kbulgrien> And as long as I put in explicit file names, bzr status is ok, just not `bzr status` or it hangs solid.
[02:41] <kbulgrien> appears that 2.5.0 has the problem fixed.\
[02:58] <kbulgrien> for that matter 2.4.2 is fixed.
[03:32] <kbulgrien> head is hurting.  having hard time figuring out what I did wrong.  set up repo, init an area under it, checked out somewhere else. added, committed, but can't see anything going into the repo.
[03:33] <kbulgrien> Anyone want to help.  Shared repo tutorial isnt very tutorial
[03:56] <stlsaint> i changed my default python now bzr has stopped working
[04:16] <bob2> what did you change it to
[04:16] <bob2> kbulgrien, it's unclear what you did
[04:17] <bob2> pastebin shell history?
[04:23] <kbulgrien> well, shell history is so scattered, not sure pastebin will help here.
[04:24] <kbulgrien> I guess I could pastebin a reconstruction
[04:24] <kbulgrien> I don't know how to set up a new "lockstep" project.
[04:25] <kbulgrien> I've obviously done it wrong because there is nothing going into the shared repo
[04:25] <kbulgrien> I can't push or pull
[04:25] <kbulgrien> It says there's nothing.
[04:26] <kbulgrien> the shared repo data shows the revision that is in my checkout, but all the goods are in the checkout and won't go up into the repo
[04:29] <bob2> I think you're just confused about trees vs branches
[04:29] <kbulgrien> I come from cvs background
[04:30] <bob2> condolences
[04:30] <kbulgrien> it works
[04:30] <kbulgrien> no need to feel sorry
[04:30] <bob2> anyway, it's still not clear what you're saying, to me
[04:31] <bob2> do you mean "I made a repo, with init-repo --no-trees, then did 'bzr init' in some dir, then added and commited some files, then pushed to the repo, but the 'branch' dir, in the repo, is empty?"?
[04:33] <kbulgrien> bzr init-repo --no-trees top; bzr init-repo --no-trees top/mid; bzr init top/mid/bot;
[04:34] <kbulgrien> somewhere else I did bzr checkout --lightweight top/mid/bot .
[04:34] <kbulgrien> I probably should not have done --lightweight
[04:34] <kbulgrien> I did adds and commits in the checkout.
[04:34] <bob2> why did you make two nested repositories?
[04:35] <bob2> and is the problem you're asking about that 'top/mid/bot' doesn't have all your files in it?
[04:35] <kbulgrien> I thought I was making a repository for multiple projects
[04:35] <bob2> not sure what you mean
[04:35] <bob2> but you don't need (or want) to nest repos
[04:35] <bob2> just init a branch somewhere inside the repository
[04:36] <kbulgrien> yes, there are no files in top/mid/bot
[04:36] <bob2> that's what no-trees means
[04:36] <bob2> all the rev data is in .bzr in the /repo root/ and .bzr in the /branch/ has some pointers (and no data itself)
[04:36] <kbulgrien> then why do docs say to use no-trees for centralized server repos
[04:36] <bob2> because it's a good idea
[04:36] <bob2> since 'bzr push' doesn't update checked out files
[04:36] <kbulgrien> what is a centralized server if it has no data
[04:36] <bob2> and newbies get immensely confused by that
[04:36] <bob2> :-/
[04:37] <bob2> it has /all the revision data/
[04:37] <bob2> 15:36:28 < bob2> all the rev data is in .bzr in the /repo root/ and .bzr in the /branch/ has some pointers (and no data itself)
[04:37] <kbulgrien> The commit comments don't do me any good without the data
[04:37] <bob2> you're confused
[04:37] <bob2> all the data is there
[04:37] <bob2> there is just no checked out copies of the working tree
[04:37] <bob2> that's what --no-trees does - not check out the files
[04:37] <kbulgrien> I am looking at the file system.
[04:37] <kbulgrien> there is no data
[04:37] <kbulgrien> only meta data
[04:38] <bob2> false, fortunately
[04:38] <bob2> one last time: all the revision data is in the .bzr dir of the /repository/ (ie in the root), the .bzr dir in the /branch in the repo/ just refers to the revision data in the repo itself
[04:39] <kbulgrien>  du
[04:39] <kbulgrien> 1.0K	./.bzr/branch-lock
[04:39] <kbulgrien> 1.0K	./.bzr/branch/lock
[04:39] <kbulgrien> 5.0K	./.bzr/branch
[04:39] <kbulgrien> 9.0K	./.bzr
[04:39] <kbulgrien> 10K	.
[04:39] <bob2> this is all unrelated to whether there is a workign tree or not
[04:39] <kbulgrien> I committed more than 10k
[04:39] <bob2> please read what I said
[04:39] <bob2> that's the contents of top/mid/bot/.bzr
[04:39] <bob2> "the .bzr dir in the /branch in the repo/ just refers to the revision data in the repo itself"
[04:39] <bob2> "all the revision data is in the .bzr dir of the /repository/ (ie in the root)" -> du -sh top/mid/.bzr
[04:40] <kbulgrien> ok
[04:40] <kbulgrien> I see that
[04:41] <kbulgrien> I think
[04:42] <kbulgrien> yes. I see a repository folder that has packs and stuff.
[04:42] <bob2> bzr has branches (mutable pointers to a revision), repositories (big piles of revision data) and working trees (your checked out files, with enough info to be able to get pristine copies)
[04:42] <bob2> ^ important model information
[04:46] <kbulgrien> well, I can see what youre saying, but setting up a repository to me isn't nearly so clear as for cvs.
[04:46] <kbulgrien> I don't know that I've done what I wanted to do.
[04:47] <bob2> I'd start over
[04:47] <bob2> cd /srv/bzr ; bzr init-repo --no-trees something
[04:47] <bob2> mkdir something/projectname/branchname
[04:47] <bob2> cd !$
[04:47] <bob2> bzr init
[04:47] <kbulgrien> you do nothing at the projectname level?
[04:47] <bob2> cd ~/something
[04:48] <bob2> bzr checkout /srv/bzr/something/projectname/branchname projectname
[04:48] <bob2> cd projectname
[04:49] <bob2> bzr add .... ; bzr commit -m'first commit111'
[04:49] <bob2> correct
[04:49] <kbulgrien> ok
[04:50] <bob2> ^ so it's just a matter of: make a repo (one time thing), make a branch in it (per-branch thing), check it out somewhere and then use it
[04:54] <kbulgrien> ok, thanks for your patience.
[04:54] <bob2> progress?
[04:55] <kbulgrien> well, I'm doing something a bit unconventional, so the setup is a little more complex than that.
[04:55] <bob2> unconventional how?
[04:55] <kbulgrien> perms and stuff
[04:56] <kbulgrien> I'm trying to version control changes I make to an OS.
[04:57] <bob2> do you mean /etc
[04:57] <kbulgrien> yeah, but sparsely
[04:57] <kbulgrien> I only track what I mess with.
[04:58] <bob2> I'd not bother and instead use etckeeper
[04:59] <kbulgrien> I'll look it up.  Part of the thing is that I need/want to learn bzr so I can transition workk over.
[05:00] <kbulgrien> I'm not really using it to preserve etc, but to preserve the knowledge of what I have to tweak to do what I want to do.
[05:00] <kbulgrien> I'm not really backing up etc per se.
[05:02] <kbulgrien> ah, its a frontend to bzr...
[05:02] <kbulgrien> to do this in cvs I wrote my own front end
[05:02] <bob2> (and git and hg)
[05:02] <kbulgrien> ok
[05:02] <kbulgrien> well, then it bears looking at for sure.
[05:03] <kbulgrien> I already had to make a wrapper script for files I had to sudo to get access to.
[05:03] <kbulgrien> but it was way simpler than what I had to do for cvs
[05:13] <kbulgrien> cool
[05:13] <kbulgrien> okay, managed to even keep the history in the checkout
[05:13] <kbulgrien> and then I checked out somewhere else and got the goods.
[05:14] <kbulgrien> I was able to push the original checkout into the remade repository.
[05:15] <kbulgrien> now the data is under "top/.bzr""
[05:16] <kbulgrien> well even if I should have used etckeeper for this, it gave me a real world problem to solve that forced some learning.
[05:17] <kbulgrien> in the process, I found that 2.3.1 (mageia) had a bug with respect to no read perms in the checkout.
[07:35] <sbarcteam> hi.
[07:35] <sbarcteam> Let's assume I have a repository at rev. N
[07:37] <sbarcteam> I have a checkout branch (with bound=True)
[07:37] <sbarcteam> at location B at the same revision.
[07:37] <sbarcteam> (the 1st repo is at location A)
[07:38] <sbarcteam> now, I am doing changes in B, and do a normal commit (not the one with --local)
[07:38] <sbarcteam> and before that commmit I do some changes in A
[07:38] <sbarcteam> and do not commit them.
[07:39] <sbarcteam> so, I have 1) dirty working dir, 2) updates on the way already in the repo history
[07:39] <sbarcteam> I want to merge both the update and the dirty working dir.
[07:39] <sbarcteam> what is the right (bzr) way to do this ?
[07:40] <sbarcteam> I thought I could commit the dirty work dir, but bzr doesn't allow.
[07:42] <lifeless> you can commit --local, or you can just update.
[07:42] <lifeless> I would just update.
[07:43] <sbarcteam> #lifeless: so, If I commit --local and then
[07:43] <sbarcteam> there's importance to not
[07:43] <lifeless> or you could shelve the work, and then update and then unshelve
[07:43] <sbarcteam> shelving is not a good idea.
[07:44] <sbarcteam> It is a running django code.
[07:44] <sbarcteam> So I want to commit the work running, and merge it off-line, test it and only then to deploy the merged code.
[07:44] <sbarcteam> What would happen if I uncommit on the location B.
[07:44] <sbarcteam> then commit on A,
[07:45] <lifeless> you can use merge --uncommitted to grab the uncommitted work.
[07:45] <sbarcteam> then update on B
[07:45] <sbarcteam> and remerge.
[07:45] <lifeless> that work work too
[07:45] <sbarcteam> OK.
[07:46] <sbarcteam> So: on B (the checkout branch) uncommit the last merge, then on A: commit changes, then on B: update, and merge.
[07:46] <sbarcteam> right ?
[07:46] <sbarcteam> (and then I'd have to update A of course)
[07:49] <lifeless> yes
[10:00] <wilx> Can bzr sign-my-commits not use keychain/gpg-agent?
[12:27] <hno> Is it possible to "unmerge" a merge in such way that it do not get expunged from the originating branch if it later pulls/merges changes?
[12:28] <wilx> I do not understand the question entirely. However, it is possible to uncommit the last commit.
[14:16] <maxb> hno: Only if you can uncommit the merge commit, or arrange for the originating branch to (merge; revert .) the unmerging commit
[15:01] <hno> maxb, ok, not quite what I am looking for.
[15:02] <hno> It's very unlikely it's the last commit. May be many versions back, and development in the branch may have continued after merge.
[15:07] <hno> I guess what I am really looking for is kind of a large distributed bzr-loom with loose threading.
=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel
=== Omni|Work is now known as Omni|AFK