Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 27 Feb 2003 14:09:52 +0000
Subject: Re: [proposal] Pruning up the CVS tree for real
From: Pier Fumagalli <pier@betaversion.org>
To: <cocoon-dev@xml.apache.org>
Message-ID: <BA83CCB0.C661%pier@betaversion.org>
In-Reply-To: <3E5E14D5.4040006@apache.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

"Berin Loritsch" <bloritsch@apache.org> wrote:

> Pier Fumagalli wrote:
>> 
>> And no issues in UNIX AFAICS... We (VNU) have already planned the adoption
>> of SVN as our backend repository for a number of reasons (the primary one
>> being that we will use it as our distributed filesystem, having our web
>> applications deployed from a URL like http://svn.vnunet.com/app/live )...
> 
> I assumed it was written primarily on UNIX--much like CVS originally
> was.   That would explain the client/server reliability in those
> environments.

Actually, I believe that it's written also by an extended and reshaped set
of the original CVS authors...

>> But as for you, for us the client is _damn_ important... And we need not
>> only to think about UNIX (server side), but with windows (JSPs amd XML
>> writers) and with MacOS/9 and X (all our graphics production team)...
> 
> Yep.  To be honest I would not be happy if the server was on a Windows
> box--but that's just me.  Windows is OK for the client (I am forced to
> use it for that), but it sucks for a server IMNSHO.
> 
> Honestly, the primary concern for me is the svn CLI binary.  All I want
> to do is use that.  I don't use WinCVS, and most of the time do my
> checkouts/updates manually using CygWin (I love that tool--it lets me
> pretend I am on Unix while being forced to use Windows).

Yes, but I can't tell my graphics designers to use "svn ci" to do the whole
thing... They need something easier than that! :-)

>> We're testing hard on the baby, it's not quite there yet, but looks so
>> promising to us that we're investing quite a good amount of time on it..
> 
> That's good news.  I know XP gave the Mozilla project some fits (and for
> some reason I seemed to be the only experiencing those problems), but
> they seemed to have worked them out now.  I am looking forward to when
> it is finished.  I think the concept rocks.

SVN is based on APR, so if you're having troubles w/ it on XP, also Apache
2.0 will... Those issues will be sorted out pretty soon, I believe, if they
haven't already been addressed and fixed in the repositories...

> I do have one question though.  In Cocoon CVS, and Avalon CVS, and many
> project's CVS, the source code has a "magick string" that automatically
> gets updated by CVS with the current revision and date that the file
> was last checked in.  Will SVN have a replacement for that?  Or will
> it support that feature from CVS?  I imagine it would be a little more
> daunting as any checkin would update the $revision: 1.5.1.2$ string
> in every file because there is only one number for all the files.  That
> would force all files to be updated everytime something is checked in.

Of course it does! :-) And you can even "extend" the set of properties you
want to attach to a file... Some properties (like "revision") are built in
and dealt with automatically (incrementing version number on each checkin).
Other properties can be custom and you can basically attach anything to them
(look at the DAV/DeltaV specs, I didn't follow closely this part in
particular, I just know that it can be done).

> Anyway, it isn't that important--but important enough to let people
> know about it.

Nono... "$revision" is important, IMVHO... And SVN supports it...

    Pier