[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitkeeper-users
Subject:    Re: [Bitkeeper-users] BitKeeper docs
From:       Wayne Scott <wscott () bitmover ! com>
Date:       2003-11-18 13:12:12
[Download RAW message or body]


Ahh.  I couple questions that are easy to answer.



From: "Staelin, Carl" <staelin@exch.hpl.hp.com>
> 	- see the list of tags
> 		- e.g. I want to create a repository
> 		  that is linux-2.6 as of version
> 		  2.6.0-test9, but I don't know what
> 		  changeset has that tag, so I want
> 		  to list the tags and their changesets
> 		  so I can 'bk clone -rX.XX' properly

'bk tags' aka 'bk changes -t' will do this.

> 	- pull a single changeset plus any dependencies
> 	  it has from another repository
> 		- e.g., I have a working tree, call it
> 		  linux-2.6-chs, where I have been
> 		  working and debugging and I have
> 		  fallen behind with 'bk pull', and I 
> 		  have heard that there is a new patch 
> 		  in the mainline tree that fixes a 
> 		  particular bug.  I want to pull in 
> 		  only that changeset and possibly those
> 		  changesets that that patch depend
> 		  upon.  How do I do it?

You want 'bk pull -rREV', which we haven't implemented yet. ;-)
We have the option reserved..

In the meanwhile you do this workaround:
   bk clone -lrREV linux-2.6-chs  tmprepo
   cd myrepo
   bk pull ../tmprepo
   rm -rf ../tmprepo

> 	- Is there some way to do the equivalent to
> 	  'bk pull -rX.XX' (e.g. pull from parent upto
> 	  changeset X.XX?), and similarly for 
> 	  'bk push -rX.XX'.  I don't remember seeing it
> 	  in the docs.

same as previous questions.  Answer: not yet.  But we are seeing a
theme here, so it increases the odds considerably.

> 	- I am tracking a third party project to
> 	  which I occassionally contribute.  I have
> 	  three trees:
> 		- track-external	-- the third-party
> 					   source tree
> 		- track-master	-- what I use as the
> 					   master source tree
> 		- track-chs		-- where I do my development
> 	  Now, I use track-external to checkin changes
> 	  in the third party sources, and I then push
> 	  those changes to track-master.  I do my
> 	  development in track-chs and push/pull changes
> 	  to/from the master tree.
> 
> 	  Occassionally some of my changes are accepted
> 	  by the third party, e.g. new files or patches
> 	  to existing files, but the changes are merged
> 	  in with lots of other changes done by others.
> 	  The third party sources are only released as
> 	  tarballs every so often, and no change history
> 	  is available.
> 	
> 	  Is there some easy way to handle the merging
> 	  so I can have some rational change history in
> 	  the master repository?

Just the description of what you are doing would be a useful FAQ.
Cort did this for years with the PPC linux tree before linux
converted.  For the most part it works pretty well.  You just have the
cases where you have a bitkeeper cset merging with an external patch
that contains the same changes.  Since the entire development is not
using BitKeeper consistantly you lose a lot of the tracking that
BitKeeper does for you.  When the patch is editing a file, it usually
works out OK because the bk merge tools will notice duplicate changes
and do the right thing.  The real problem is when you create a new
file in track-chs and then that file gets created seperately when you
patch is imported.  BitKeeper will forever consider those two files to
be different and they can't occupy the same location.  That means that
when you get a file conflict in track-master you need to resolve the
conflicted by renaming the file created in track-chs and moving your
other local changes to the file created in the patch.  If you create a
lot of files this can be a royal pain and is not automated.

> One suggestion, why not setup a wiki for a BK
> combination HOWTO/FAQ where people can add their
> tips/tricks/use-models/etc.?  If you had a 
> 'how do I do ...?' section where people could
> add questions in the FAQ, then either BitMover
> people or other users could hopefully add the
> answers.  This would make the process less of a
> one-shot deal and more of a process.

A good idea and we have considered it and haven't ruled out the
possibility.  There is a good community of BK users that have a lot to
contribute and we would be better able to gage where people are most
interested in changes.

-Wayne

_______________________________________________
Bitkeeper-users mailing list
Bitkeeper-users@bitmover.com
http://bitmover.com/mailman/listinfo/bitkeeper-users
To unsubscribe from this list, go to the above URL, follow instruction at the bottom of the web page.
[prev in list] [next in list] [prev in thread] [next in thread]