Re: fun with Unix command lines

* About patch set manipulation and formats

        gstein: I've been thinking about this one off and on for the
                 past week. Some people have been desirous of moving
                 patch sets around, and having a well-defined format
                 to do all the work (tree changes, text changes, and
                 prop changes) would be very nice.

   my reply:

        Do you agree with these design goals, if they are easily
        achieved?:

                *) new patch set formats should be SCM-system
                   independent

z *) new patch generation and application tools
                   should work both on SCM working trees,
                   and on "ordinary" trees

                *) the new patch tools should handle exact and
                   inexact patching that includes tree rearrangements

        If you agree with those goals, then you should catch up with
        and join the effort that is part of the arch project to design
        such a patch set format and the basic patch set manipulation
        tools. We have a draft standard, and about 75% of a `mkpatch'
        implementation, but would welcome a genuine effort by the svn
        project to help with the tools and make sure they are useful
        to svn as well. Because considerable progress has already
        been made, I'm hopeful that helping out with this would not be
        a major time commitment for the svn team.

        If you do not agree with those goals for patch sets, I'd
        like to hear your explanation of why not.

* about atomicity

        gstein: Eh? Maybe I'm misunderstanding what you're saying,
                 but we version things as atomic sets of changes.

  my reply:

        Nevermind. It's a subtle point and a tangential one -- not
        worth trying to explain in detail right now.

* about distributed revision control

        gstein: We haven't applied any real thought to this problem,

                [...] although I do know that many people are
                interested in adding new types of distribution to
                SVN. Our use of HTTP should actually be quite helpful
                here, since it is possible to have an HTTP proxy that
                aggregates multiple repositories.

  my reply:

        If you are cooperative, we should discuss that. A proxy
        is a poor solution to the problem, but arch offers
        a simpler solution that can be adopted by other systems.

* about IDEs

        gstein: Once we actually ship an alpha/beta/final, then I
                think the IDE guys will start to incorporate SVN.

                Since we're library-based, and have bindings to
                multiple languages, I don't think there will be a
                large hurdle for IDE developers to integrate SVN.

  my reply:

        In context, that's a pretty funny reply.

        I tried to raise the subtle topic of the SCM feature set of
        next generation IDE tools and you replied that user interfaces
        are easier to write if they are linked against a C library. I
        think a lot of IDE designers must think like you ;-)

        Nevermind ... there's plenty to discuss re patch sets
        and distribution.

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 20 05:53:54 2002