You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Alex Blewitt <Al...@ioshq.com> on 2003/08/15 10:25:56 UTC

Re: SVN on MacOS X

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.


Re: SVN on MacOS X

Posted by "Daniel S. Haischt" <me...@daniel.stefan.haischt.name>.
Alex Blewitt wrote:

> 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 :-(

do you mean the subversion server?

i am just asking because the client packages are there.

[...]


Re: SVN on MacOS X

Posted by Dain Sundstrom <da...@coredevelopers.net>.
[12:24:39] dain$ svn --version
svn, version 0.23.0 (r5962)
    compiled Aug 14 2003, 01:46:05

Copyright (C) 2000-2003 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) 
protocol.
   - handles 'http' schema
* ra_local : Module for accessing a repository on local disk.
   - handles 'file' schema
* ra_svn : Module for accessing a repository using the svn network 
protocol.
   - handles 'svn' schema



On Saturday, August 16, 2003, at 03:46 AM, Jason Dillon wrote:

> What version of svn did fink install?
>
> --jason
>
>
> On Saturday, August 16, 2003, at 05:07  AM, Dain Sundstrom wrote:
>
>> I got it working on my Mac and I barely know how this thing works.  
>> Just install Fink Commander and click on the svn module (then wait 3 
>> hours while  builds it from source... macs are slooooow).
>>
>> Then I installed a Java GUI wrapper package, supervision, and it all 
>> seems to work well.
>>
>> -dain
>>
>> On Friday, August 15, 2003, at 04:08 PM, Noel J. Bergman wrote:
>>
>>> Brian,
>>>
>>> I'm finding it interesting that no one else seems to be commenting 
>>> about Mac
>>> OS X support, but if there is someone around (Justin, perhaps?), who 
>>> could
>>> do a build for him, that could put an end to the discussion.
>>>
>>> I get the strong feeling that he's a Java IDE person and probably 
>>> doesn't
>>> know how to build a native code app.
>>>
>>> Eventually, it might be nice if subeclipse adopted Harald Wellmann's 
>>> vision
>>> to use the webdav transport, rather than having to have any native 
>>> code on
>>> the client.  Wouldn't bother me to see SVN-UP's native code approach
>>> deprecated.
>>>
>>> 	--- Noel
>>>
>>>
>>
>> /*************************
>>  * Dain Sundstrom
>>  * Partner
>>  * Core Developers Network
>>  *************************/
>>
>
>

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/


Re: SVN on MacOS X

Posted by Jason Dillon <ja...@coredevelopers.net>.
What version of svn did fink install?

--jason


On Saturday, August 16, 2003, at 05:07  AM, Dain Sundstrom wrote:

> I got it working on my Mac and I barely know how this thing works.  
> Just install Fink Commander and click on the svn module (then wait 3 
> hours while  builds it from source... macs are slooooow).
>
> Then I installed a Java GUI wrapper package, supervision, and it all 
> seems to work well.
>
> -dain
>
> On Friday, August 15, 2003, at 04:08 PM, Noel J. Bergman wrote:
>
>> Brian,
>>
>> I'm finding it interesting that no one else seems to be commenting 
>> about Mac
>> OS X support, but if there is someone around (Justin, perhaps?), who 
>> could
>> do a build for him, that could put an end to the discussion.
>>
>> I get the strong feeling that he's a Java IDE person and probably 
>> doesn't
>> know how to build a native code app.
>>
>> Eventually, it might be nice if subeclipse adopted Harald Wellmann's 
>> vision
>> to use the webdav transport, rather than having to have any native 
>> code on
>> the client.  Wouldn't bother me to see SVN-UP's native code approach
>> deprecated.
>>
>> 	--- Noel
>>
>>
>
> /*************************
>  * Dain Sundstrom
>  * Partner
>  * Core Developers Network
>  *************************/
>


Re: SVN on MacOS X

Posted by Dain Sundstrom <da...@coredevelopers.net>.
I got it working on my Mac and I barely know how this thing works.  
Just install Fink Commander and click on the svn module (then wait 3 
hours while  builds it from source... macs are slooooow).

Then I installed a Java GUI wrapper package, supervision, and it all 
seems to work well.

-dain

On Friday, August 15, 2003, at 04:08 PM, Noel J. Bergman wrote:

> Brian,
>
> I'm finding it interesting that no one else seems to be commenting 
> about Mac
> OS X support, but if there is someone around (Justin, perhaps?), who 
> could
> do a build for him, that could put an end to the discussion.
>
> I get the strong feeling that he's a Java IDE person and probably 
> doesn't
> know how to build a native code app.
>
> Eventually, it might be nice if subeclipse adopted Harald Wellmann's 
> vision
> to use the webdav transport, rather than having to have any native 
> code on
> the client.  Wouldn't bother me to see SVN-UP's native code approach
> deprecated.
>
> 	--- Noel
>
>

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/


RE: SVN on MacOS X

Posted by "Noel J. Bergman" <no...@devtech.com>.
Brian,

I'm finding it interesting that no one else seems to be commenting about Mac
OS X support, but if there is someone around (Justin, perhaps?), who could
do a build for him, that could put an end to the discussion.

I get the strong feeling that he's a Java IDE person and probably doesn't
know how to build a native code app.

Eventually, it might be nice if subeclipse adopted Harald Wellmann's vision
to use the webdav transport, rather than having to have any native code on
the client.  Wouldn't bother me to see SVN-UP's native code approach
deprecated.

	--- Noel


Re: SVN on MacOS X

Posted by Brian Behlendorf <br...@collab.net>.
As much as I hate to participate in this thread...

On Fri, 15 Aug 2003, Alex Blewitt wrote:
[...]
> 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 likewise, *you*'re asking everyone to suffer with an inferior solution
because you won't spend 10 minutes to read the man page for the command
line client or wait for the Eclipse plug-in to be compiled for you.  Fair
enough?

There is no conflict between using Eclipse and the command-line tool.
It's just not pretty pointy-and-clicky to update your sources or check in.

	Brian

Re: SVN on MacOS X

Posted by mk...@gmx.de.
> I don't know what the best choice is. It may well be that what's best 
> for the community isn't what I find the easiest solution, or what I'm 
> used to. However, I'm sure that I'd adapt should a move occur.
... and there is always a quiet crowd and me among them appreciating that
someone is challenging the issue of eclipse integration so thorough.  So I do
appreciate that it is heard that there is a demand for a 100% pure Java
svn-client.

On a sidebar. I do believe that the atomic check-ins and support for change
sets are important and I would fall back to the command line client to get
it, although I would habe appreciated a proper (=100% pure Java) plug-in for
Eclipse.

Cheers,
Mariano


Re: SVN on MacOS X

Posted by Alex Blewitt <Al...@ioshq.com>.
>> 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 suspect you're not winning hearts and minds with this attitude, 
> irregardless of smileys :) I'm sure a number of people here don't care 
> about what you can click on in Eclipse. IDE support wouldn't be my 
> first criterion for choosing source control, but telling me you don't 
> care isn't making me sympathetic.

True, could have used better wording.

>> 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.
>
> Me, me, me. Here, you're a member of a community first and foremost. 
> What do you think is the best choice for that community?

I don't know what the best choice is. It may well be that what's best 
for the community isn't what I find the easiest solution, or what I'm 
used to. However, I'm sure that I'd adapt should a move occur.

It's true that SVN has a number of advantages over CVS from 
manipulating the repository, of which I'm not doubting, but IMNSO the 
advantages aren't huge. As long as it can be used to check software in 
and out, then that provides pretty much what I'd expect from a source 
code control system.

>> And from what I see, the major disadvantage of CVS is that you loose 
>> changes during moves.
>
> This is a major disadvantage, particulary with Java and the idiom that 
> package structures must be reflected in directory strcuture (not 
> required, but that's how the tools are).

True, this is where CVS has fallen down. And if there were a decent fix 
for CVS, that'd be great. But there isn't, and SVN provides such 
benefits.

I'm also pretty sure that even with SVN tools available, should it 
replace CVS as the de-facto standard for source code then my favourite 
IDE will have them eventually as well :-)

>> 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.
>
> Like I said. Me. me, me.

Yes, I was expressing a personal opinion there. My personal opinion may 
not be the same as other people's, but when working in a group I know 
that it's not so much a matter of what everyone's individual opinions 
are, but a consensus opinion of the group. I also think it's a good 
idea to discuss differing opinions to find out where there are 
overlaps, and to re-evaluate one's own opinions. And lastly, I'm wrong 
more often than I'd care to admit and sometimes need a little 
convincing :-)

I wanted to raise the issues associated with moving from CVS to SVN in 
my experience; but not to say 'You cannot do this because ...' Clearly 
as a group a number of us want to move to SVN, and I was highlighting 
some of the potential issues to solve in that transition as/when it 
occurs. In particular, I wanted to express the potential problems that 
may occur when using an older version of the subversion client; 
although I've not used it, I was concerned to read about 
inter-operability with older/newer versions of the SVN software.

I also appreciate the other feedback people have given, and am 
currently downloading the svn-client on my system to play around with.

Alex.


Re: SVN on MacOS X

Posted by Bill de hÓra <bi...@dehora.net>.
Alex Blewitt wrote:


Hi Alex,

> 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 suspect you're not winning hearts and minds with this attitude, 
irregardless of smileys :) I'm sure a number of people here don't 
care about what you can click on in Eclipse. IDE support wouldn't be 
my first criterion for choosing source control, but telling me you 
don't care isn't making me sympathetic.


> 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 :-)

I was brought up to do both. It's not so hard.


> 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.

Me, me, me. Here, you're a member of a community first and foremost. 
What do you think is the best choice for that community?


> 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.

This is a major disadvantage, particulary with Java and the idiom 
that package structures must be reflected in directory strcuture 
(not required, but that's how the tools are).

The compelling argument not to worry about moving stuff around is 
having tests. The more tests you have the less history you need. 
Now, if you were to argue that we should use cvs because it's 
maximally in java developer tools...


> 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.

Like I said. Me. me, me.


> 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?

You get better granularity. With svn the commital is versioned. With 
CVS the files are versioned.

Bill de hÓra