Hi List,
the code repository is a small but important piece of Matterhorns
infrastructure and processes. On Matterhorns way from a founded to a
community driven project, a lot of processes have changed and will
change. I would propose to see this decision not isolated for one system
or another. The system has to fit with the new community processes for
dev, QA and release. We should do both together - define processes and
systems we use.
AND remember all the community members have to use it. You can collect
tonnes of pro's and con's for one system or another - if the community
don't adopt it, they don't use it and stop contributing in various areas
(dev, qa, ...).
So be careful with you decision, it concerns not only the developer and
it is part of a lot of processes. Those who will get involved to solve
our staff shortage have to be happy to come on board with this tool and
the processes we gave them as guidance for contribution.
Just my two cents
Nils
On 21.11.11 18:56, Denis Meyer wrote:
On 11/21/11 6:39 PM, Christopher Brooks wrote:
Hi Denis,
Here are some disadvantages from my perspective:
- everyone needs to learn it and become productive enough with it
- we need to change our jira setup to use git, presumably this needs to
be done with cru as well
- all of the docs that are svn explicit need to be changed to git
explicit
- all of scripting that we have written (which is not tonnes, but some)
would need to be redone
That is certainly true but I think after the short learning phase
(yes, short, because it's not that different from handling other
version controls) it will be a pleasure working with git and all
developers save so much time (not just because of the faster checking
out/checking in/branching but also because of the improved automated
merging back).
I don't know how hard it is to change the JIRA setup, though.
Most of the advantages of Git exist with SVN too. For instance, these
are all true with SVN:
- better access, easier to join development for new developers
- work on their own repository
- push to shared repository when ready
- many developers work in different countries simultaneously
- security:
- immediately after the repository clone, there is basically no
information about that project that the server you cloned from has
that you do not have (including ALL changes and revisions)
- every person working on your project has what is essentially a
full backup of the project data
No, I don't think so. An example: As a new developer that does not
have commit rights for the svn repository yet, you can't push your
changes without sending a patch to somebody that has rights to check
the changes in. With git it is easier. You just commit into your local
branch, you have all the advantages of version control and send a pull
(or merge) request later.
And I listed much more arguments for git than just the checking out of
the history.
I'm not really anti-git, it seems fine enough. I'm anti-change for
changes' sake; our velocity is already low and our processes are
just getting cemented (finally) with SVN. I don't want to slow
development down any further.
I'd be against changing while we have a release in the pipe. I see
changing as just another distraction on getting the software going,
unless everyone developing on the project was already familiar with
git. I'd be more relaxed about this between releases, but want anyone
who thinks it would slow them down to announce that clearly; if enough
would lose cycles on this then the wins just aren't significant to me.
You're absolutely right, it is not a good idea to change the system
while we're in the middle of a release. I just wanted to start the
discussion soon.
Chris
Denis
--
Denis Meyer
Universität Osnabrück
ELAN e.V., Zentrum virtUOS
Raum 42/205, Heger-Tor-Wall 12, D-49074 Osnabrück
E-Mail: [email protected]
Web: http://www.virtuos.uos.de
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
