On 18/02/2014 17:10, Andreas Krüger wrote:
Hello, Bill and all,
Hi Andreas,
don't take my comments below as a vote against git as a VCS, I feel that
git is the way to go and compared to it Subversion is clumsy and a
legacy product. I am just think aloud ;)
I guess I'm suggesting
* opening up GitHub something like March 1,
Given the other requirements of the project - Wiki (not used, but should
be), mailing lists, issue tracking (not used, but could be), ... I don't
consider GitHub as a suitable place for a project that isn't fully
distributed. The other hosting providers being mentioned do include
these extra facilities AND a git bare repository facility. Unless
convinced otherwise I suspect that GitHub is not a good destination for us.
I see GitHub as a place for individuals to locate their public bare
repositories or as a location for truly distributed projects. The WSJT
projects are more centralised and mature, needing the other facilities
above. We mustn't loose sight of the scope of the task in hand here, the
migration of the public repository is probably the easiest part which
can be done on virtually all of the available OSS project hosts.
* use both BerliOS and GitHub in parallel for
some weeks, as an experiment, migrating back
and forth (I'd be willing to help in that),
You need to define what you mean as 'parallel' working entails. I can
see a possibility of having a non-authoritative read only git bare
repository that developers and others could clone for testing or
training purposes. The problem I see with that, is the real power and
complexity of git happens when you start making changes (fetch, pull,
branch, edit, add, commit, rebase, push, pull-request, ...) which one
intends to have accepted in the authoritative public repository. How
would you propose a developer do work on such a parallel git repository.
For example who would make sure that the upstream git repo is always
mirrored the authoritative svn repo? For those that know git this would
be a hindrance and to those that don't, probably an overcomplicated
place to learn a git work flow.
For a simple example; before I issue a pull-request to the project
integrator, I always update my fix/enhancement branch to the latest and
greatest and at least do a build. In such a parallel working environment
how I can be sure that I have the latest changes from others? I'd rather
use 'git-svn clone ...' and work with fix/enhancement branches in my
local repo; then 'git-svn rebase', final build, 'git-svn dcommit' i.e.
no need for a public git repository unless I want to collaborate with
others on a fix/enhancement. This way I get all the local branching and
stashing with piecemeal incremental changes without anyone having to
maintain parallel public repositories.
I would suggest a fork on git of the svn repo and use that to test the
migration and for developers to use as a temporary 'sand pit' to learn
git. Also to choose the best suited of the many possible git work flows
for the projects. Rather than treating it as any sort of parallel
project, just use it as a throw away experiment before doing (or not
doing) a final real migration. There's no reason why such a 'throw away'
repository can't be kept up to date with checkins from svn, but in the
other direction IMHO will just cause problems and confusion.
* forget about Git if it didn't work out,
or else forget about BerliOS and be done.
I have no answer to the mailing list question.
I had considered hosting some initial Git
on my private server. But there's really
no reason why not to start with GitHub
right away.
See above, also the OSS hosting providers have very high availability,
do backups, snapshots, and have almost unlimited bandwidth which is hard
to compete with on a lesser server.
Regards, Andreas
DJ3EI
73
Bill
G4WJS.
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
