[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Git migration and ECF 3.4 timing: PLEASE READ
- From: Wim Jongman <wim.jongman@xxxxxxxxx>
- Date: Tue, 3 Aug 2010 13:26:07 +0200
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wvRqscC8LmVlUWfDDLmJBA091AFoVt8drjQO+NEjGz/wydtIh3WWHmaj05nUuD1bGt QCJZ3uAoayjqhdqFO6Ai7njPNpkrTOYaP7+Q09+KJV7NPZXx2MriYCnhiMyz30W5pFNh 6VDjfeEv9FQtYQx2xyyncfvgUk0DBm1jo4W0Q=
Personally I don't even see the need to keep a CVS repo in the first
place. For a consumer what's the difference between "cvs co $REPO" and
"git clone $REPO"? This might sound ignorant, but if consumers want to
make sense out of ECF, they should at least be able to use a SCM.
Otherwise they will fail with ECF anyway. %)
Yes, I see your points. It is the usability I am concerned about. I have changed my stance a little bit in favor of the occasional user. If someone is trying something out but needs to do a lot of work, he might get put off.
Why did my stance change:
I had to patch my remote services blog , I got a reply from a user on july the 9th . I never heard something from him since that time. I then read my blog and realized that is was broken because of the ECF1 shutdown. Did we lose one user to the competition because of this? I say yes. One soul lost to enemy. (dramatic music and drums)
That does not say "do not go to git", but we want to make sure our current stuff stays working until we have replaced it.
A CVS sync will buy us time to sort all this stuff out until we can replace it with an alternative.
Get the sources
Please fire up a Helios with a new workspace and get the two bundles needed for this example from this project set
** (copy this file in a project, give it the extension .psf, right click and choose Import Project Set...).