How to Import a bitkeeper repo into git

How to Import a bitkeeper repo into git

[free cycle]

Hi,

I'm looking for the best path to import a bk repo into git.


I was not able to find the download site for the tailor repo-conversion application.
Is it still supported and maintained?

I think bk can export to CVS and then git can import from CVS.
Is this the best way?

Thanks in advance,

Scott

Re: How to Import a bitkeeper repo into git

[VMiklos]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Na Mon, Jul 09, 2007 at 09:57:09AM -0700, free cycle <freecycler23@yahoo.com> pisal(a):
> I was not able to find the download site for the tailor repo-conversion application.
> Is it still supported and maintained?

http://progetti.arstecnica.it/tailor/

yes, it's maintained but it does not support bitkeeper

> I think bk can export to CVS and then git can import from CVS.

i think so

- VMiklos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: How to Import a bitkeeper repo into git

[Linus Torvalds]

On Mon, 9 Jul 2007, VMiklos wrote:
> 
> > I think bk can export to CVS and then git can import from CVS.
> 
> i think so

That's how I did my kernel history, and cvsps has a special "BK mode", 
which knows to trust the CVS timestamps more when importing from a BK CVS 
archive (since the timestamps will then be exact).

That said, the quality of the result isn't stellar. The CVS export will 
obviously linearize the BK information, so you do lose things. So there's 
actually a better kernel BK->git archive around which doesn't do that, but 
that was done apparently from a custom database, so it's not reproducible.

			Linus

Re: How to Import a bitkeeper repo into git

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:
> 
> On Mon, 9 Jul 2007, VMiklos wrote:
>>> I think bk can export to CVS and then git can import from CVS.
>> i think so
> 
> That's how I did my kernel history, and cvsps has a special "BK mode", 
> which knows to trust the CVS timestamps more when importing from a BK CVS 
> archive (since the timestamps will then be exact).
> 
> That said, the quality of the result isn't stellar. The CVS export will 
> obviously linearize the BK information, so you do lose things. So there's 
> actually a better kernel BK->git archive around which doesn't do that, but 
> that was done apparently from a custom database, so it's not reproducible.
> 
> 			Linus
> -

We have a CVS repository that we want to import into bitkeeper. I tried
the bk import option, including with a branch bug fix, but it's
still having problems.

I imported the CVS repository to git and it worked great. Since all
of our other repository are in bitkeeper the management would like to
stick with CVS. With git apparently still being weak in the area of
supporting difftool on different version that seems somewhat reasonable
for the time being.

The folks at bitmover are converting you kernels to bk and it's
maintaining the branch history and I'd like to do the same. So far
they haven't help us convert the git repository to bk. Do you happen
to know of someone else that might now how to do this in case the
folks at bitmover can't provide the scripts to convert this git
repository to bk?

I was curious why the difftool paradigm hasn't been integrated into
the git GUIs. It's very comfortable and I think it has been used in
other source code control systems, for example Sun Microsystems.

- -piet

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHE/pKJICwm/rv3hoRAs/QAJoDL0HQDaOAI1x6UakEiVvti9tI2wCfUpGI
bfyKH+ykUK7p2AL9CSE+XXc=
=0gnp
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git

[Shawn O. Pearce]

Pete/Piet Delaney <pete@bluelane.com> wrote:
> I imported the CVS repository to git and it worked great. Since all
> of our other repository are in bitkeeper the management would like to
> stick with CVS. With git apparently still being weak in the area of
> supporting difftool on different version that seems somewhat reasonable
> for the time being.
...
> I was curious why the difftool paradigm hasn't been integrated into
> the git GUIs. It's very comfortable and I think it has been used in
> other source code control systems, for example Sun Microsystems.

What's difftool?  What's so great about it?

Forgive my ignorance but it has been many years since I last used
BitKeeper and even when I did use it I didn't get into many of the
features it offered.  Its entirely possible I never learned about
difftool.

I've never found that I cannot get the information I need out of Git
when I need it.  Actually I've found it to be the easiest VCS to get
data out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.
Of course I also know Git better than I know those tools...

-- 
Shawn.

Re: How to Import a bitkeeper repo into git

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shawn O. Pearce wrote:
> Pete/Piet Delaney <pete@bluelane.com> wrote:
>> I imported the CVS repository to git and it worked great. Since all
>> of our other repository are in bitkeeper the management would like to
>> stick with CVS. With git apparently still being weak in the area of
>> supporting difftool on different version that seems somewhat reasonable
>> for the time being.
> ...
>> I was curious why the difftool paradigm hasn't been integrated into
>> the git GUIs. It's very comfortable and I think it has been used in
>> other source code control systems, for example Sun Microsystems.
> 
> What's difftool?  What's so great about it?

It's a side by side graphical diff. So instead of showing the difference
like diff does it takes the output from diff and shows the originals
with the diffs highlighted.

tkdiff is a good example that's easy to down load and see. So
just imagine allowing git-gui to run tkdiff of revisions you select
with the mouse.


> 
> Forgive my ignorance but it has been many years since I last used
> BitKeeper and even when I did use it I didn't get into many of the
> features it offered.  Its entirely possible I never learned about
> difftool.

Try downloading tkdiff. There also a X implementation,
I think it's xdiff.

> 
> I've never found that I cannot get the information I need out of Git
> when I need it.  Actually I've found it to be the easiest VCS to get
> data out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.
> Of course I also know Git better than I know those tools...

Try tkdiff and then tell me you don't find it easier to read that
the straight output from diff.

- -piet

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFAi4JICwm/rv3hoRAluCAJ9jFrA9G8aKQi1rtM2CSiNnmhlo4wCeJjk7
LONAM+lzvin021HAhQ8jKoE=
=QsE/
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git

[Linus Torvalds]

On Mon, 15 Oct 2007, Pete/Piet Delaney wrote:
> 
> I imported the CVS repository to git and it worked great. Since all
> of our other repository are in bitkeeper the management would like to
> stick with CVS. With git apparently still being weak in the area of
> supporting difftool on different version that seems somewhat reasonable
> for the time being.

I can't see how bk's difftool could possibly have any relevance to the 
"reasonable to stick with CVS" decision, but hey, I'm always surprised by 
peoples inventiveness in rationalizing their decisions ;)

I don't know what difftool does that a simple

	git diff -U99 | viewdiff -

wouldn't do, but in all honesty, I don't think I ever used difftool (I 
found the other tools in bk much more useful - eg mergetool, renametool)

I don't actually know of any sane programs to view unified diffs, but you 
can script one with little trouble. Here's a really hacky one I just came 
up with:

	#!/bin/sh
	cat "$@" > /tmp/diff
	grep '^[ -]' /tmp/diff > /tmp/orig
	grep '^[ +]' /tmp/diff > /tmp/result
	meld /tmp/orig /tmp/result

which fools 'meld' into showing a unified diff in a nice graphical manner.

[ Quite frankly, I don't understand why tools like meld and kdiff3 can't 
  just take the unified diff directly - they have *all* the logic, it 
  should be trivial to do, and very useful to view diffs for those people 
  who like that graphical bling. ]

> The folks at bitmover are converting you kernels to bk and it's
> maintaining the branch history and I'd like to do the same. So far
> they haven't help us convert the git repository to bk. Do you happen
> to know of someone else that might now how to do this in case the
> folks at bitmover can't provide the scripts to convert this git
> repository to bk?

Hmm. Converting from git to bk should not be that hard at least 
conceptually, but no, I have no idea how to script it sanely and 
efficiently. The obvious solutions all would want to have multiple active 
heads of development open at the same time (Larry calls them "LOD's" not 
branches), and would also require some way to set the result of a merge. 
Neither of which I would know how to do in BK (I created a lot of merges 
in BK, but I always let BK do the merging - I wouldn't know how to specify 
the merge result by hand).

		Linus

Re: How to Import a bitkeeper repo into git

[David Brown]

On Mon, Oct 15, 2007 at 05:45:44PM -0700, Linus Torvalds wrote:

>	git diff -U99 | viewdiff -

Do you have reference for viewdiff.  I can't seem to locate it.

>[ Quite frankly, I don't understand why tools like meld and kdiff3 can't 
>  just take the unified diff directly - they have *all* the logic, it 
>  should be trivial to do, and very useful to view diffs for those people 
>  who like that graphical bling. ]

kompare can read the unified diffs.  If you add enough context, the result
is no different than the full files.

David

Re: How to Import a bitkeeper repo into git

[David Brown]

On Mon, Oct 15, 2007 at 05:41:28PM -0700, Pete/Piet Delaney wrote:

>Try tkdiff and then tell me you don't find it easier to read that
>the straight output from diff.

Both.  Most of the time, I find the diff output easier to read.  Only when
a change modifies a whole bunch of lines sprinkled around do I find the
side-by-side format easier.  Even then, it is only marginal.

However, asking for a side-by-side diff viewer is probably the most common
request I've gotten from people I work with starting to use git.

David

Re: How to Import a bitkeeper repo into git

[Linus Torvalds]

On Mon, 15 Oct 2007, David Brown wrote:
>
> On Mon, Oct 15, 2007 at 05:45:44PM -0700, Linus Torvalds wrote:
> 
> > 	git diff -U99 | viewdiff -
> 
> Do you have reference for viewdiff.  I can't seem to locate it.

That was the stupid script I just posted ;)

> > [ Quite frankly, I don't understand why tools like meld and kdiff3 can't
> > just take the unified diff directly - they have *all* the logic, it  should
> > be trivial to do, and very useful to view diffs for those people  who like
> > that graphical bling. ]
> 
> kompare can read the unified diffs.  If you add enough context, the result
> is no different than the full files.

Ahh, good pointer. I had to google for it to find that it's part of the 
kdesdk package, which I hadn't installed. But a simple "yum install 
kdesdk" worked fine.

Much better than my stupid script ;)

		Linus

Re: How to Import a bitkeeper repo into git

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:
> 
> On Mon, 15 Oct 2007, Pete/Piet Delaney wrote:
>> I imported the CVS repository to git and it worked great. Since all
>> of our other repository are in bitkeeper the management would like to
>> stick with CVS. With git apparently still being weak in the area of
>> supporting difftool on different version that seems somewhat reasonable
>> for the time being.
> 
> I can't see how bk's difftool could possibly have any relevance to the 
> "reasonable to stick with CVS" decision, but hey, I'm always surprised by 
> peoples inventiveness in rationalizing their decisions ;)
> 
> I don't know what difftool does that a simple
> 
> 	git diff -U99 | viewdiff -

Sigh, no help for git diff.

> 
> wouldn't do, but in all honesty, I don't think I ever used difftool (I 
> found the other tools in bk much more useful - eg mergetool, renametool)

Wondering if adding a file dimension to gitk might help and adding the
ability to diff different version of a file git gitk by doing something
like holding down the shift key and/or adding a new view pull down.


> 
> I don't actually know of any sane programs to view unified diffs, but you 
> can script one with little trouble. Here's a really hacky one I just came 
> up with:
> 
> 	#!/bin/sh
> 	cat "$@" > /tmp/diff
> 	grep '^[ -]' /tmp/diff > /tmp/orig
> 	grep '^[ +]' /tmp/diff > /tmp/result
> 	meld /tmp/orig /tmp/result
> 
> which fools 'meld' into showing a unified diff in a nice graphical manner.

I just download 'meld', looks interesting, I didn't know about it or
'kompare'. Linking either one into gitk would be a pleasant graphical
'bling'.

> 
> [ Quite frankly, I don't understand why tools like meld and kdiff3 can't 
>   just take the unified diff directly - they have *all* the logic, it 
>   should be trivial to do, and very useful to view diffs for those people 
>   who like that graphical bling. ]
> 
>> The folks at bitmover are converting you kernels to bk and it's
>> maintaining the branch history and I'd like to do the same. So far
>> they haven't help us convert the git repository to bk. Do you happen
>> to know of someone else that might now how to do this in case the
>> folks at bitmover can't provide the scripts to convert this git
>> repository to bk?
> 
> Hmm. Converting from git to bk should not be that hard at least 
> conceptually, but no, I have no idea how to script it sanely and 
> efficiently. The obvious solutions all would want to have multiple active 
> heads of development open at the same time (Larry calls them "LOD's" not 
> branches), and would also require some way to set the result of a merge. 
> Neither of which I would know how to do in BK (I created a lot of merges 
> in BK, but I always let BK do the merging - I wouldn't know how to specify 
> the merge result by hand).

Hmm, actually I'm only seeing rev topology up to 2.6.13,
later version seem to be linear and when I try to use a larger
time window something seems to crashing, the gui goes away,
and 'bk revtool' returns. Sigh.

I'll try keeping it real simple and just import our release branch
and hope for the best. Hopefully Johnannes, or perhaps folks more
involved with gitk can add a bit more graphical bling soon to the
cheetah release. BTW, is this the right mailing list for discussing
gitk as well as git?

- -piet

> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFDPyJICwm/rv3hoRAsU0AJ9o6rHtu5rkiUeNlheRNUpwd4bfagCdHEK8
hDeVvRCyD8Xf8INbdMpuDDU=
=XB2c
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git

[Marco Costalba]

On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> I just download 'meld', looks interesting, I didn't know about it or
> 'kompare'. Linking either one into gitk would be a pleasant graphical
> 'bling'.
>

In case you are interested a git GUI viewer called qgit can spawn
'Kompare' , 'Meld' or any other diff tool that support 'two files'
command line interface:

$my_preferred_diff_tool  file1.txt file2.txt

And they will show what you are looking for. The input files are
prepared by qgit that also handles the housekeeping at the end.

Another feature you asked, i.e. CTRL + right click to select a
revision (different from the parent) to diff against the current one
is also already implemented.

And of course the two above features can be integrated: you select two
random revisions and then call the external diff viewer to check at
the differences in the way you prefer.

It is possible to download qgit from

http://sourceforge.net/project/showfiles.php?group_id=139897


Two versions:

qgit-1.5.7 is Qt3 based

qgit-2.0 is Qt4 based (works also under Windows)



regards
Marco

Re: How to Import a bitkeeper repo into git

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Costalba wrote:

Hi Marco:

> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> I just download 'meld', looks interesting, I didn't know about it or
>> 'kompare'. Linking either one into gitk would be a pleasant graphical
>> 'bling'.
>>
> 
> In case you are interested a git GUI viewer called qgit can spawn
> 'Kompare' , 'Meld' or any other diff tool that support 'two files'
> command line interface:
> 
> $my_preferred_diff_tool  file1.txt file2.txt
> 
> And they will show what you are looking for. The input files are
> prepared by qgit that also handles the housekeeping at the end.

Great, I installed Qgit version 1.5.3 a while ago, I didn't
notice these advantages over gitq.

Yea, I just noticed, if I pull down External Diff in the files
window it tosses the diffs to Kompare. Super!


> Another feature you asked, i.e. CTRL + right click to select a
> revision (different from the parent) to diff against the current one
> is also already implemented.

It's not quite a intuitive/familiar as with bitkeeper. I suspect I just
need some practice. I selected a huge list if files that we use to
filter the release with and double clicked on the file I thought showing
to focus on that file. The I pulled down External Diff and it took for
ever; like it's confused.

Often we/I want to see the rev history for a particular file.
How would you do that with Qgit?

> 
> And of course the two above features can be integrated: you select two
> random revisions and then call the external diff viewer to check at
> the differences in the way you prefer.

Can I see just the revs for a particular file?

> 
> It is possible to download qgit from
> 
> http://sourceforge.net/project/showfiles.php?group_id=139897

I'll get the latest and greatest. Thinks. Often the problem is
having the current version of Qt3. My workstation is Mandrake
1005 Limited Edition (X11 Xinerama works on this release).
Looks like I have Qt3 on my workstation. Would it be worthwhile
to install Qt4 from src and try to use qgit-2.0?


> 
> Two versions:
> 
> qgit-1.5.7 is Qt3 based
> 
> qgit-2.0 is Qt4 based (works also under Windows)

What new features are in 2.0 over 1.5.7?

Thanks Marco,

- -piet

> 
> 
> 
> regards
> Marco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFFS0JICwm/rv3hoRAlFIAJsEbp22Fs1fGVlt+RIXOOjJ3ZiqIQCeIQ1/
nG/JJUfuNNyoIL2MUJppId4=
=JQWE
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git

[Marco Costalba]

On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> It's not quite a intuitive/familiar as with bitkeeper. I suspect I just
> need some practice. I selected a huge list if files that we use to
> filter the release with and double clicked on the file I thought showing
> to focus on that file. The I pulled down External Diff and it took for
> ever; like it's confused.
>

You shoudl select only _one_ additional revision.

The currenlty selected revision is the base + select another one
(only) with CTRL + *RIGHT* click (the file list change background
color) , then call external diff tool.

> Often we/I want to see the rev history for a particular file.
> How would you do that with Qgit?
>

Select the file from the file list (right bottom pane) or from the
tree view (use key 't' to toggle treev view) double click on it or use
context menu (right click on the file name) and that's all.

>
> Can I see just the revs for a particular file?
>

See above.


I know I'm going to tell you a very _unpopular_ thing, but, in case
you have 5 minutes of spare time (yes, it doesn't take longer), open
qgit then please press a nice key called 'F1', a nice handbook will
appear...

I really suggest to look at it. To keep UI 'clean' a lot of features
are not immediatly visible, so reading the handbook (at least the
chapter's titiles) would give you a better idea of what qgit could do
for you.

>
> I'll get the latest and greatest. Thinks. Often the problem is
> having the current version of Qt3. My workstation is Mandrake
> 1005 Limited Edition (X11 Xinerama works on this release).
> Looks like I have Qt3 on my workstation. Would it be worthwhile
> to install Qt4 from src and try to use qgit-2.0?
>

Yes it is. There are a lot of new featrures, is almost as stable as
the previous and if you are interested in file history (annotations)
in qgit-2.0 this feature has been greatly speeded up.


Have fun
Marco

Re: How to Import a bitkeeper repo into git

[Andreas Ericsson]

Marco Costalba wrote:
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
> 
>> Would it be worthwhile
>> to install Qt4 from src and try to use qgit-2.0?
>>
> 
> Yes it is. There are a lot of new featrures, is almost as stable as
> the previous and if you are interested in file history (annotations)
> in qgit-2.0 this feature has been greatly speeded up.
> 

The only thing I really, really, really don't like about qgit4 is the
fact that it fudges up the commit-message. I've been trying for two
days to get rid of the HTML output, but I just can't get it done
without the signed-off-by email being enclosed in &lt;&gt; tags.

Marco, is there any chance you could make the old commit-message view
an option? Especially, the subject line should really, really be at the
bottom, with the rest of the message-text (although I liked the other
view without the colored box a lot more). The little arrows in the
commit window are also fairly annoying, as one quite quickly understands
that up-/down-arrows work much better for that sort of stuff anyway.

I'm at my wits end wrt c++ and qt, and can't for the life of me think of
how to make it an option :(

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: How to Import a bitkeeper repo into git

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On Mon, Oct 15, 2007 at 17:45:44 -0700, Linus Torvalds wrote:
> I don't actually know of any sane programs to view unified diffs, but you 
> can script one with little trouble. Here's a really hacky one I just came 
> up with:
> 
> 	#!/bin/sh
> 	cat "$@" > /tmp/diff
> 	grep '^[ -]' /tmp/diff > /tmp/orig
> 	grep '^[ +]' /tmp/diff > /tmp/result
> 	meld /tmp/orig /tmp/result
> 
> which fools 'meld' into showing a unified diff in a nice graphical manner.
> 
> [ Quite frankly, I don't understand why tools like meld and kdiff3 can't 
>   just take the unified diff directly - they have *all* the logic, it 
>   should be trivial to do, and very useful to view diffs for those people 
>   who like that graphical bling. ]

Kompare (KDE analog of meld) can. It is even bound to text/x-diff in
konqueror, so opening patches with konqueror yields side-by-side diff view.
On the other hand it still keeps a unixy behaviour:
 git diff | kompare -
works.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to Import a bitkeeper repo into git

[Linus Torvalds]

On Tue, 16 Oct 2007, Jan Hudec wrote:
> 
> Kompare (KDE analog of meld) can. It is even bound to text/x-diff in
> konqueror, so opening patches with konqueror yields side-by-side diff view.
> On the other hand it still keeps a unixy behaviour:
>  git diff | kompare -
> works.

Side note: I think kompare is beautiful, but kompare does one thing 
totally wrong: it seems to think that you only want to look at the diff 
fragments one file at a time.

That's totally bogus. My trivial four-liner shell script does this better 
than kompare does - as does "gitk" in the diff view window.

The fact is, quite often you have diffs that are lots of small changes to 
tons of files, and the kompare interface is totally ludicrous and useless. 
It would be *much* nicer to literally show them as one long flowing diff.

And yes, it will depend on circumstances, but I can't seem to even find 
the config option to not do that. As a result, you have to click through 
all the files manually (even the "Next file" thing is grayed out when I do 
the "git diff | kompare -", so I can't even use the keyboard shortcut to 
go to the next file).

So I have to say, after playing with it, my shell-script "viewdiff" is 
actually infinitely better than "kompare -" is, at least for my workflow.

		Linus

Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Costalba wrote:

Hi Marco:

I've gone back and tried my old Qgit 1.5.3 and it was
much closer in functionality to Bitkeeper.

> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> I just download 'meld', looks interesting, I didn't know about it or
>> 'kompare'. Linking either one into gitk would be a pleasant graphical
>> 'bling'.
>>
> 
> In case you are interested a git GUI viewer called qgit can spawn
> 'Kompare' , 'Meld' or any other diff tool that support 'two files'
> command line interface:
> 
> $my_preferred_diff_tool  file1.txt file2.txt
> 
> And they will show what you are looking for. The input files are
> prepared by qgit that also handles the housekeeping at the end.

While I'm looking at the diffs for a file if I pull down External Diff
it launches 'kcompare' but for a file with a large change it seems
to be running extremely slow. We have a file with 13,000 files in it
and I have two changes in the file, each is an addition and deletion
of about 100 lines in one contiguous block. If I click between them
it's fine but since the 100 lines is more than one page I try to
scroll thru the diff. At this point of time 'kompare' seems to be
using 95% of the CPU time and it takes about 10 seconds for it to
scroll. It scrolls fine in the qgit diff window. It;s not a problem
for small files. Know of what can me done so that 'kcompare' works
fast on large files; something like pointing it's tmp files to a
not NFS partition.


Another problem I've noticed is that sometime while running git
it seems to spend a large amount of time  switching from one
change-set to the next; seems to be due to all of the tagged
files.

> Another feature you asked, i.e. CTRL + right click to select a
> revision (different from the parent) to diff against the current one
> is also already implemented.

It seems that while I'm in "Rev List" mode I can select the the
two versions to compare a selected file with View->External diff...

Now, if I pull down "View File" or go to the file context were
you see the change-set for a file then I can't get the CTRL + right
click to allow me to diff two revisions of the file.

While messing around in this area of trying to diff two revision
of the file from the file context I got:
- ------------------------------------------------------------------
/nethome/piet/src/blux$ qgit
Saving cache. Please wait...
Compressing data...
Done.
Saving cache. Please wait...
Compressing data...
Done.
ASSERT in getAncestor: empty file from
e86306878efb575be80d070ac3dec49f8d358cd1
ASSERT in lookupAnnotation: no annotation for cli/quagga-0.96/lib/bluelane.c
ASSERT in remove: 8 is not the first in list
Thrown exception 'Canceling annotation'
Exception 'Canceling annotation' not handled in init...re-throw
terminate called after throwing an instance of 'i'
Aborted
/nethome/piet/src/blux$
- ------------------------------------------------------------------

MY guess is that I should install a newer version of qgit,
I'm using 1.5.3.

How difficult is it to upgrade to the Qt4. Can I just
install it to /usr/local and not interfere with Qt3?
Last I recall messing with installing ethereal from src
I needed a graphics lib and as I recall installing it in
/usr/local/ confused some build crap. It would be interesting
to try out your new qgit-2.0.

> 
> And of course the two above features can be integrated: you select two
> random revisions and then call the external diff viewer to check at
> the differences in the way you prefer.

Right, but how do I do this from the file context?

> 
> It is possible to download qgit from
> 
> http://sourceforge.net/project/showfiles.php?group_id=139897
> 
> 
> Two versions:
> 
> qgit-1.5.7 is Qt3 based
> 
> qgit-2.0 is Qt4 based (works also under Windows)

Picked up both, I'll start with qgit-1.5.7.

Installing qt4 might not be so easy; looking at:

	http://packages.qa.debian.org/q/qt4-x11.html

it seems to be pretty big. The date on 1.5.7 was very
close to 2.0 so I thought they might be very close in
functionality and you maintaining the same code for
both the common Qt3 and the new Qt4 to make it easy
for users to install.

Regards,
Piet

> 
> 
> 
> regards
> Marco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFZd4JICwm/rv3hoRAgMVAJ0d49Sbbuppt8o5F1U7tbkaQjSQzwCfV0nn
mnFXyUWIKGhoxz7pqulJeVk=
=Jq+Y
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Costalba wrote:
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> It's not quite a intuitive/familiar as with bitkeeper. I suspect I just
>> need some practice. I selected a huge list if files that we use to
>> filter the release with and double clicked on the file I thought showing
>> to focus on that file. The I pulled down External Diff and it took for
>> ever; like it's confused.
>>
> 
> You shoudl select only _one_ additional revision.
> 
> The currenlty selected revision is the base + select another one
> (only) with CTRL + *RIGHT* click (the file list change background
> color) , then call external diff tool.
> 
>> Often we/I want to see the rev history for a particular file.
>> How would you do that with Qgit?
>>
> 
> Select the file from the file list (right bottom pane) or from the
> tree view (use key 't' to toggle treev view) double click on it or use
> context menu (right click on the file name) and that's all.

't' worked fine but still can see how to diff do of the list of
changes for a file. Viewing diffs of files based on change sets
worked fine but I think with BitKeeper I found it helpful to be
able to do a full 'kompare' type diff the file only; often I'm
not interested in which change set it went into.

Something for a future version or am I lucky and you have
it covered already?

> 
>> Can I see just the revs for a particular file?
>>
> 
> See above.
> 
> 
> I know I'm going to tell you a very _unpopular_ thing, but, in case
> you have 5 minutes of spare time (yes, it doesn't take longer), open
> qgit then please press a nice key called 'F1', a nice handbook will
> appear...

Good Idea, thought it's brought up a few questions:

	1. When I do the <control-minis> to Decrease the font size
	   I can't undo it with the <control-plus>. Also <control-plus>
	   doesn't seem to do anything.

	2. When displaying the "Lane info" why can't I see the
           branch names?

>
> I really suggest to look at it. To keep UI 'clean' a lot of features
> are not immediatly visible, so reading the handbook (at least the
> chapter's titiles) would give you a better idea of what qgit could do
> for you.

I'll read it a few more times. I seem to sometimes get into a state
where I'm locked onto the current change set and can't get back to
the other change sets without starting another qgit.

> 
>> I'll get the latest and greatest. Thinks. Often the problem is
>> having the current version of Qt3. My workstation is Mandrake
>> 1005 Limited Edition (X11 Xinerama works on this release).
>> Looks like I have Qt3 on my workstation. Would it be worthwhile
>> to install Qt4 from src and try to use qgit-2.0?
>>
> 
> Yes it is. There are a lot of new featrures, is almost as stable as
> the previous and if you are interested in file history (annotations)
> in qgit-2.0 this feature has been greatly speeded up.

Do you know if it's a lot of work to install Qt4?

- -piet

> 
> 
> Have fun
> Marco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFZv5JICwm/rv3hoRAky6AJ47DFL/pWa8CCHv0ezw0wdkLLmbIQCeJqZN
cNHuMINv2/7fmnwczWcowhs=
=VSZN
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git

[Marco Costalba]

On 10/16/07, Andreas Ericsson <ae@op5.se> wrote:
> Marco Costalba wrote:
> > On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
> >
> >> Would it be worthwhile
> >> to install Qt4 from src and try to use qgit-2.0?
> >>
> >
> > Yes it is. There are a lot of new featrures, is almost as stable as
> > the previous and if you are interested in file history (annotations)
> > in qgit-2.0 this feature has been greatly speeded up.
> >
>
> The only thing I really, really, really don't like about qgit4 is the
> fact that it fudges up the commit-message. I've been trying for two
> days to get rid of the HTML output, but I just can't get it done
> without the signed-off-by email being enclosed in &lt;&gt; tags.
>

You mean when you commit some changes or when you brows the revisions?

If it is the highlighted title that annoy you I can try to remove the
background color, or set as plain text as an option.

> view without the colored box a lot more). The little arrows in the
> commit window are also fairly annoying, as one quite quickly understands
> that up-/down-arrows work much better for that sort of stuff anyway.
>

Little arrows should already be removable from settings->browse->'Show
smart labels' , you can also add lateral tabs with
settings->browse->'Show tabbed revisions' if you like.


Marco

Re: How to Import a bitkeeper repo into git

[Marco Costalba]

On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> 't' worked fine but still can see how to diff do of the list of
> changes for a file. Viewing diffs of files based on change sets
> worked fine but I think with BitKeeper I found it helpful to be
> able to do a full 'kompare' type diff the file only; often I'm
> not interested in which change set it went into.
>

Well, open tree view ('t'), select the file you are interested of,
then click the magic wand button on the tool bar, now revisions you
see are filtered by that file, if you browse the revisions the
patch/diff you see will always point to your file (also if you can see
the whole patch).

> Something for a future version or am I lucky and you have
> it covered already?
>

Don't know, depends on how you answer to the above point ;-)

>
> Good Idea, thought it's brought up a few questions:
>
>         1. When I do the <control-minis> to Decrease the font size
>            I can't undo it with the <control-plus>. Also <control-plus>
>            doesn't seem to do anything.
>
>         2. When displaying the "Lane info" why can't I see the
>            branch names?
>

Thanks for the reports, I will investigate as soon as I have a bit of
spare time.

>
> I'll read it a few more times. I seem to sometimes get into a state
> where I'm locked onto the current change set and can't get back to
> the other change sets without starting another qgit.
>

Please, could you be so kind to better explain me the above point.
Seems interesting, but I didn't get how to reproduce.


> >
> > Yes it is. There are a lot of new featrures, is almost as stable as
> > the previous and if you are interested in file history (annotations)
> > in qgit-2.0 this feature has been greatly speeded up.
>
> Do you know if it's a lot of work to install Qt4?
>

With Mandriva you are just at an uprmi away.

Try something like

urpmi libqt4-devel

It worked for me ;-)

Marco

Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.

[Marco Costalba]

On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> While I'm looking at the diffs for a file if I pull down External Diff
> it launches 'kcompare' but for a file with a large change it seems
> to be running extremely slow.

qgit does not intergarte Kompare functionality, it just prepares the
files and spawns a Kompare process.

So there's seem nothing qgit can do about Kompare speed. You can try
with different diff viewers, meld,...etc..


> for small files. Know of what can me done so that 'kcompare' works
> fast on large files; something like pointing it's tmp files to a
> not NFS partition.
>

Well temporary file sfor Kompare are created in the repository working
directory. If this is a problem for you you can save manually the
files corresponding to the two revisions you want to diff (open tree
view, select the file, right click to open context menu, save as...)

You need to repeat the above 'save as...' the first time selecting the
first revision you want to compare, then selecting the other revision
in main view, so that tree view is updated and you end-up saving the
correct files.

You can save the files where you want then run Kompare manually, at
least you test your assumption about slowness of NFS partition.

>
> Another problem I've noticed is that sometime while running git
> it seems to spend a large amount of time  switching from one
> change-set to the next; seems to be due to all of the tagged
> files.
>

If you can post a repository where this occurs and the step to
reproduce I can investigate further.

> > Another feature you asked, i.e. CTRL + right click to select a
> > revision (different from the parent) to diff against the current one
> > is also already implemented.
>
> It seems that while I'm in "Rev List" mode I can select the the
> two versions to compare a selected file with View->External diff...
>
> Now, if I pull down "View File" or go to the file context were
> you see the change-set for a file then I can't get the CTRL + right
> click to allow me to diff two revisions of the file.
>


Yes. This is true, is not supported this feature. Maybe could be added ;-)


>
> MY guess is that I should install a newer version of qgit,
> I'm using 1.5.3.
>

Please install 1.5.7, it has several bugs fixed.

> How difficult is it to upgrade to the Qt4. Can I just
> install it to /usr/local and not interfere with Qt3?

It does not interfere wuth Qt3 also if you install with urpmi,
directories are kept separated. I have installed both with no
problems.

> Last I recall messing with installing ethereal from src
> I needed a graphics lib and as I recall installing it in
> /usr/local/ confused some build crap. It would be interesting
> to try out your new qgit-2.0.
>

Qt4 is big and complex, I would really suggest avoid experimenting
with that library, stay safe and use urpmi.

> >
> > And of course the two above features can be integrated: you select two
> > random revisions and then call the external diff viewer to check at
> > the differences in the way you prefer.
>
> Right, but how do I do this from the file context?
>

In this case (and also in the above case of external viewer) you need
the magic wand ;-)

Select a file from tree view, go with the magic wand and you can do
everithing from main view.

>
> it seems to be pretty big. The date on 1.5.7 was very
> close to 2.0 so I thought they might be very close in
> functionality and you maintaining the same code for
> both the common Qt3 and the new Qt4 to make it easy
> for users to install.
>

Yes it is. qgit-1.5.7 should be very similar to qgit-2.0 regarding the
features you listed above.


Marco

Re: How to Import a bitkeeper repo into git

[Andreas Ericsson]

Marco Costalba wrote:
> On 10/16/07, Andreas Ericsson <ae@op5.se> wrote:
>> Marco Costalba wrote:
>>> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>>>
>>>> Would it be worthwhile
>>>> to install Qt4 from src and try to use qgit-2.0?
>>>>
>>> Yes it is. There are a lot of new featrures, is almost as stable as
>>> the previous and if you are interested in file history (annotations)
>>> in qgit-2.0 this feature has been greatly speeded up.
>>>
>> The only thing I really, really, really don't like about qgit4 is the
>> fact that it fudges up the commit-message. I've been trying for two
>> days to get rid of the HTML output, but I just can't get it done
>> without the signed-off-by email being enclosed in &lt;&gt; tags.
>>
> 
> You mean when you commit some changes or when you brows the revisions?
> 

When I browse the revisions. 

> If it is the highlighted title that annoy you I can try to remove the
> background color, or set as plain text as an option.
> 

That does annoy me indeed, but the primary annoyance is the fact that
the subject is no longer listed with the rest of the commit message, but
rather above the ancestry links.


>> view without the colored box a lot more). The little arrows in the
>> commit window are also fairly annoying, as one quite quickly understands
>> that up-/down-arrows work much better for that sort of stuff anyway.
>>
> 
> Little arrows should already be removable from settings->browse->'Show
> smart labels' , you can also add lateral tabs with
> settings->browse->'Show tabbed revisions' if you like.
> 

Sweet. I'll have to look into it. Thanks for your gentle instruction, and
a great product :)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.

[Robin Rosenberg]

onsdag 17 oktober 2007 skrev Marco Costalba:
> On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
> >
> > While I'm looking at the diffs for a file if I pull down External Diff
> > it launches 'kcompare' but for a file with a large change it seems
> > to be running extremely slow.
> 
> qgit does not intergarte Kompare functionality, it just prepares the
> files and spawns a Kompare process.
> 
> So there's seem nothing qgit can do about Kompare speed. You can try
> with different diff viewers, meld,...etc..

You could avoid the temporary files if you just pipe the diff to kompare. That
would require an option to tell qgit that the external viewer can read a git diff.

At the time qgit 1.5 was written, kompare could not handle git diffs.

-- robin

Re: How to Import a bitkeeper repo into git

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Costalba wrote:
> On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> 't' worked fine but still can see how to diff do of the list of
>> changes for a file. Viewing diffs of files based on change sets
>> worked fine but I think with BitKeeper I found it helpful to be
>> able to do a full 'kompare' type diff the file only; often I'm
>> not interested in which change set it went into.
>>
> 
> Well, open tree view ('t'), select the file you are interested of,
> then click the magic wand button on the tool bar, now revisions you
> see are filtered by that file, if you browse the revisions the
> patch/diff you see will always point to your file (also if you can see
> the whole patch).

I take it the "magic wand button" is the check mark on the upper right
that says "Pin View (Alt-V)".  When I pin the view the view of the file
in Qgit locks to the selected file but the External diff seems to stay
the same. The External diff appears to show my last change to the file;
changing the change-set selection doesn't seem to change anything with
the view pinned.


> 
>> Something for a future version or am I lucky and you have
>> it covered already?
>>
> 
> Don't know, depends on how you answer to the above point ;-)

How'd I do?

> 
>> Good Idea, thought it's brought up a few questions:
>>
>>         1. When I do the <control-minis> to Decrease the font size
>>            I can't undo it with the <control-plus>. Also <control-plus>
>>            doesn't seem to do anything.
>>
>>         2. When displaying the "Lane info" why can't I see the
>>            branch names?
>>
> 
> Thanks for the reports, I will investigate as soon as I have a bit of
> spare time.

ok, I suspect that's an easy one.

> 
>> I'll read it a few more times. I seem to sometimes get into a state
>> where I'm locked onto the current change set and can't get back to
>> the other change sets without starting another qgit.
>>
> 
> Please, could you be so kind to better explain me the above point.
> Seems interesting, but I didn't get how to reproduce.

I'm not sure how I get into this state either, I'll try to recall
how I get into this state the next time it occurs.



> 
>>> Yes it is. There are a lot of new featrures, is almost as stable as
>>> the previous and if you are interested in file history (annotations)
>>> in qgit-2.0 this feature has been greatly speeded up.
>> Do you know if it's a lot of work to install Qt4?
>>
> 
> With Mandriva you are just at an uprmi away.
> 
> Try something like
> 
> urpmi libqt4-devel

    /nethome/piet$ su
    /nethome/piet$ /usr/sbin/urpmi libqt4-devel
                   no package named libqt4-devel
    /nethome/piet$

/urpmi libqt4 also didn't work.

> 
> It worked for me ;-)

I'm running 2005 Limited Edition; I wonder if QT4 even existed then.
Think it's worth messing with QT4 just to upgrade to you latest version?
Some of these graphics libs can be bear to install from src.

- -piet

> 
> Marco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFoLhJICwm/rv3hoRAt73AJ9kWv8EhuaAH/69HqG0+FZOAD8LlgCdH6uU
2PJDFOuZENrKJBA66MOdANc=
=yd6t
-----END PGP SIGNATURE-----

Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.

[Marco Costalba]

On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> You could avoid the temporary files if you just pipe the diff to kompare. That
> would require an option to tell qgit that the external viewer can read a git diff.
>
> At the time qgit 1.5 was written, kompare could not handle git diffs.
>

So does the other tools I have checked at that time.

But I don't know if this fixes the problem of slowness reported. A
little test Pete may do is just as I have written in the former email:
try to save the big files that cause troubles where he prefers and run
Kompare on them directly from the command line.

Is kompare faster? If no probably the 'pipe' technique will not solve
the problem and shrinks the applicability of the external diff
launcher to tools that handle diffs directly.

Marco

Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.

[Robin Rosenberg]

torsdag 18 oktober 2007 skrev Marco Costalba:
> On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> >
> > You could avoid the temporary files if you just pipe the diff to kompare. That
> > would require an option to tell qgit that the external viewer can read a git diff.
> >
> > At the time qgit 1.5 was written, kompare could not handle git diffs.
> >
> 
> So does the other tools I have checked at that time.
> 
> But I don't know if this fixes the problem of slowness reported. A
> little test Pete may do is just as I have written in the former email:
> try to save the big files that cause troubles where he prefers and run
> Kompare on them directly from the command line.
> 
> Is kompare faster? If no probably the 'pipe' technique will not solve
> the problem and shrinks the applicability of the external diff
> launcher to tools that handle diffs directly.

kompare is pretty fast. Obviously not as fast as less.

"git diff HEAD HEAD~1000|kompare -" takes less than two seconds (hot cache)
on my machine. With small diffs it is almost instantaneous.

-- robin

Re: Qgit performance and maintain CVS environment with GIT repository

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Costalba wrote:
> On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>> You could avoid the temporary files if you just pipe the diff to kompare. That
>> would require an option to tell qgit that the external viewer can read a git diff.
>>
>> At the time qgit 1.5 was written, kompare could not handle git diffs.
>>
> 
> So does the other tools I have checked at that time.
> 
> But I don't know if this fixes the problem of slowness reported. A
> little test Pete may do is just as I have written in the former email:
> try to save the big files that cause troubles where he prefers and run
> Kompare on them directly from the command line.
> 
> Is kompare faster? If no probably the 'pipe' technique will not solve
> the problem and shrinks the applicability of the external diff
> launcher to tools that handle diffs directly.

Marco:
   I'll try kcompare on the huge files both on and off the NFS
   file system to see if it has a noticeable impact.

Johannes:
  I read somewhere in the past week that it was possible to maintain
  our existing CVS environment with git. I though it was a separate
  package to export git back to cvs but I just noticed a git-cvsserver
  and as a std part of git and was wondering about using that.

  We have a number of build machines with flamebox perl scripts pulling
  out CVS branches for builds. I was wondering what is the best way to
  use git and it's nicer pull/push model and merge facility and possibly
  maintain CVS exports for scripts doing builds if possible the cvsweb
  and bonsai (CVS Query Form) that a number of engineers are currently
  using. I started looking over out flamebox scripts with the intent
  up converting them over to git but I mentioned the git to cvs
  coexistence and we are wondering if that's a better route than
  upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
  and gitweb along with the git utilities seems at least desirable.
  Any thoughts or suggestions?

- -piet

> 
> Marco

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHF+8/JICwm/rv3hoRApKnAJ4suTVrULHeVnU2HrS3TDo+eTzxVQCbBH7x
NzKdc6wRc1VdAOWgXOXBJ4U=
=RuQc
-----END PGP SIGNATURE-----

Re: Qgit performance and maintain CVS environment with GIT repository

[Johannes Schindelin]

Hi,

On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:

> Johannes:
>   I read somewhere in the past week that it was possible to maintain
>   our existing CVS environment with git. I though it was a separate
>   package to export git back to cvs but I just noticed a git-cvsserver
>   and as a std part of git and was wondering about using that.

Where did you read that?  AFAIK git-cvsserver is one option.  The other is 
cvsexportcommit.  The former is more appropriate if you want to switch the 
developers over to git, and want to provide a smooth path for the devs (or 
cannot convert a few hardcore CVS "fans").

The latter is appropriate if you cannot control the server side, or are 
not allowed to switch to CVS.

> We have a number of build machines with flamebox perl scripts pulling 
> out CVS branches for builds. I was wondering what is the best way to use 
> git and it's nicer pull/push model and merge facility and possibly 
> maintain CVS exports for scripts doing builds if possible the cvsweb and 
> bonsai (CVS Query Form) that a number of engineers are currently using. 

I don't know how cvsweb copes with git-cvsserver, but I guess that there 
will be no problem.

> I started looking over out flamebox scripts with the intent up 
> converting them over to git but I mentioned the git to cvs coexistence 
> and we are wondering if that's a better route than upgrading the 
> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along 
> with the git utilities seems at least desirable. Any thoughts or 
> suggestions?

My suggestion: if you're fine with CVS, stick with it.  Really.  I am not 
here to teach the whole world about the advantages of git, so by all 
means, if you yourself do not find any advantage to using git, don't use 
it.  Stick with what works for you.

Ciao,
Dscho

Re: Qgit performance and maintain CVS environment with GIT repository

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:
> 
>> Johannes:
>>   I read somewhere in the past week that it was possible to maintain
>>   our existing CVS environment with git. I though it was a separate
>>   package to export git back to cvs but I just noticed a git-cvsserver
>>   and as a std part of git and was wondering about using that.
> 
> Where did you read that?
Don't recall exactly, I thought it was a page like the one showing
git Related tools but didn't find it today when looking for it.



>                           AFAIK git-cvsserver is one option.  The other is 
> cvsexportcommit.  The former is more appropriate if you want to switch the 
> developers over to git, and want to provide a smooth path for the devs (or 
> cannot convert a few hardcore CVS "fans").
> 
> The latter is appropriate if you cannot control the server side, or are 
> not allowed to switch to CVS.

I've got root access on the CVS server and want to switch to git without
disturbing the environment more than is necessary to make the switch.
I think developers will want to us git and git-cvsserver looks like
the more likely desirable path.

> 
>> We have a number of build machines with flamebox perl scripts pulling 
>> out CVS branches for builds. I was wondering what is the best way to use 
>> git and it's nicer pull/push model and merge facility and possibly 
>> maintain CVS exports for scripts doing builds if possible the cvsweb and 
>> bonsai (CVS Query Form) that a number of engineers are currently using. 
> 
> I don't know how cvsweb copes with git-cvsserver, but I guess that there 
> will be no problem.
great.

> 
>> I started looking over out flamebox scripts with the intent up 
>> converting them over to git but I mentioned the git to cvs coexistence 
>> and we are wondering if that's a better route than upgrading the 
>> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along 
>> with the git utilities seems at least desirable. Any thoughts or 
>> suggestions?
> 
> My suggestion: if you're fine with CVS, stick with it.  Really.  I am not 
> here to teach the whole world about the advantages of git, so by all 
> means, if you yourself do not find any advantage to using git, don't use 
> it.  Stick with what works for you.

We are definitely not fine with CVS, the branch merging isn't
comfortable. I'm just wondering about maintaining the existing
CVS browsers and the build scripts if it's not a big deal. I'll
try the git-cvsserver path. If anyone has any war stories to share
on the path this would be an ideal time to share them.

- -piet


> 
> Ciao,
> Dscho
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHF/jPJICwm/rv3hoRAkXgAJ9pa/DHxka926i3FHqYTsxCb5kzcQCeKiSk
j/Paxc6tJemOPK0TV8MhFGs=
=ut2Q
-----END PGP SIGNATURE-----

Re: Qgit performance and maintain CVS environment with GIT repository

[Jeff King]

On Thu, Oct 18, 2007 at 05:22:39PM -0700, Pete/Piet Delaney wrote:

> I've got root access on the CVS server and want to switch to git without
> disturbing the environment more than is necessary to make the switch.
> I think developers will want to us git and git-cvsserver looks like
> the more likely desirable path.

Depending on the environment and the willingness of people to change to
git, it might be worth moving slowly and keeping the backend as CVS at
first.  I.e., keep the "official" repository as CVS, and let some devs
start moving to access through git-cvsimport and git-cvsexportcommit
(and maybe even provide an official git repo which is backed by the CVS
repo, so that all of the import/export happens in one place).  That will
give them time to get used to git, give those who are resistant to the
change their original interface, and if anything goes wrong, you can
always fall back to the "old" way.

And then when everything seems to be going well, swap it. Make git the
official repo, but provide a "legacy" CVS access for the die-hards
(using git-cvsserver).

And then eventually just shut off CVS access entirely (when everyone is
happier using git).

Of course none of that is necessary, but one of the nice things about
git is how it can integrate with existing setups, so you can really ease
into a transition without investing a lot of resources.

-Peff

Re: Qgit performance and maintain CVS environment with GIT repository

[Johannes Schindelin]

Hi,

On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:

> I'll try the git-cvsserver path. If anyone has any war stories to share 
> on the path this would be an ideal time to share them.

I was responsible for a medium long running CVS repository, and I wanted 
to switch to git.  For a long time, I just ran tests and tried to flesh 
out things, and eventually went for it.

A few of the patches to git-cvsserver from me were direct results of 
problems we ran to.  But mind you, that was almost over a year ago.

In the meantime, many of my developers switched.  Some because it was 
easier than waiting for me to fix the bugs with the cvs server.

Some because they saw me working with git.

I still do not know why the third group switched.

Now I have exactly one dev left, who refuses to use anything else than 
cvs.  Fine with me.  I can live with other people using inferiour programs 
than myself.

I even patched cvsserver not to print the "committed using git-cvsserver" 
message locally.

But then, I was never a cvs "power" user.  Only a git power user.

Ciao,
Dscho

Re: Qgit performance and maintain CVS environment with GIT repository

[Andreas Ericsson]

Pete/Piet Delaney wrote:
> Johannes:
>   I read somewhere in the past week that it was possible to maintain
>   our existing CVS environment with git. I though it was a separate
>   package to export git back to cvs but I just noticed a git-cvsserver
>   and as a std part of git and was wondering about using that.
> 
>   We have a number of build machines with flamebox perl scripts pulling
>   out CVS branches for builds. I was wondering what is the best way to
>   use git and it's nicer pull/push model and merge facility and possibly
>   maintain CVS exports for scripts doing builds if possible the cvsweb
>   and bonsai (CVS Query Form) that a number of engineers are currently
>   using. I started looking over out flamebox scripts with the intent
>   up converting them over to git but I mentioned the git to cvs
>   coexistence and we are wondering if that's a better route than
>   upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>   and gitweb along with the git utilities seems at least desirable.
>   Any thoughts or suggestions?
> 

If you do convert them to git, you can fairly easily do an automatic
bisect on build-errors, and the developer can (after some time) get
an email of what machines they broke the code on and what the bad
commit was.

Besides that, it's not a black-and-white scenario. If I were you I'd set
up git-cvsserver and make sure that works for all the scripts, and then
pick one or two auto-build things to convert to git. Preferrably on a
separate machine, so everything keeps working the same as always while
you're fiddling with the auto-build stuff.

Just my two cents.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Qgit performance and maintain CVS environment with GIT repository

[Jan Wielemaker]

On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
> We are definitely not fine with CVS, the branch merging isn't
> comfortable. I'm just wondering about maintaining the existing
> CVS browsers and the build scripts if it's not a big deal. I'll
> try the git-cvsserver path. If anyone has any war stories to share
> on the path this would be an ideal time to share them.

As for web browsing the history, our project was quickly convinced
gitweb is a lot better than cvsweb.  We are starting to get use to
basic git.  One developer works on CVS.  This is a bit handicapped,
but workable after a few patches to git-shell and git-cvsserver.

In another project I use git-cvsserver to do the Windows builds.
All development except for minor typos and compatibility things is
done on linux and cvs <-> git works just fine for that model.

	--- Jan

Re: Qgit performance and maintain CVS environment with GIT repository

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Wielemaker wrote:
> On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
>> We are definitely not fine with CVS, the branch merging isn't
>> comfortable. I'm just wondering about maintaining the existing
>> CVS browsers and the build scripts if it's not a big deal. I'll
>> try the git-cvsserver path. If anyone has any war stories to share
>> on the path this would be an ideal time to share them.
> 
> As for web browsing the history, our project was quickly convinced
> gitweb is a lot better than cvsweb.  We are starting to get use to
> basic git.  One developer works on CVS.  This is a bit handicapped,
> but workable after a few patches to git-shell and git-cvsserver.

Could you tell me a bit more about those patches and the need for using
git-shell (haven't even messed with that yet).

Think I can set things up so the CVS updates, checkouts, and the
like that are being used on our build machines can remain untouched
and have the git-cvsserver exactly acting like the current CVS server.
It would be nice if branches and tags work without touching all of the
build machines and their scripts.

I don't think we need to have any developers continuing to use CVS;
but I may be wrong. I think I read that there's a limitation to being
on the main branch and unfortunately most of out tags are on a release
branch.

- -piet

> 
> In another project I use git-cvsserver to do the Windows builds.
> All development except for minor typos and compatibility things is
> done on linux and cvs <-> git works just fine for that model.
> 
> 	--- Jan
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHGHG9JICwm/rv3hoRApQIAJ0Ys6QwxnBAu9tNWrGLU9svwtYXZwCeIFlq
Yr8snPT8TW/nBxFygFr95Ik=
=MtJS
-----END PGP SIGNATURE-----

Re: Qgit performance and maintain CVS environment with GIT repository

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Ericsson wrote:
> Pete/Piet Delaney wrote:
>> Johannes:
>>   I read somewhere in the past week that it was possible to maintain
>>   our existing CVS environment with git. I though it was a separate
>>   package to export git back to cvs but I just noticed a git-cvsserver
>>   and as a std part of git and was wondering about using that.
>>
>>   We have a number of build machines with flamebox perl scripts pulling
>>   out CVS branches for builds. I was wondering what is the best way to
>>   use git and it's nicer pull/push model and merge facility and possibly
>>   maintain CVS exports for scripts doing builds if possible the cvsweb
>>   and bonsai (CVS Query Form) that a number of engineers are currently
>>   using. I started looking over out flamebox scripts with the intent
>>   up converting them over to git but I mentioned the git to cvs
>>   coexistence and we are wondering if that's a better route than
>>   upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>>   and gitweb along with the git utilities seems at least desirable.
>>   Any thoughts or suggestions?
>>
> 
> If you do convert them to git, you can fairly easily do an automatic
> bisect on build-errors, and the developer can (after some time) get
> an email of what machines they broke the code on and what the bad
> commit was.

Could you explain that a bit more. Sounds like you saying it's worth
messing with the flamebox scripts to use git instead of using the git
cvserver and letting them pull the cvs branches as they do now. Is the
existing flamebox email of build log effected buy switching form cvs
to git? I hadn't expect it to change.


> Besides that, it's not a black-and-white scenario. If I were you I'd set
> up git-cvsserver and make sure that works for all the scripts, and then
> pick one or two auto-build things to convert to git. Preferrably on a
> separate machine, so everything keeps working the same as always while
> you're fiddling with the auto-build stuff.

I get the impression your suggestion to first get git-cvsserver serving
the repo so that the build machines works without any change and then to
go to each build machine and update the scripts to use git instead of cvs.

Are there any tricks I need to so on the repo to make the branches pull
out with exactly the same commands that we are currently using. My guess
is that the branch checkouts should work without any messing around.
> 
> Just my two cents.

Hey, you two cents could easily save me hours of messing getting this
conversion done.

BTW, I don't think anyone is checking into the repo, but if they do
can I do another git-cvsimport to just update the one I already did?

- -piet

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHGHUUJICwm/rv3hoRArHsAJ9GQMjpLc5CzpBXnHkxLfBgfwEo/QCdGNfj
DiivgfDDSbIB+9YBZvj/5Z0=
=SBSg
-----END PGP SIGNATURE-----

Re: Qgit performance and maintain CVS environment with GIT repository

[Andreas Ericsson]

Pete/Piet Delaney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andreas Ericsson wrote:
>> Pete/Piet Delaney wrote:
>>> Johannes:
>>>   I read somewhere in the past week that it was possible to maintain
>>>   our existing CVS environment with git. I though it was a separate
>>>   package to export git back to cvs but I just noticed a git-cvsserver
>>>   and as a std part of git and was wondering about using that.
>>>
>>>   We have a number of build machines with flamebox perl scripts pulling
>>>   out CVS branches for builds. I was wondering what is the best way to
>>>   use git and it's nicer pull/push model and merge facility and possibly
>>>   maintain CVS exports for scripts doing builds if possible the cvsweb
>>>   and bonsai (CVS Query Form) that a number of engineers are currently
>>>   using. I started looking over out flamebox scripts with the intent
>>>   up converting them over to git but I mentioned the git to cvs
>>>   coexistence and we are wondering if that's a better route than
>>>   upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>>>   and gitweb along with the git utilities seems at least desirable.
>>>   Any thoughts or suggestions?
>>>
>> If you do convert them to git, you can fairly easily do an automatic
>> bisect on build-errors, and the developer can (after some time) get
>> an email of what machines they broke the code on and what the bad
>> commit was.
> 
> Could you explain that a bit more. Sounds like you saying it's worth
> messing with the flamebox scripts to use git instead of using the git
> cvserver and letting them pull the cvs branches as they do now. Is the
> existing flamebox email of build log effected buy switching form cvs
> to git? I hadn't expect it to change.
> 

git has quite a wonderful tool named git-bisect. In short, it helps track
down what particular commit introduced a bug. Let's say your builds fail
for some reason, and the build-scripts send out the build-log to the
developer. The script can then continue to check the repo by running git
bisect on it and finding the commit that introduced the build-error, and
email that too to the developer. In short, when you check things in at
5 o'clock that doesn't build, you don't have to sit there and wrestle with
it. You can go home, have dinner, tuck the kids into bed, and then open
your mailbox and have an email with the exact commit that introduced the
regression.

Now, if you can also convince your developers to make small and isolated
commits, and your build-system is such that it doesn't rebuild *everything*,
but has proper dependency tracking and suchlike (a properly written Makefile
for example), the developer will get pointed to a commit that affects perhaps
10-20 lines of code within a reasonable time, and it should be so trivial to
fix that anyone can do it.

> 
>> Besides that, it's not a black-and-white scenario. If I were you I'd set
>> up git-cvsserver and make sure that works for all the scripts, and then
>> pick one or two auto-build things to convert to git. Preferrably on a
>> separate machine, so everything keeps working the same as always while
>> you're fiddling with the auto-build stuff.
> 
> I get the impression your suggestion to first get git-cvsserver serving
> the repo so that the build machines works without any change and then to
> go to each build machine and update the scripts to use git instead of cvs.
> 

That's the idea, yes.

> Are there any tricks I need to so on the repo to make the branches pull
> out with exactly the same commands that we are currently using. My guess
> is that the branch checkouts should work without any messing around.

I'm not sure what you mean by that. You can tell git to automatically fetch
any new branches (that's the default, I think), but you'll ofcourse have to
switch to using git-pull instead of cvs co (or whatever you're using now),
unless you use git-cvsserver. AFAIK, git-cvsserver mimics a cvs server well
enough that it accepts all commands and the two are interchangeable (assuming
the background repo conversion has been done, ofcourse).

>> Just my two cents.
> 
> Hey, you two cents could easily save me hours of messing getting this
> conversion done.
> 

That's well-invested money then ;-)

> BTW, I don't think anyone is checking into the repo, but if they do
> can I do another git-cvsimport to just update the one I already did?

Yes. It works incrementally, but since cvs commits aren't atomic, you
have to wait 10 minutes after the cvs commit *starts* to be able to
use cvsimport to move it over to git.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Qgit performance and maintain CVS environment with GIT repository

[Jan Wielemaker]

On Friday 19 October 2007 10:58, Pete/Piet Delaney wrote:
> Jan Wielemaker wrote:
> > On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
> >> We are definitely not fine with CVS, the branch merging isn't
> >> comfortable. I'm just wondering about maintaining the existing
> >> CVS browsers and the build scripts if it's not a big deal. I'll
> >> try the git-cvsserver path. If anyone has any war stories to share
> >> on the path this would be an ideal time to share them.
> >
> > As for web browsing the history, our project was quickly convinced
> > gitweb is a lot better than cvsweb.  We are starting to get use to
> > basic git.  One developer works on CVS.  This is a bit handicapped,
> > but workable after a few patches to git-shell and git-cvsserver.
>
> Could you tell me a bit more about those patches and the need for using
> git-shell (haven't even messed with that yet).

One patch concerned handling "cvs update -p", which was accepted and I
guess will end up in the stable version someday.  One concerned handling
"cvs diff -c", which I never submitted.  I first tried a more general
approach to get diff option processing complete, but I had to backtrack
on that.  Now I have a quite simple hack, but more complete coverage of
diff option processing requires a bit more perl knowledge than I have.

I submitted a patch for shell.c to make it call "git cvsserver server"
if a commandline "cvs server" was passed to it, so you can do CVS+SSH
compatible to normal CVS.  I got so many comments I decided to keep it
for myself for now.

> I don't think we need to have any developers continuing to use CVS;
> but I may be wrong. I think I read that there's a limitation to being
> on the main branch and unfortunately most of out tags are on a release
> branch.

No, you can checkout any GIT branch as it it were a CVS module.

	--- Jan

Re: git push problem - unpack unpacker exited with error code; ng refs/heads/rel2_branch n/a (unpacker error)

[Johannes Schindelin]

Hi,

On Tue, 6 Nov 2007, Piet Delaney wrote:

> I'm getting an error when I try to push back a git repository
> that I just pulled and made a slight change to:
> -------------------------------------------------------------------------------------
> -bash-3.00$ git push
> [...]
> error: failed to push to 'git://cvs.bluelane.com/home/git/blux'

For security reasons, you cannot push to git://, by default. git:// does 
not have any form of authentication or encryption.

You need to use the ssh protocol (probably something like 
cvs.bluelane.com:/home/git/blux in your case).

Ciao,
Dscho