[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 664 - trunk/subversion/bindings/ruby

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-12-19 23:04:32 CET

On Wed, Dec 19, 2001 at 11:58:26AM -0500, Greg Hudson wrote:
> On Tue, 2001-12-18 at 17:11, Greg Stein wrote:
> > That is (IMO) the absolute best way to move files and functions. Move first.
> > Commit. Then edit.
> >
> > When a move *and* changes are comingled, then it becomes darn near
> > impossible to figure out the actual changes made. By separating the change
> > step, it is possible to easily verify just those changes.
>
> Er, isn't that a failing on Subversion's part if it's true? It seems
> like, if the version control system is doing its job, then the right
> thing to do is move and edit at the same time, if that's what's required
> to go from working state to working state.
>
> (Or are you only talking about this as a temporary discipline for the
> current state of Subversion?)

Temporary relative to SVN. A must for when you need to use CVS.

When we can do a "diff" between a file and its predecessor (whether or not
that predecessor was located elsewhere), then we can ignore the
move/commit/edit/commit policy.

[ and arguably, we could ignore it today since the server records all the
  right info; but since a lot of review is based on commit emails and that
  isn't smart now... we *do* want to keep the policy for now ]

That said: I do have to disclaim that I hadn't really considered that we
could relax the policy at some point in the future. Your point is very
valid.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.