geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hÓra <>
Subject Re: SVN on MacOS X
Date Mon, 18 Aug 2003 10:44:43 GMT
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

View raw message