Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Fri, 15 Aug 2003 09:25:56 +0100
Subject: Re: SVN on MacOS X
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Alex Blewitt <Alex.Blewitt@ioshq.com>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <6C94CFBC-CEF3-11D7-ACF2-000A9566A360@coredevelopers.net>
Message-Id: <17974205-CEFA-11D7-BB42-0003934D3EA4@ioshq.com>

On Friday, Aug 15, 2003, at 08:38 Europe/London, Jason Dillon wrote:

> Last I check the fink (or was it the binary apt-get) svn package was 
> not being maintained :-(

Doesn't help :-)

>> WHAT?! Subversion is fully supported on MacOS X. A number of the SVN
>> developers' primary platform is MacOS (e.g. Justin Erenkrantz).
>>
>> And from what Noel was saying, it seems that it may be that all you 
>> need to
>> do is to build svnup on your platform, and it will work within 
>> Eclipse.
>>
>> Subversion is built using the Apache Portable Runtime (APR), meaning 
>> it runs
>> everywhere the Apache web server does. That is a *lot* of platforms.

True, but I don't use the command line whilst developing in Eclipse. I 
point to the project and click on 'update'. Or 'Create patch'. Or 
'Apply patch'. cvs -Rt? diff -u-r? No idea. Don't care, either :-)

I've never found it necessary to learn how to use the command line 
equivalents for these tools, either using Eclipse, or WSAD (or its 
older cousins, Studio and Visual Age).

>>> Sorry, but I don't really care how the server works -- I need the
>>> client to work :-)
>>
>> The command line client absolutely works on your platform. It has for 
>> a long
>> time. And it sounds like subclipse might, if you simply build the 
>> sucker.

By 'client', I meant 'Eclipse', not command line stuff. Sorry if I 
don't grok the command line versioning tools, but that's the way I've 
been brought up -- expect the app to do it for you :-)

>>>> The suggestion that "lack of Eclipse" integration is enough to *not*
>>>> consider SVN seems rather short-sighted. It seems like you aren't
>>>> considering the other side of the equation. What do you *get* by
>>>> switching?
>>>
>>> The ability to not develop code on my machine? A small space saving 
>>> on
>>> the server? Log messages from when the code was very old?
>>
>> You're off the deep end here. SVN works fine on MacOS X.

OK. SVN has advantages. Possibly many advantages over CVS. I'm 
certainly aware that a lack of 'CVS move' has hurt a number of times 
before.

But at present, SVN isn't supported in my primary development tool. 
You're asking me to come out of the tool that I use to work and run a 
few command line options to get/update/commit changes. Instead, I can 
do these things within Eclipse at the moment with point-and-click for 
CVS.

And from what I see, the major disadvantage of CVS is that you loose 
changes during moves. Well, I think that moves will happen a lot in the 
initial months as design/structuring settles, but after that will 
remain fairly constant. And I don't think you loose that much by not 
being able to get back to changes made before the move occurred. Even 
if you wanted to, you could still access the old files from the Attic 
in the old locations anyway, so it's a bit more work to find out such 
changes.

I think it boils down to which is done more often; moving files from 
one directory to another (and then wanting to access changes prior to 
the move after it has happened), or checking code in and out using my 
IDE interface. I'm going to do the latter daily; the former I don't 
think I'd want to do maybe two or three times in the project's 
lifecycle. Optimising the latter in detriment to the former isn't a 
worthwhile tradeoff for me.

>>>> Of course, I'm biased :-), but I also think the discussion needs to
>>>> think
>>>> about more items than simply Eclipse integration.
>>>
>>> There aren't a whole lot of other decent tools available for free on
>>> Mac OS X. Cutting a small-but-non-negligible user-base out of
>>> development to save bytes on the server isn't a good tradeoff IMHO.
>>
>> It isn't about saving bytes. It is about tracking the history of the
>> project. 'svn copy' is also just as important as moves. And the atomic
>> commits.

Can you tell me why atomic commits are so good? CVS has always seemed 
to work for me, though I expect there are parts of the implementation 
that could work better. But as a developer, what's in it for me?

Alex.