[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] cvs, servers and stuff.

On Wed, 16 Aug 2006 00:08:18 +0200 Kim Woelders <kim@woelders.dk> babbled:

> It seems to me that our SCM system feature requirements are extremely
> limited. We hardly ever tag or branch, let alone do merging between
> branches or anything resembling changeset management.
> I think CVS amply provides the features we need. It's simple and robust.
> It's far from perfect, but as Michael says - It's the devil we know.
> I don't believe changing SCM will make any significant difference to the 
> problems that we appear to have, except possibly on a very short term. 
> Even in the unlikely case that some SCM system is twice(four/ten/... 
> times) as fast as CVS the problem we have will resurface if/when the 
> user base grows accordingly.
> Unless there happens to be an SCM system that is just incredibly more 
> efficient than CVS I also think that we would make a change for the 
> wrong reason. Changing SCM system should IMO be done only if we 
> want/need particular features not available in CVS.
> In the unfortunate case that it is concluded that we want to switch away 
> from CVS I hope it will be to git. Not because I know it from personal 
> experience, but simply because it is used by linux and xorg, which are 
> two projects I respect.

i agree with everything you said - we need very few features - we need history
management so we can see who did what to what and when - that is enough to be
able to roll back. i am looking at git, but i would only move if it really is
an order of magnitude faster (and i dont mean by download times but by how many
users can a single server handle before it becomes useless).

i had been hoping to get benchmarks - and - we have some! yay! i do agree they
need to test what happens if you get 10 or 20 clients at once using it.

svn is also an option - but so far it deosn't seem to really be far ahead
enough of cvs to warrant much further looking :(

of course we could consider much more exotic solutions...

insead of anon cvs we could provide server-side regular "make dist" tarballs
and go back to a download-only distriubtion mehcanism.

anonymous users really have little use for cvs beyond limiting download sizes
of updates. what alternative options do we have?

raw tarballs of cvs module checkouts generated by servers - make dist tarballs
of particular sub-projects - making a cvs checkout file tree available over
http, ftp or rsync?

we can look at this instead...

> /Kim
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)