Re: [Gnu-arch-users] conversion of bitkeeper archive to tla

[Zenaan Harkness]

On Sat, 2004-08-21 at 12:46, John Meinel wrote:
> This isn't nearly as bad with smaller projects.

Well, we're at about 350 files, and only growing slowly, and the windows
(laptop) is a 1.4GHz Pentium M.

Sounds like cygwin might be acceptable.

BTW, thanks for the numbers.

> If I had to pick one, I would say Samba share will give you the best
> performance. But my Linux box is over a 11MB wireless link through
> several walls, so I haven't tried it. For me, building would take too
> long on the share.

I don't like centralized servers either - been there with a team of 30
and the server goes down. The company stops for a day (or until the
admins get it going again - I think it was a bit over half a day from
memory - failed disk or something).

And a big part of arch is decentralized development.

> Currently there aren't any bitkeeper -> arch conversion scripts.

Well, I just found bitkeeper 'export':

---
The  export  command generates a directory tree alongside the BitKeeper
repository which contains checked-out copies of  all  the  files  under
BitKeeper  control.   It  can  also  generate  traditional  (diff -Nur)
patches between any two revisions of the source tree.  By  default,  bk
export  only  exports  user files.  Files under the BitKeeper directory
are not exported.  This behavior can be changed  with  the  -i  and  -x
options.

If  you  are trying the export a patch for a sub-directory, and some of
the files in that directory have been moved out of the  directory.  You
want to make sure the out-of-view file looks like deleted file. This is
done by replacing the |rev part of the out-of-view file to  |1.0.   You
can do this using the following command:
    bk rset -hrA,B | your_script | bk gnupatch
---

Looks like that should be satisfactory.

> A simple thing that was mentioned, though. Just get each version of the
> bk archive, and the check that into the arch one. I don't know bk well,
> but I'm guessing you could just cut and paste the log. With only 20
> changesets, I don't think it would be a lot of work.

Thanks
Zen