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

To Greg Stein (was: Re: svn commit: r32515 - trunk/subversion/libsvn_wc)

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 18 Aug 2008 10:11:05 +0200

On Sun, Aug 17, 2008 at 03:39:49PM -0700, gstein_at_tigris.org wrote:
> Author: gstein
> Date: Sun Aug 17 15:39:48 2008
> New Revision: 32515
> Log:
> Another round of exploration on the API for the metadata/text-base
> interface. There are three main sections now: manipulate the BASE tree,
> perform mutation operations on the BASE/WORKING trees, and read state from
> the BASE/WORKING trees.

I'm wondering: Shouldn't these commits go to a feature branch?


a) It will make the end result of your effort much easier to review.
   People can just diff the feature branch against trunk and see
   the end result of all your changes in one batch.

b) Potential problems caused by changes entering trunk affects *all*
   feature branches, because they regularly sync with trunk.

   In the long run, committing many small work-in-progress
   changes to trunk could mean that conflict resolution might need
   to be done several times on several of our branches (as soon
   as you start changing existing files, that is).

   This gets even worse in case files are deleted/moved around etc,
   which is something you may want to do while reworking libsvn_wc.
   Because then we can run into tree conflicts which are sometimes
   non-obvious, and merging trunk to feature branches to keep them
   in sync gets even harder (unless we like merge errors).

   For this reason it's better to merge the known-working end
   result into trunk and let other feature branches do catch-up
   work with your feature just once.

c) A branch can optionally give the work you are currently doing a scope.

   That is, you could name the branch "branches/wc-ng" (scope: everything
   under the sun people might want to have in wc-ng) or e.g.
   "branches/centralised-wc-meta-data" (scope: implement centralised
   meta-data storage for libsvn_wc).

   I guess taking multiple smallish steps towards the ultimate goal
   of a "new working copy" might help people who would like to get
   involved at different stages (e.g. me, and I bet a bunch of others
   are also interested).

   For example, as I already pointed out we *need* to make the new
   working copy smarter about tree conflicts. If we don't do that
   eventually, we totally lose, and can scrap this whole project, and
   spend our time on a different version control system, IMHO.
   This is really important to me.

   However, doing this is a separate problem from changing meta data
   location. So these can be done in two separate steps, on two separate
   branches, perhaps. There may be more bite-sized tasks like these
   which ultimately lead up to the next-generation working copy.

   Since you're currently putting more brain power into this than anyone
   else here, could you identify and describe some of the subtasks you're
   currently seeing which might warrant their own feature branches, if any?

Just some thoughts.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-18 10:10:21 CEST

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.