Marko Macek <Marko.Macek@gmx.net> writes:
> New patch, fixes a few issues detected so far. Not ready to be merged,
> but good enough for testing.
What does this mean, exactly? :-)
If it's not ready to be merged, whatever testing we do now will merely
have to be done later when we have the *actual* change in hand.
Yes, it's true that sometimes we test a general approach to see how it
affects performance (for example, turning off fsync'ing in bdbd), and
then complete the formalities once we know the approach looks
promising. But here, you haven't stated what the goal is, so we don't
know what we're testing for. If we don't know what we're supposed to
be approaching, we can't say whether an approach looks promising :-).
> The next thing I am going to do is split up the ".commits" file
> generation for merging.
Is that be a tweak to this change, or a new unrelated change, or... ?
Please don't misunderstand -- I'm *very* glad you're working on
cvs2svn. But you have to realize that what seems obvious to you, as
you work on it, may not be obvious to the rest of us. For
collaborative development to work, we need to devote a lot of energy
just to making changes easily comprehensible to everyone else:
- Clearly stating the goal and overall effect of each change
- Making small and independent changes, where possible
- Writing clear and complete log messages (see HACKING)
Right now, it's hard to incorporate this patch, because I don't know
what problem it's trying to solve. Perhaps if you start out by
describing the deficiencies you see in the current cvs2svn, and your
plan to solve them, that would be a good starting place.
Here are the main things I'm working on right now (and I'd be very
happy to solve them by applying patches from you!):
* branches / tags need to be handled in a more natural way. Right
now, it looks like we're doing an fs_copy() every time there's a
commit on a branch, instead of just copying when the branch is
created and doing regular commits after that. I could be wrong
though; my understanding of that loop is still incomplete.
* Holding the whole resync file in memory is bad; not sure yet how
to solve this.
* The code is not very well documented. Many methods and classes
have no doc string, or just a one line informal description
instead of a true API description, so it's hard to figure out
what's going on.
I'm sure there are problems besides the above three, those just seem
like the biggest right now. If your priorities are different, that
probably means there's something important I don't know about, so
let's talk :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 22:21:44 2003