[00:17] <bob2> Demosthenex, sure, cherrypicking is a thing
[00:17] <bob2> Demosthenex, but in practice it'd often be better to not do that and instead make use of the templates and derive from them or whatever
[00:23] <Demosthenex> my example was where while making a document, a change should return to the parent to be included in new/updated docs from now on.
[00:24] <Demosthenex> obviously not everything should be ported back
[00:24] <Demosthenex> and the alternative is manually updating...
[00:25] <Demosthenex> the second example i have is another common one, where you have a standardized config file as the parent, each host has a branch with it's changes. why not push a single commit from a child back to parent, so it can push to the other children (ie: updating the standard)
[00:25] <Demosthenex> that is cherry picking?
[00:25] <lifeless> no
[00:25] <lifeless> cherry picking is merging a non-connected part of the history graph
[00:27] <Demosthenex> well, branching/merging tends to imply that changes will eventually return to the trunk...
[00:27] <Demosthenex> that's why i thought fork was right...
[00:27] <Demosthenex> parallel forks
[00:27] <Demosthenex> how can you exchange single commits when they share a parent?
[00:54] <bob2> cherry-pick
[01:09] <lifeless> or ensure they are teh first commit on the branch :)
[01:11] <Demosthenex> both examples start from a very slow to change parent... all the work is in the children.
[01:11] <Demosthenex> i'm thinking it sounds likely i just may do it manually :P
[01:11] <Demosthenex> i didn't see much in the bazaar site on cherry picking.
[01:13] <bob2> well, you'd need to read the manual
[01:15] <Demosthenex> http://wiki.bazaar.canonical.com/CherryPick
[01:16] <bob2> sure
[01:17] <lifeless> Demosthenex: I generally just make sure there is a branch which can be fully merged.
[01:17] <lifeless> Demosthenex: don't tangle up 'things you want to merge' and 'things you don't want to merge.'
[01:19] <Demosthenex> lifeless: i think that's the question... do i want to merge?
[01:19] <Demosthenex> it's just a common occurance, i'm using a documentatio template, it's small and contains code...
[01:20] <Demosthenex> i write a document, and change the code snippets (lots of docs, little code), and i want to push just the code portions that came from the template back
[01:20] <Demosthenex> right now i hand repeat those changes.
[01:20] <bob2> which is silly
[01:20] <bob2> either make the changes upstream or use cherry-pick
[01:21] <lifeless> right
[01:21] <Demosthenex> that's why i was asking if cherry picking might do it
[01:21] <lifeless> or use a third branch for those changes until you're satisfied and merge that branch both upstream and to your doc branch
[01:22] <lifeless> yes cherrypicking will copy patches, its basically the same as diff+patch
[01:22] <Demosthenex> i'm pretty sure i can isolate the changes that i want to a whole commit, thus my interest
[08:13] <_arch> Hey, I want to add a revno as a variable to each committed file. Any suggestions? I've tried to write a post_commit-hook but it does not seem to recognize changed files.
[08:13] <lifeless> post-commit would be too late
[08:13] <lifeless> there is a plugin for doing variable injections like that
[08:14] <_arch> The keyword-plugin?
[08:15] <bob2> suggest not doing that
[08:16] <_arch> at all? I don't like the idea much either but I need some way to get revno for each file a customer is using for support and debug :(
[08:16] <lifeless> _arch: do they have bzr?
[08:17] <lifeless> _arch: if so, just have them run 'bzr revision-info'
[08:18] <_arch> No. I'll try to explain
[08:18] <bob2> add it somewhere during your build process
[08:19] <_arch> The files run on an embedded system. Our customer gets modified files from us every now and then. They might not have to update all of the files on the system
[08:20] <_arch> they also might roll back on some of the files every now and then
[08:20] <bob2> use 'bzr revision-info' in your build script
[08:20] <lifeless> do they edit the files ?
[08:20] <_arch> no they don't
[08:20] <lifeless> If not, just ask them for the shasum of the file
[08:20] <lifeless> you can look that up
[08:21] <lifeless> or, as bob2 says, embed version info as you ship the file to the customer, rather than in VCS
[08:21] <_arch> can't look that up, because they don't remember which version of the file they are using and it's not trivial to get the shasum from the embedded system.
[08:21] <_arch> I guess that's a better way
[08:22] <_arch> it's a damn stupid problem anyway :)
[11:56] <hikiko> hello
[11:57] <hikiko> is there any bazaar command/option to see the differences between 2 different branches? (like bzr diff but for all files)
[14:19] <rly> Is there a gitk like tool for bzr?
[14:22] <rly> ALso, what's the command to delete all local changes like git reset --hard?
[14:24] <vila> rly:  try qbzr or bzr-gtk plugin
[14:24] <vila> rly:  probably 'bzr revert'
[14:25] <rly> vila: note that I didn't commit anything.
[14:26] <vila> right, so 'bzr revert' will  do (more explanations with 'bzr help revert')
[14:27] <rly> vila: how do I do the equivalent of git pull?
[14:27] <rly> vila: bzr merge does something different.
[14:28] <rly> It seems to be bzr update
[14:30] <vila> bzr pull ?
[14:35] <rly> vila: thanks
[14:36] <rly> I don't get why there are so many version control systems, but I suppose everyone must be thinking that everybody else before did it wrong.
[14:37] <LeoNerd> Often because projects have to get to a certain level before they become "public" enough that everyone else sees them, so you tend to get multiple differnet ones being started all at the same time
[14:38] <rly> So far I have used: cvs, svn, bzr, monotone, darcs,git,fossil,veracity,mercurial, and I am sure I am forgetting a few.
[14:39] <LeoNerd> p4?
[14:39] <rly> No
[14:39] <LeoNerd> Ah.. lucky :)
[14:42] <rly> I installed bzr-gtk, and then what?
[14:42] <rly> I had expected a bzr-gtk command in /usr/bin
[14:45] <rly> bzrk also does nothing.
[14:47] <rly> At no point does this page explain how to use it: http://wiki.bazaar.canonical.com/bzr-gtk?action=show&redirect=BzrGtk
[14:47] <rly> It lists a changelog which is at best a detail.
[14:52] <rly> I get it finally.
[18:41] <ianbrandt> Greetings.  I had a symlink in Bazaar that prevented Windows users from checking out the project per https://bugs.launchpad.net/bzr/+bug/81689.  I've removed the symlink, added a copy of the file in its place, and committed a new HEAD revision.  On Windows I still get the same error trying to branch the project.  Does this bug apply if there is a symlink anywhere in the history of the project?  I would have thought a checkout would
[18:41] <ianbrandt> if the latest revision contains no symlinks.
[19:14] <ianbrandt> abentley: Hello.  I noticed you started the wiki page on Windows symlink support (http://wiki.bazaar.canonical.com/WindowsSymlinkSupport).  Do you know if there is any workaround for getting "bzr: ERROR: Unable to create symlink 'foo' on this platform" on checkout even after the 'foo' symlink has been removed and replaced with a file in the latest commit?
[19:15] <abentley> ianbrandt: No, if the symlink was removed in the latest commit, I'm surprised that you can't do a checkout.
[19:17] <ianbrandt> abentley: Okay.  Me too.  This is with 2.5.1.  On my mac when I do revno I get 4102.  Same on Windows where the repository was checkout out, but the tree failed to populate.
[19:21] <ianbrandt> bzr ls -R --kind=symlink at the root of the project returns nothing on my mac.
[19:21] <ianbrandt> bzr revert -r 4102 on Windows results in "bzr: ERROR: No final name for trans_id 'new-1120' file-id: None root trans-id: 'new-0'"