You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/12/18 22:11:28 UTC
Re: svn commit: rev 664 - trunk/subversion/bindings/ruby
On Tue, Dec 18, 2001 at 04:50:11AM -0600, yoshiki@tigris.org wrote:
> Author: yoshiki
> Date: 2001-12-18 10:50 GMT
> New Revision: 664
>
> Added:
> trunk/subversion/bindings/ruby/repos.c
> Modified:
> trunk/subversion/bindings/ruby/fs.c
> trunk/subversion/bindings/ruby/svn_ruby.c
> trunk/subversion/bindings/ruby/svn_ruby.h
> Log:
> Move svn_repos stuff to new file, repos.h. Note that this commit only
> moves contents so this file does not compile yet.
Yay!
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.
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
Re: svn commit: rev 664 - trunk/subversion/bindings/ruby
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Yay!
>
> 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.
Greg, I'm totally sold on this too now. You want to put something to
this effect in HACKING? (I have to run right now, otherwise I'd do
it).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 664 - trunk/subversion/bindings/ruby
Posted by Greg Stein <gs...@lyra.org>.
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
Re: svn commit: rev 664 - trunk/subversion/bindings/ruby
Posted by Greg Hudson <gh...@MIT.EDU>.
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?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org