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

Re: Moving bindings into a separate project.

From: <kfogel_at_collab.net>
Date: 2004-02-21 07:06:17 CET

Justin Erenkrantz <justin@erenkrantz.com> writes:
> I have an issue with moving the development of the bindings out of
> dev@svn, but I definitely don't have an issue with the bindings being
> separately released though from the core. However, the bindings are
> *extremely* tied into the core - in a way that no other SVN
> applications would be. In the long run, I think it'll be beneficial
> to have them joined together not artificially separated.

The main thing I'm talking about, in addition to the bindings being
released in a separate tarball(s), is that they also get moved out of
the Subversion repository. That is, I think they should be treated
like any other third-party project. Having reviewed emails & thought
a bit more, I also think they should have their own mailing lists.

So yes, this proposal is for a complete decoupling.

In practical terms, I don't see why the fact that the bindings are so
tied to the core APIs makes it somehow necessary for them to live in
the same tree. If someone could explain why it matters, with concrete
examples, that would help. So far, the best argument I've heard (in
irc) is that someone can commit a core change and its corresponding
bindings change in a single revision. Well, yippee! :-) Not only is
this not a terribly compelling advantage, the truth is it almost never
happens right now anyway, so we wouldn't be losing it.

When I think of exactly how the bindings development process would
work as a separate project, I don't see how them being in a different
tree would interfere with that process.

So the argument that "the bindings are special" does not convince, at
least not without further elaboration.

> I think cvs2svn can easily be split off as there is a clear
> demarcation line, but I just don't see the same rationale for the
> bindings.

Here are some rationales:

   * Bindings commits show up in the regular Subversion log history.
     This is noise. We have to skip over it when generating the
     CHANGES file -- or, worse, pay attention to it. IOW, there's one
     more burden for people browsing logs, for whatever reason.

   * Bindings commits show up in the Subversion tree commit emails.

   * Bindings votes occupy a large portion of the activity in STATUS
     files right now. One might respond: "Yes, but we're proposing
     that they be released separately, so that won't be a factor."
     Sure, but read on...

   * It's confusing to have bindings in the regular tree yet not
     include them in packaged SVN distributions. It implies a greater
     difference than currently exists between tarballs and working
     copy builds, because someone building from a working copy faces
     the question: do I use the bindings here, or get the released
     bindings package? Theoretically, you should use the bindings
     right there in the tree, because they'd be most up-to-date for
     that code. Yet this is the opposite of the way the user should
     behave for tarball builds, where the bindings won't even be
     present in the tree. Confusion reigns.

     The more simple and comprehensible solution is: if something that
     is used with Subversion is nevertheless not distributed with
     Subversion, that that something shouldn't live in Subversion's
     tree either.

   * We tried once keeping other projects in the same repository as
     Subversion (the old clients/ dir). We hated it. We stopped.
     "Those who forget history are condenmed to repeat it." :-)

   * Third-party clients are intimately tied to our APIs too, and have
     often been bitten by API changes. Yet they've managed just fine.

Please note that the issue is not the importance of the bindings.
They're very important, but that's not relevant here. The more
popular third-party clients are also very important, but we don't keep
those in our tree.

The important factor, IMHO, is that the bindings developers are, by
and large, different from the C code developers. *Most* discussions
the C developers have are not relevant for the bindings developers,
and *most* discussions the bindings developers have are not even read
by many C developers. (Sure, there's some crossover, I'm just talking
about the broad view here.)

What keeps the bindings up-to-date is not their proximity on disk to
the core API files. It's humans -- humans building and using the
bindings, and discovering problems. Humans will be no more nor less
able to do this with them as a separate project. The difference is
that when people *do* discover problems, they will have a more focused
forum for solving them, and not distract others who for the most can't
help them anyway.

As you can tell, I feel pretty strongly about this. I really, really
want those bindings to have the status of a full, separate project,
with all the rights, privileges, and responsibilities thereunto
appertaining :-).

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 21 08:08:57 2004

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.