RE: Killing bitkeeper history

I hope I haven't misunderstood what's trying to be achieved but here's
what we do with tar balls.

What we do is not attempt to do that at all. We create individual
repositories for each 3rdParty repo that we use. Let's take libpcap as
an example. We untar that into a directory as it comes out of the tin -
that creates a directory libpcap-0.9.1 (or whatever release we're using
at the time). We then setup a bk repo with that. Any local changes can
then be applied to that, committed and pushed (we don't have any - just
citing an example of what we do if we needed to). In our main repo, we'd
create a libs/pcap directory. And in that we use make to signal which
version of libpcap we're using by setting a make variable (in this case,
libpcap-0.9.1) and that then builds using the libpcap-0.9.1 source under
our libs/pcap directory.

Now, let's say we want to change version of libpcap to libpcap-0.9.2 (I
don't know whether that version exists and don't care - it's just an
example). We untar that tar ball, create a bk repo from that, apply any
local changes from our libpcap-0.9.1 repo (we have none so that's a
noop). We're still not using that though in the main project. To use it,
we change the makefile in libs/pcap to refer to the new libpcap. Even
then this change is isolated to the person who is trying to integrate
libpcap-0.9.2 - it's not until that's succeeded, committed and pushed
that everyone else on the project starts to use the new version on
libpcap.

The beauty of this approach is:

o 	older versions of our software can continue to use
	the old version of libpcap without being affected
	by what's being done in newer versions.
o 	different projects could pick and choose different=20
	versions of the third party software.
o 	the revision history of the makefile in libs/pcap=20
	captures the change of use of different versions
	of the third party software.
o 	our main repo is not bogged down with 3rd party
	software.

Obviously, I'm sweeping much of the implementation under the carpet.

If you don't want to do that, you could always have a repo that simply
logs the different versions of the tar balls you're using and then keep
the tar balls in some well known place and not revision controlled - ie
you're revision controlling the pointers rather than the tar balls
themselves. That would be a lot less cumbersome. You could probably have
a trigger that detars the relevant tar balls into the build hierarchy
automatically.

Hope that helps.

--=20
Andy, BlueArc Engineering
=20

> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Tristan Van Berkom
> Sent: 27 February 2006 23:22
> To: Brendan Heading
> Cc: bitkeeper users list
> Subject: Re: [Bitkeeper-users] Killing bitkeeper history
>=20
> Brendan Heading wrote:
> [...]
> > Respectfully, what's the point in using a revision control=20
> system if you=20
> > keep deleting all the history ?
> >=20
>=20
> Well, ideally we want to keep the history, its just that after
> stacking changeset upon changeset of modified tarballs makes the
> repo impossible to manage/use on a day-to-day basis.
>=20
> We ofcourse would still need to branch off versions of this
> repository for some projects and pull those results into an
> integration repository etc etc just like our other repositories
> (which are comrised of graphics skinsets, scripts and ofcourse the
> codebase).
>=20
> >>     - How can I conveniently pile changes from a stripped
> >>       repository onto the "backup repo" ?
> >=20
> > clone the repository and put it somewhere before doing=20
> csetprune, but to=20
> > me it seems like a waste of time.
>=20
> Hmmm, I was kind of hoping I could pile the new changesets onto an
> ever growing history of changesets; what you suggest would be like
> a single "undo" item where I would want a complete undo stack.
>=20
> All that aside; I agree that we may have used the wrong tool for that
> particular task... its what we used to do with CVS (and that was
> still a hassle for the same reasons)... if I can get away with not
> addressing that issue and finding a clunky but usable permenent
> solution; I'll be a happy man ;-D
>=20
> Cheers,
>                          -Tristan
>=20
> _______________________________________________
> Bitkeeper-users mailing list
> [email protected]
> http://mail.bitmover.com/mailman/listinfo/bitkeeper-users
>=20