[subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)

[Alex Karasulu <ao...@bellsouth.net>]

Hi,

Sorry to get into this one late.  Had too though since I'm one of those 
directory folks :-).

> From: Noel J. Bergman [mailto:noel@devtech.com]
> Good but out of date.  The subclipse web page appears to be lagging behind
> its code:
> http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=2240

I'm an eclipse user myself and really loved the integrated CVS features.  
However I had to give up on an eclipse plugin for subversion but am anxious 
to start using this new version.  I gave up on using an IDE all together for
my VCS activities because of a switch to subversion.

I use the command line svn program with cygwin and that was hard since 
the CVS plugin is so nice.  Unfortunately I still have to develop on 
Windows XP most of the time because of corporate requirements.  It's 
definitely a trade off to use the CL svn program instead of the eclipse
plugin for CVS but I think I made the right choice.  Anyway it looks 
like I can resume using eclipse for VCS ops against subversion now!

> > How often are we going to be using the unique administration
> > features in Subversion as compared to the day-to-day usage
> > features available in the CVS plugin.
> 
> One example would be every time you refactor, but as a general
> observation,
> I'll guess that the Directory project is using the unique features of
> Subversion every few days at least.


Subversion for eXtreme Refactoring
==================================

And we could not do without these features.  It's more than simple 
administration features though.  Let me see if I can explain the 
subtle changes to our development style these features have had.

Subversion affords us a more liberty.  Besides the obvious renaming and 
deleting of files and directories without the loss of history etcetera, 
we find that our development style can be geared towards XP.  These 
features are changing our outlook.  We are no longer worried about 
chewing up a repository to re-factor on a whim.  I personally have 
re-factored conservatively on CVS because there was no way to easy 
way to cleanup the consequences afterwards: loss of history and empty
directories.  But now there are no inhibitions with subversion so we're
free to be liberal with re-factoring - it's the way we code.  Bang 
something rough out and then gradually reshape it as we discover new 
things along the way.  Plus the ease of branching by just copying
directories and merging them makes large re-factoring efforts without
disrupting development a breeze.  These features have for these reasons
improved our development style and the quality of our code.  Subversion 
goes hand in hand with XP!  It's the preferred VCS for extreme 
programmers!

Going back to CVS is not an option for me after tasting development 
using subversion: it would mean going backwards.  The best description 
I can give of the having to use CVS after using subversion is when I 
have to use dial up rather than high speed internet access.  It's just
frustrating.

Subversion is the future that fits the latest paradigms in software
development.  I cannot stress the importance of the positive effects
it will have for development here at the ASF not to mention for 
infrastructure.  And ultimately the transition will have to happen 
at some point.

BTW in the past I have been a CVS consult and lived and swore by it 
since it put food on the table.  I cannot overstate how emphatic
I have been regarding CVS.  It was a religion for me.  Now after years
of using CVS, I swear by subversion and that's got to be worth 
something when said by a CVS diehard.

Regards,
Alex







---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Fwd: [subversion] Subversion for eXtreme Refactoring

[Ted Husted <hu...@apache.org>]

So, I'm sure many of us saw this on the Jakarta Commons DEV list, but I thought it might be worth bringing up in the context of our refactoring discussions. 

I have no strong feelings myself. Though, I'm sure we all realize that eventually we'll be using Subversion. 

To date, I've never done more with CVS than what I needed to get through the day. But I think that might change once I end up working on a project that uses Subversion. :)

For anyone wondering what is all about, see <http://subversion.tigris.org/> and <http://svnbook.red-bean.com/>.

-Ted.

--- Original Message ---
From: "Alex Karasulu" <ao...@bellsouth.net>
To: 'Jakarta Commons Developers List' <co...@jakarta.apache.org> 
Sent: Sat, 27 Mar 2004 14:54:36 -0500
Subject: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)

> Subversion for eXtreme Refactoring
> ==================================
>
> Subversion affords us a more liberty.  Besides the obvious renaming
> and deleting of files and directories without the loss of history
> etcetera, we find that our development style can be geared towards
> XP.  These features are changing our outlook.  We are no longer
> worried about chewing up a repository to re-factor on a whim.  I
> personally have re-factored conservatively on CVS because there was
> no way to easy way to cleanup the consequences afterwards: loss of
> history and empty directories.  But now there are no inhibitions
> with subversion so we're free to be liberal with re-factoring -
> it's the way we code.  Bang something rough out and then gradually
> reshape it as we discover new things along the way.  Plus the ease
> of branching by just copying directories and merging them makes
> large re-factoring efforts without disrupting development a breeze.
>  These features have for these reasons improved our development
> style and the quality of our code.  Subversion goes hand in hand
> with XP!  It's the preferred VCS for extreme programmers!
>
> Going back to CVS is not an option for me after tasting development
> using subversion: it would mean going backwards.  The best
> description I can give of the having to use CVS after using
> subversion is when I have to use dial up rather than high speed
> internet access.  It's just frustrating.
>
> Subversion is the future that fits the latest paradigms in software
> development.  I cannot stress the importance of the positive
> effects it will have for development here at the ASF not to mention
> for infrastructure.  And ultimately the transition will have to
> happen at some point.
>
> BTW in the past I have been a CVS consult and lived and swore by it
> since it put food on the table.  I cannot overstate how emphatic I
> have been regarding CVS.  It was a religion for me.  Now after
> years of using CVS, I swear by subversion and that's got to be
> worth something when said by a CVS diehard.
>
> Regards,
> Alex
>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: commons-dev-
> unsubscribe@jakarta.apache.org For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

RE: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)

[Alex Karasulu <ao...@bellsouth.net>]

> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sorry to get into this one late.  Had too though since I'm one of those
> > directory folks :-).
> 
> I'm finally finding that I can get svn installed on suse and os x [it's
> not without issue] and am looking forward to migrating to svn over the
> next year in all my endeavours.

I know you had a few bumps on your way, I'm glad to hear things are 
progressing.

> > Subversion affords us a more liberty.  Besides the obvious renaming and
> > deleting of files and directories without the loss of history etcetera,
> 
> Never really had that much pain doing this on the CVS server. One of the
> pluses CVS had was that the system was easily understandable and if CVS
> did not support a feature, you could often use something like perl to gain
> said feature. CVS hackery was effectively an easy way to extend CVS.
> Lookinjg at the SVN repo, it looks a lot more complicated and will require
> far more in the way of effort to change, ie) writing [I assume] berkely db
> client code.

CVS is really great if you have access to the repository and don't make 
mistakes.  However CVS came together out of necessity as some project 
level meaning was to be given to a set of RCS files.  Basically it's a 
kludge although not a bad one.  Subversion is a complete rewrite and 
has some subtle yet major differences.  However I do feel safer knowing 
that there is less 'hackery' now while preserving the ability to extend 
subversion.  

In the past, I made a living off of other people's ignorance when it came 
to administering CVS and hacking around its flaws.  Don't get me wrong 
I'm glad to have profited but would rather have worked on creating 
something new rather than working around a flawed piece of software.  
Rather than spend time knowing the internals of a VCS to make up for 
its shortcomings, I'd rather put that time towards using it to its 
fullest extent and improve the development lifecycle.

<snip/>

> > things along the way.  Plus the ease of branching by just copying
> > directories and merging them makes large re-factoring efforts without
> > disrupting development a breeze.  These features have for these reasons
> 
> Branching and tagging in svn confuse me. People talk about them being
> easier, but the difficulty of such things in CVS is not the action, but
> the management of multiple branches of code. All i see in SVN so far is a
> different way [which may be faster on the server, but who cares unless

Yes svn could be difficult because it requires breaking old CVS habits.  The
fact that a revision# = tag# in subversion may confuse the need for branches
in the traditional CVS sense.  Branching just becomes a very efficient copy
operation.  IMHO this is an improvement.

> there are lots of binary files] and not an improved way. Is there any
> concept of live vs dead branches? Any way to implement naming conventions?
> R/W setting of branches?

Subversion like all good systems leaves the interpretation (meaning) of the
state of a branch up to you but gives you the tools you need to manage it.
The tools here are user definable attributes.  So when you want to devise a
scheme for tracking the state of your branch you have first class support
from subversion to do so.  CVS never gave you this although you could mimic
it with workarounds.

> Also, branches seem to have less in the way of support as you now have to
> come up with your own filing hierarchy to contain them. While the new SVN
> structure seems simpler, which might lead to a more easily implemented
> powerful system, there's nothing to crow about yet.

You're right that it will take time before the entire community begins to
see the true value of svn.  

> > Going back to CVS is not an option for me after tasting development
> > using subversion: it would mean going backwards.  The best description
> > I can give of the having to use CVS after using subversion is when I
> > have to use dial up rather than high speed internet access.  It's just
> > frustrating.
> 
> Your anology reminds me of something that frustrated me. Subversion
> apparantly has a different commit method, it sends patches up and not full
> files [?]. This makes for less bandwidth usage. Anyways, the bit that
> frustrates me is the SVN seems unable to work with basic WebDAV clients,
> which I think quite a few of us assumed when it talked about using WebDAV
> [yeah, I don't grokk DAV]. Anyway, this means that I can't mount a
> subversion repo as a virtual drive and commit by simply copying a new
> version of a file in, or editing it, and I can't use a tool like
> Dreamweaver to change it. It does work in a read-only way though, just
> errors on commits.

Yeah I was a little disappointed by not having these features you mention
also.  I think they are due to only a partial implementation of DeltaV but
others would know about this better thank I.  Regardless it would be sweet
to have the write half also because then everything is a standard wrt the
comm. protocol portion of svn.

> > Subversion is the future that fits the latest paradigms in software
> > development.  I cannot stress the importance of the positive effects
> > it will have for development here at the ASF not to mention for
> > infrastructure.  And ultimately the transition will have to happen
> > at some point.
> 
> From what I understand, SVN is written by the maintainers of CVS? Which
> implies that CVS is dead and SVN is basically a very non-backwards
> compatible CVS-2. That's the main reason to move for me.

That's also another reason as well.  I only think of SVN as a CVS
replacement about 40% of the time now.  It might have been greater when I
started working with it and said 'Oh it has all the cvs commands I used
before'.  Then as you begin to play and experiment with its features you
realize this road starts where CVS left off but can take you far far away.

Also the assignment of global repository version numbers for each change is
truly awesome.  I really don't need to tag anything anymore.  CVS assigns a
revision per file with tags to track them.  SVN uses a global repository
version number for changes.  This IMO is the biggest difference and is a
paradigm shift in the way a repository is thought of in the user's mind.  It
makes SVN much more than CVS-2.  Also a single unique version number for an
entire change transaction makes it really easy to reference fixes in JIRA or
any other issue tracking tool.  

> So far, the only improvements I've found are the ability to move files, a
> slightly nicer set of messages when committing and 'svn status' replacing
> 'cvs -nq update'. A lot of it feels more generic, which can be a good
> thing.
> 
> > BTW in the past I have been a CVS consult and lived and swore by it
> > since it put food on the table.  I cannot overstate how emphatic
> > I have been regarding CVS.  It was a religion for me.  Now after years
> > of using CVS, I swear by subversion and that's got to be worth
> > something when said by a CVS diehard.
> 
> I suspect complaints like "but it's too complicated", "it's not well
> supported" etc were heard by RCS die-hards when CVS came out too :)

Yeah support is less than what there is for CVS but in time this will
change.  It will change very rapidly too.  I think SVN fixes all of the
complaints users have had with CVS and for that reason it will be adopted
much more readily by people who had avoided CVS for those reasons.  In the
end, SVN should have a bigger following with much more support.  You
obviously already see that.

> I expect to not be using CVS in a year [home,apache,osjava,work], but it's
> going to take a good chunk of time to transform my cvs-admin knowledge
> over to svn.

Great then we can help each other along as we learn the ins and outs of
subversion.  I'm sure we'll be finding ways to use SVN in ways the authors
never conceived.  I'd like to hear the experiences of others as they too
make the move to SVN, learn how to use it and extend it in novel ways.

Alex





---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)

["Noel J. Bergman" <no...@devtech.com>]

> CVS hackery was effectively an easy way to extend CVS.

You may be a CVS guru, but do you really want to know how many times someone
has crapped CVS by playing around with things they don't understand?  Not
directly related, perhaps, but we had to fix a problem just this past week
where someone started using the live CVS repository on minotaur for their
personal workspace.

> Lookinjg at the SVN repo, it looks a lot more complicated and will require
> far more in the way of effort to change, ie) writing [I assume] berkely db
> client code.

Subversion has several well-defined interfaces, including WebDAV/DeltaV.

> Branching and tagging in svn confuse me.

Branches and tags are just lightweight copies.  A branch and a tag are the
same thing.  Placing them under branches/ and tags/ are just conventions.
To quote the Subversion book:

  "Subversion has no internal concept of a branch-only copies.
   When you copy a directory, the resulting directory is only
   a "branch" because you attach that meaning to it. You may
   think of the directory differently, or treat it differently,
   but to Subversion it's just an ordinary directory that
   happens to have been created by copying."

To "tag" something, you make a copy of it.  If you started editing the copy
it is a "branch", otherwise it is a "tag".  The important thing is that you
used Subversion to copy, so that it tracks the file identity.

The book, http://svnbook.red-bean.com/, should answer many of your
questions.

> R/W setting of branches?

We use mod_authz_svn for that purpose.

> the bit that frustrates me is the SVN seems unable to work with
> basic WebDAV clients, which I think quite a few of us assumed
> when it talked about using WebDAV

> I can't mount a subversion repo as a virtual drive and commit
> by simply copying a new version of a file in

There is support for auto-versioning, but we may have it disabled.  One of
the issues with auto-versioning is that you don't get commit comments.  I
believe that DeltaV is the way out of it, but you would have to talk with
the Subversion folks.  In any event, it is a current limitation, not a
design point.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [subversion] Subversion for eXtreme Refactoring ( was [HiveMind] Discuss: CVS or Subversion?)

[Henri Yandell <ba...@generationjava.com>]

On Sat, 27 Mar 2004, Alex Karasulu wrote:

> Hi,
>
> Sorry to get into this one late.  Had too though since I'm one of those
> directory folks :-).

I'm finally finding that I can get svn installed on suse and os x [it's
not without issue] and am looking forward to migrating to svn over the
next year in all my endeavours.

Some questions on the below though:

> Subversion for eXtreme Refactoring
> ==================================
>
> Subversion affords us a more liberty.  Besides the obvious renaming and
> deleting of files and directories without the loss of history etcetera,

Never really had that much pain doing this on the CVS server. One of the
pluses CVS had was that the system was easily understandable and if CVS
did not support a feature, you could often use something like perl to gain
said feature. CVS hackery was effectively an easy way to extend CVS.
Lookinjg at the SVN repo, it looks a lot more complicated and will require
far more in the way of effort to change, ie) writing [I assume] berkely db
client code.

> we find that our development style can be geared towards XP.  These
> features are changing our outlook.  We are no longer worried about
> chewing up a repository to re-factor on a whim.  I personally have
> re-factored conservatively on CVS because there was no way to easy
> way to cleanup the consequences afterwards: loss of history and empty
> directories.  But now there are no inhibitions with subversion so we're
> free to be liberal with re-factoring - it's the way we code.  Bang
> something rough out and then gradually reshape it as we discover new
> things along the way.  Plus the ease of branching by just copying
> directories and merging them makes large re-factoring efforts without
> disrupting development a breeze.  These features have for these reasons

Branching and tagging in svn confuse me. People talk about them being
easier, but the difficulty of such things in CVS is not the action, but
the management of multiple branches of code. All i see in SVN so far is a
different way [which may be faster on the server, but who cares unless
there are lots of binary files] and not an improved way. Is there any
concept of live vs dead branches? Any way to implement naming conventions?
R/W setting of branches?

Also, branches seem to have less in the way of support as you now have to
come up with your own filing hierarchy to contain them. While the new SVN
structure seems simpler, which might lead to a more easily implemented
powerful system, there's nothing to crow about yet.

> Going back to CVS is not an option for me after tasting development
> using subversion: it would mean going backwards.  The best description
> I can give of the having to use CVS after using subversion is when I
> have to use dial up rather than high speed internet access.  It's just
> frustrating.

Your anology reminds me of something that frustrated me. Subversion
apparantly has a different commit method, it sends patches up and not full
files [?]. This makes for less bandwidth usage. Anyways, the bit that
frustrates me is the SVN seems unable to work with basic WebDAV clients,
which I think quite a few of us assumed when it talked about using WebDAV
[yeah, I don't grokk DAV]. Anyway, this means that I can't mount a
subversion repo as a virtual drive and commit by simply copying a new
version of a file in, or editing it, and I can't use a tool like
Dreamweaver to change it. It does work in a read-only way though, just
errors on commits.

> Subversion is the future that fits the latest paradigms in software
> development.  I cannot stress the importance of the positive effects
> it will have for development here at the ASF not to mention for
> infrastructure.  And ultimately the transition will have to happen
> at some point.

>From what I understand, SVN is written by the maintainers of CVS? Which
implies that CVS is dead and SVN is basically a very non-backwards
compatible CVS-2. That's the main reason to move for me.

So far, the only improvements I've found are the ability to move files, a
slightly nicer set of messages when committing and 'svn status' replacing
'cvs -nq update'. A lot of it feels more generic, which can be a good
thing.

> BTW in the past I have been a CVS consult and lived and swore by it
> since it put food on the table.  I cannot overstate how emphatic
> I have been regarding CVS.  It was a religion for me.  Now after years
> of using CVS, I swear by subversion and that's got to be worth
> something when said by a CVS diehard.

I suspect complaints like "but it's too complicated", "it's not well
supported" etc were heard by RCS die-hards when CVS came out too :)

I expect to not be using CVS in a year [home,apache,osjava,work], but it's
going to take a good chunk of time to transform my cvs-admin knowledge
over to svn.

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org