version control system

version control system

[Frank Ch. Eigler]

Hi -

Are people generally happy with cvs?  If not, we could add bridges to
mercurial or git or even replace cvs outright.

- FChE

RE: version control system

[Stone, Joshua I]

Frank Ch. Eigler wrote:
> Are people generally happy with cvs?  If not, we could add bridges to
> mercurial or git or even replace cvs outright.

If nothing else, moving away from CVS will help things like reproducing
snapshots.  It is very convenient to have a revision/commit-id that
uniquely describes the entire tree, which most other SCMs support.

I generally dislike CVS, but I've been making do with my own local git
import.  The import is actually pretty simple to create and keep sync'ed
(git-cvsimport), but committing changes is not well integrated
(git-cvsexportcommit).  If we publish a git "mirror" of CVS, I think
we'll have the same commit issues to deal with.

Subversion is nice because it's not too different for those used to CVS,
and git-svn is well integrated for people like me who enjoy DSCM.

If we are willing to fully jump to DSCM, the I vote for git, but only
because I haven't tried any others (mercurial, bazaar).  We could even
run a git-cvsserver for the dinosaurs to use. :)


Josh

Re: version control system

[Frank Ch. Eigler]

joshua.i.stone wrote:

> [...]  If we are willing to fully jump to DSCM, the I vote for git,
> but only because I haven't tried any others (mercurial, bazaar).

Well, why not give it a try.  The following URLs will all work to keep
roughly up-to-date with systemtap.  They contain only a periodically
git-cvsimported form of the src/ tree; the others (doc/, patches/)
would need their separate repos.

        git://sources.redhat.com/git/systemtap.git
        ssh://sources.redhat.com/git/systemtap.git
        http://sources.redhat.com/git/systemtap.git

While the "ssh:" URL can accept git push, let's not try that until
when/if we decide to switch over altogether.

> We could even run a git-cvsserver for the dinosaurs to use. :)

With sourceware being a machine shared amongst diverse projects, this
could be difficult.

- FChE

RE: version control system

[Stone, Joshua I]

Frank Ch. Eigler wrote:
> 
> joshua.i.stone wrote:
> 
>> [...]  If we are willing to fully jump to DSCM, the I vote for git,
>> but only because I haven't tried any others (mercurial, bazaar).
> 
> Well, why not give it a try.

Since I'm the only one who responded, I may be the only one who cares,
but thanks for humoring me.

> The following URLs will all work to keep roughly up-to-date with
> systemtap.  They contain only a periodically git-cvsimported form of
> the src/ tree; the others (doc/, patches/) would need their separate
> repos.
> 
>         git://sources.redhat.com/git/systemtap.git
>         ssh://sources.redhat.com/git/systemtap.git
>         http://sources.redhat.com/git/systemtap.git

The "http:" URL works for me, but as a "dumb" transport, that's not
optimal.  I can't use the "git:" URL because of Intel proxies.  When I
try the "ssh:" URL, I can get to the server, but I get an error:

  fatal: ''/git/systemtap.git'': unable to chdir or not a git archive
  fatal: The remote end hung up unexpectedly
  fetch-pack from 'ssh://sources.redhat.com/git/systemtap.git' failed.

> While the "ssh:" URL can accept git push, let's not try that until
> when/if we decide to switch over altogether.

Right -- this should be treated as read-only until we've actually
migrated.

If we do fully migrate, it would be nice to more closely attribute
authors.  See the '-A' option to git-cvsimport.  I count only 24
different committers (git log | git shortlog -s), so it's not too bad.
I don't think we need to worry about translating the author/committer
relationships of "on behalf of ..." commits, but it's nice that git can
maintain that in the future.

Another thing to beware of: by default, git-cvsimport pulls into an
'origin' branch, and on the first import it creates a 'master' branch
for you.  However, future import-syncs will only move origin.  (In fact,
your systemtap mirror is already out of sync in this fashion.)  Since
HEAD is pointing to master, anyone who clones is going to get the stale
branch by default.

It also looks a little weird when you clone it to see the remote
branches 'origin/origin' and 'origin/master'.  So I prefer to make
git-cvsimport go directly to the 'master' branch with the '-o' option.
 
>> We could even run a git-cvsserver for the dinosaurs to use. :)
> 
> With sourceware being a machine shared amongst diverse projects, this
> could be difficult.

Understood.

Thanks,

Josh