cvs2svn: optimized tag creation #2

[Marko Macek <Ma...@gmx.net>]

Hi!

New patch, fixes a few issues detected so far. Not ready to be merged, 
but good enough for testing.

The next thing I am going to do is split up the ".commits" file 
generation for merging.

Please comment,

Changes:
 - Currently assumes that revision 1.1.1.1 is the same as 1.1 (cvs import
   was only used at initial repository creation). otherwise it's hard 
to convert
   any branches because cvs puts tags on 1.1.1.1 when file is not modiifed.
   This needs to be made optional.
 - Support for vendor branches has been disabled (due to above)
 - Nested branches are not yet tested
 - Timestamps not handled correctly yet
 - Some passes share data and can't be restarted
 - Doesn't yet break up commits if they are tagged differently
 - Handlings of tags on subset is not optimal (reverts to file by file copy
   even when subtree copy would be possible).

Regards,
Mark

Re: cvs2svn: optimized tag creation #2

[Karl Fogel <kf...@newton.ch.collab.net>]

Karl Fogel <kf...@newton.ch.collab.net> writes:
>    * 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.

Oh, I forgot: detecting the highest directory in a set of tagged or
branched files, and just copying that (then incorporating mods
beneath, if any).  That's kind of important too :-).

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: cvs2svn: optimized tag creation #2

[Karl Fogel <kf...@newton.ch.collab.net>]

Marko Macek <Ma...@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