Questions on 'cvs migration guide''

Questions on 'cvs migration guide''

[Martin Langhoff]

In the section 'Emulating CVS behaviour', where the team setup is
described with a team 'merger'. What is not clear is how to deal with
project-wide branches. Should they be created in the master repo, and
everyone clone a new repo from it?

With a team of 10 people, and perhaps 4 or 5 branches, the setup to
pull stuff back seems messy.

And yet another question: the teammember who is pulling must 'switch'
the merging repo to the right branch, pull from the corresponding
remote repos of each teammember, and push to the public view of the
repo. Is that right?

cheers,


martin

Re: Questions on 'cvs migration guide''

[Linus Torvalds]

On Fri, 19 Aug 2005, Martin Langhoff wrote:
>
> In the section 'Emulating CVS behaviour', where the team setup is
> described with a team 'merger'. What is not clear is how to deal with
> project-wide branches. Should they be created in the master repo, and
> everyone clone a new repo from it?

Just make them another branch in the master repo. Whether people will 
clone a whole new repo for it, or have just one repo and switch between 
local branches in their own local (single) repo is their personal choice. 
Some people may well prefer to have all different branches checked out in 
different places (ie have one repository per branch) others may prefer to 
work with one repository and just switch.

> And yet another question: the teammember who is pulling must 'switch'
> the merging repo to the right branch, pull from the corresponding
> remote repos of each teammember, and push to the public view of the
> repo. Is that right?

.. yes. Or alternatively, just keep the repo at that branch (and if such a 
person works on multiple branches, he/she can thus just keep multiple 
repos). 

		Linus

Re: Questions on 'cvs migration guide''

[Martin Langhoff]

On 8/19/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > And yet another question: the teammember who is pulling must 'switch'
> > the merging repo to the right branch, pull from the corresponding
> > remote repos of each teammember, and push to the public view of the
> > repo. Is that right?
> 
> .. yes. Or alternatively, just keep the repo at that branch (and if such a
> person works on multiple branches, he/she can thus just keep multiple
> repos).

I'm keen on keeping my 'merge & publish' step in a single repo that
has all the 'team' branches. The person running this repo will
probably actually code in separate repos, and merge in there too.

Right now I'm switching 'heads' (I'm getting used to cogito's use of
'branch' for 'remote head') using this quick'n'dirty bit of shell:

#!/bin/bash 

HEADNAME=$1

if [ -e .git/refs/heads/$HEADNAME ]; then
	cd .git/
	ln -s -f .git/refs/heads/$HEADNAME HEAD
	cd ..
	cg-reset
	cg-restore -f

fi;

but I want to prevent the action if the checkout is 'dirty'. Is there
any way to check whether cg-diff thinks anything has changed?

cheers,


martin

Re: Questions on 'cvs migration guide''

[Linus Torvalds]

On Fri, 19 Aug 2005, Martin Langhoff wrote:
> 
> I'm keen on keeping my 'merge & publish' step in a single repo that
> has all the 'team' branches. The person running this repo will
> probably actually code in separate repos, and merge in there too.

I would suggest against a person owning a "merge and publish". Instead, 
just have a public repo that everybody involved to can push to - _they_ 
will need to merge before they push (since a push won't accept a unrelated 
parent), but that way anybody can export their changes at any time, 
exactly like with a central CVS repository.

> Right now I'm switching 'heads' (I'm getting used to cogito's use of
> 'branch' for 'remote head') using this quick'n'dirty bit of shell:

No, just do

	git checkout <headname>

> but I want to prevent the action if the checkout is 'dirty'. Is there
> any way to check whether cg-diff thinks anything has changed?

If you use "git checkout" to switch branches, it will do that testing for 
you. You can still _force_ a head switch with "git checkout -f".

Oh, and if a file was dirty that is the same in both heads, the 
"dirtyness" follows you into the new head. If that isn't what you want, 
then you need to add some logic like

	if [ "$(git-diff-files)" != "" ]; then
		echo "Current branch not clean" >&2
		exit 1
	fi
	git checkout "$@"

or something.

		Linus