Being of the group that has to make this transition I thought I'd chime
in on both of Sean's messages. Let me preface this by annoncing that
we're making the change. I just feel the need to talk about it more :)
OK, I know you will have to start from scratch. So the question is, "Does
anyone currently use the svn repo at changeset level, or is it just a tool
for facilitate collaboration." I think you may find it is the later.
In QA we use changeset controls every day. As you've probably seen on
the list here, changepackages provide the best level of detail for
mainitaining the codebase and collaboration. Some changes don't require
that level (docs for example) but when nailing down a regression,
quiclkly isolating the offending patch allows me to find the line of
code that caused the regression.
<evil-grin>Me being the newbie, could not care less about the anything but
HEAD. If there is nothing valuable in the change set, svn dump, do a backup
and let's start over.</evil-grin>
That's also the shortest route to functionality.
Deciding to use a closed source tool is a slippery slope.
The decision to use Perforce was made a long time ago, in a business
model far far away...
I think you almost
have to be fanatically religious about something like this. All open source
or nothing. The other solution is perhaps to move away from the centralized
model and use a distributed system like Bazaar. I think the later may not be
an option, considering the learning curve.
All or nothing means we dump Jira too. I have other reasons to consider
*that* move too, but at least with Jira the developer needs not taint
their environment.
If possible, I would like to use tools under a free license.
<thinking>Geez, I hope this trouble is not because of me.</thinking>
This is not a new debate for us. Balancing the principles of open source
and the practice of moving around SCM takes some doing. Managing the
priorities of a small IT staff in that mix adds its own challenges.
and later...
Looking forward, to a day when open versions of flash or other runtimes will
be more ready and available, do you really want to be in a situation where
you are using a closed source tool for revision management?
Even Linus used BitKeeper. Sometimes the right tool isn't under the
right license. Perforce has shown themselves to be supportive of the
open source community by providing free licenses to projects looking to
use p4. Linux on BitKeeper is past tense now for many reasons, but I'm
sure you see my point. At the time of that choice, it was the best tool
for the job. Perforce was not seen as ready for a project of that size
and IIRC the Subversion team asked not to be considered for the same
reason. Perforce is used for larger projects than Linux but it takes
real work and has downsides. For example, nVIDIA uses P4 for everything
including their complete library of silicon layouts.
The decisions we make today, will determine our reality in the future. That
future looks very open source. I am an open source zealot, I am willing to
accommodate that the runtime is not open due to limitations in the
availability of open source alternatives. I am not willing to tolerate using
a closed source tool for revision management when there are suitable and
accessible free tools available now.
No disagreement there. Perforce was chosen because it was the right tool
at the time for the job we were doing. I will say that until last year
P4 had terrible support for those of us using open source in the rest of
our life. I've been 100% Linux for a long time now and the disparity
between the toolsets was terrible. I've since become so effecient with
the original command line tools that when the gap was closed, I didn't
need the super-gui. Though the Qt based merge tool is quite nice.
Look at it this way. When an open source zealot arrives at an open project,
there is an expectation that the project has embraced open source philosophy,
methodology, technology and license to the fullest extent possible. If this
is the case, then the way for participation is made easy and the zealot can
tolerate the use of non-GPL software.
We've spent a lot of time considering this transition. Moving our source
repository to another SCM is expensive. It's going to cost us time,
history, stability and training/transition time up front and have
continuing cost coordinating merges. Moving the repository to a
free-licensed perforce instance is nearly free.
That being said, the cost to the long term heath of the whole project is
probably greater than the cost of the transition. Alienating a whole
class of developers and contributors is not in our best interests. No
sense in beeing penny wise and pound foolish with this choice. It's
worth doing for that reason.
The reality of the database problem is that proper attention from the system
admin and a suitable plan for backup and continuity would have seen this
problem being much less dramatic than what it is.
Unfortunately that is an argument for staying with Perforce. We're
learning that our initial installation may have been flawed and altering
the configuration will (in thory) return the repository to a stable state.
On pure technical merit, Perforce has many advantages over Subversion in
_some_ development patterns. Perforce is not designed for the way we
want to work in the open source world. Perforce's main flaw is that it's
not optimized for disconnected development.
--
Mark Davis
Sr. Manager, QA & IT -- Laszlo Systems
${this.title} -- OpenLaszlo.org
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
