sm-grimoire AT lists.ibiblio.org
Subject: Discussion of Spells and Grimoire items
List archive
- From: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
- To: Eric Sandall <sandalle AT hellhound.homeip.net>
- Cc: Source Mage Grimoire <sm-grimoire AT lists.ibiblio.org>
- Subject: Re: [SM-Grimoire]CVS or Perforce
- Date: Tue, 6 Aug 2002 02:38:30 +0400 (MSD)
Wow, we do think alike.
Here's what I was preparing to say. First of all, our
being slow is simply the consequence of code not being
free -- we take it that only the maintainer is allowed
to make modifications to his/her section, not all the
gurus. This is bad thing because it stifles the
development. There are better methods of making
maintainer aware of the changes, and there are better
uses for the energy of our better and more active
maintainers (no, I don't mean myself). Currently,
grimoire has 121 new bugs, most of which require
minimal changes and testing, and some of them were
fixed in practice. What I'm trying to say is, whoever
can allocate time and is trusted to make changes,
should do so for the common benefit. Not onlt in
his/her section.
Secondly, we can't make the code available to all gurus
because we would have to sync it between P4 and CVS.
I've submitted a spell, VCP, which supposedly allows
for import/export between P4 and CVS (as well as other
SCM), and is sposnsored by P4. I'm exchanging letters
with VCP's author in order to resolve some minor
questions. VCP doesn't support branches, which we don't
have anyway. However, I don't think that in the long
run VCP is the way out, because it will not reduce the
number of problems, it would only allow us not to
multiply this number.
Third point. Subversion. Yeah, yeah. Better CVS? No,
Subversion is different and in fact, has certain
similarities with P4, for instance in a way it supports
branching (there are no branches, only copies of
directories). It does have changesets (transactions),
it does not lock files, it has BSD license, it has
commit and other kinds of hooks that allow
pre-,post-commit processing, e.g. rebuilding things,
backing up database, producing tarballs, whatever, it
does have XML output which pretty much allows it to
produce any flavour of output, and I can go on about
this. The disadvantage? Beta quality. However,
Subversion has the following very appealing quality:
you can "dump" repository database (Berkeley DB) in
earlier version, and "restore" it in the later. I'm
subscribed to the dev list of Subversion and see people
are beginning to use it for production development.
Subversion does have a Windows client, if anybody's
interested, and of course a (minimal) web-interface,
with some CGI glue to for instance make changes to log
messages which are not versioned. There is a script
that allows export from CVS, which doesn't support
branches.
So, I'd like to suggest:
a) make modifications unrestricted to section maintainer;
b) think about/start using VCP to sync up P4 and CVS repos;
c) I volunteer to setup a test Subversion repository
and script the export of CVS repos into it on the
periodic basis. This will require current apache2
2.0.40, current library called neon, current Python,
current PHP (if we need PHP on the same server), and
current Subversion. Each spell is available either in
existing grimoire, or from me (I have httpd-dev,
php-dev exporting code from live CVS repos, which are
not in the grimoire). Subversion is available now from
my section 'collab', but the latest build requires
httpd-dev and latest neon.
Sorry that was too wordy.
Sergey Lipnevich,
Guru for section 'collab'.
Eric Sandall <sandalle AT hellhound.homeip.net>:
> Fellow Source Mage Developers,
>
> This (beginning) thread is not meant to restart the
CVS vs. Perforce wars,
> but to bring up something I think we should talk about.
>
> We currently have most of our developers using
Perforce (which I like) and
> some using CVS (which I also like, but haven't used
nearly as much as
> Perforce, but this is also Open Sourced ;)). I don't
see a problem with
> people using one or the other except that this
creates extra work for Eric
> Schabell as he needs to sync the CVS with Perforce.
I noticed that while
> Schabell was gone on vacation the CVS updates were
not synced with
> Perforce (not that he should have, it was his
vacation. :)).
>
Sergey Lipnevich, MCSE, SCPJ,
Sr. Software Engineer,
New Age Network New York, Inc.,
+1-848-459-LIPN.
-
[SM-Grimoire]CVS or Perforce,
Eric Sandall, 08/05/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Andrew Stitt, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Julian v. Bock, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Andrew Stitt, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Ryan Abrams, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Dufflebunk, 08/06/2002
- Re: [SM-Grimoire]CVS or Perforce, Andrew Stitt, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Dufflebunk, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Ryan Abrams, 08/06/2002
- Re: [SM-Grimoire]CVS or Perforce, Eric Sandall, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Ryan Abrams, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Andrew Stitt, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Julian v. Bock, 08/06/2002
- <Possible follow-up(s)>
-
Re: [SM-Grimoire]CVS or Perforce,
Sergey A. Lipnevich, 08/05/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Eric Sandall, 08/05/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Jon Svendsen, 08/05/2002
- Re: [SM-Grimoire]CVS or Perforce, Julian v. Bock, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Sergey A. Lipnevich, 08/05/2002
- Re: [SM-Grimoire]CVS or Perforce, Ryan Abrams, 08/05/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Eric Sandall, 08/05/2002
- Re: [SM-Grimoire]CVS or Perforce, Sergey A. Lipnevich, 08/05/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Jason Flatt, 08/06/2002
- Re: [SM-Grimoire]CVS or Perforce, Eric Sandall, 08/06/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Jon Svendsen, 08/05/2002
- Re: [SM-Grimoire]CVS or Perforce, Laurent Wandrebeck, 08/07/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Eric Sandall, 08/05/2002
-
Re: [SM-Grimoire]CVS or Perforce,
Andrew Stitt, 08/06/2002
Archive powered by MHonArc 2.6.24.