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?
Because:
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.
Thanks,
Stefan
---------------------------------------------------------------------
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