'RE: [Bitkeeper-users] BitKeeper docs [was updating 3rd party...]'

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

List:       bitkeeper-users
Subject:    RE: [Bitkeeper-users] BitKeeper docs [was updating 3rd party...]
From:       "Staelin, Carl" <staelin () exch ! hpl ! hp ! com>
Date:       2003-11-18 8:19:47
[Download RAW message or body]

Larry,

As you know, I wanted the tracking stuff (which
you already pointed out).  I should also like to
know how to:
	- 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
	- 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?
	- 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?
	- 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.

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.

Cheers,

Carl

_________________________________________________
[(hp)]	Carl Staelin
	Senior Research Scientist
	Hewlett-Packard Laboratories
	Technion City
	Haifa, 32000
	ISRAEL
	+972(4)823-1237x305	+972(4)822-0407 fax
	staelin@hpl.hp.com
_______http://www.hpl.hp.com/personal/Carl_Staelin_______

> -----Original Message-----
> From: bitkeeper-users-admin@bitmover.com
> [mailto:bitkeeper-users-admin@bitmover.com]On Behalf Of Larry McVoy
> Sent: Monday, November 17, 2003 5:36 PM
> To: Dale Hagglund
> Cc: Larry McVoy; Greg Lonnon; bitkeeper-users@bitmover.com
> Subject: [Bitkeeper-users] BitKeeper docs [was updating 3rd party...]
> 
> 
> On Sun, Nov 16, 2003 at 12:36:07AM -0700, Dale Hagglund wrote:
> > Larry McVoy <lm@bitmover.com> writes:
> > 
> > > Does http://www.bitkeeper.com/tracking.ps help at all?
> > 
> > Not that I have the problem in question, but I found it a very
> > interesting read.  To me, it's an example of a category of 
> "cookbook"
> > or "howto" or "best practices" docs that I've been unable 
> to find for
> > bitkeeper.  (Perhaps I've just failed to look in the right places.)
> 
> We've been too busy evolving the product to write docs, unfortunately.
> We are looking to rectify that, we could hire a full time docs person
> but I'm reluctant to do that, I prefer to have engineers write docs 
> (I wrote that tracking paper, for example).
> 
> Let's try an experiment.   Let's toss around ideas for a list 
> of useful
> cookbook items.  I can seed that list but I'd prefer not to, I'm too 
> likely to drive the list towards stuff I think should be 
> documented and
> what I want is the list of things you think should be 
> documented.  I can
> always fill in what's missing.  
> 
> Once we have a list, let's try and sort it in order of 
> usefulness and then
> we'll find a tech writer and see what they can do.  If we can 
> get useful
> docs taht way and use up less engineering time, we have the 
> money for it
> so we should do it.
> 
> So think back to before BK and try and remember the things 
> that you needed
> to understand to use it well.  What are the problems you 
> needed to solve
> using BK?  Post 'em.  If this approach doesn't work after a 
> few days I'll
> post what I think is a good list and we can discuss it.
> -- 
> ---
> Larry McVoy              lm at bitmover.com          
> http://www.bitmover.com/lm
> _______________________________________________
> 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.
> 

_______________________________________________
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] 