My short take on Karl's comments...
The client-side of subversion is just at that "teetering point" right
now where it's about to *explode* into a universe of functionality.
Its growth rate will be phenomenal. The problem is that we don't have
the cycles to spend managing that growth -- if volunteers start
contributing all sorts of fixes and features, we'll have no choice but
to become deeply involved... which we *want*, just not *yet*!
So, to all our volunteers, we beg: if you want to speed subversion's
progress, *please* help us with the filesystem work! We promise that
we'll come back to the client-side again RSN. :)
Karl Fogel <kfogel@galois.collab.net> writes:
> The things you mention (passing the targets list down into
> libsvn_client and possibly beyond, fixing up invocation syntaxes so
> that committing directories works right, etc) are things we will need
> to do soon. They will affect the libsvn_client interface, and likely
> cause a few changes in libsvn_wc as well, though nothing major. The
> main thing is to sit down and spend some thought on making a good
> interface at the libsvn_client level, then code it up all at once --
> changing the client code, the libsvn_client code, and libsvn_wc
> together so we can see & deal with the effects of the change in one
> fell swoop.
>
> This is a one or two-day deal at the most, it's not going to be a
> showstopper. However, we *have* to focus on the repository right now.
> I know it's tempting to just work more on what's already working, but
> the fact is the repository is such an overriding priority at this
> point that we shouldn't be devoting cycles to anything else.
>
> (I do appreciate that you're doing client work, and that you need
> interfaces to go any further. I guess I'm just asking if you can hold
> out for a while longer, because it's very important to concentrate
> exclusively on getting basic repository functionality working right
> now. If coming up with the libsvn_client interfaces were more
> parallelizable, I'd say just go for it on your own, but in truth, I
> must admit that Ben and I will probably have to be -- and want to be
> -- very involved in the process.)
>
> I know I'm being a bit hard-nosed about this. Please remember what
> gets me up in the morning: the Net is positively littered with free
> software projects that never got completed. In fact, the majority end
> up that way. One common reason for not finishing is losing focus --
> making some initial progress, and then perfecting what one already has
> instead of tackling the hard stuff.
>
> Subversion is *not* going to be one of them. :-)
>
> -K
>
> Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> > --AhhlLboLdkugWU4S
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Tue, Feb 06, 2001 at 09:31:32AM -0600, Ben Collins-Sussman wrote:
> > >=20
> > > The "targets" problem is stack is a bit more complicated; you're on
> > > the right track.
> > >=20
> > > A number of svn subcommands *should* take lists of targets. But they
> > > don't right now, as you noticed.
> > >=20
> > > What we need are some standardized routines which will:
> > >=20
> > > * given a list of targets, "condense" the list, i.e. remove any item
> > > from the list which is contained within another item
> > >=20
> > > * given a condensed list of targets, calculate the longest common
> > > ancestor path. This would be the path where we would start a
> > > replace_root() (or begin_edit(), whatever we call it now).
> > >=20
> > > If you'd like to implement these things, it would be great! We've put
> > > them off until the filesystem is working.
> >
> > Will do, but a couple of points. I was thinking of using
> > svn_path_get_longest_ancestor for getting the longest common ancestor
> > path in a list of condensed targets. The problem with this is that
> > svn_path_get_longest_ancestor will not handle if one path is given
> > relatively, and one is given absolutely. Perhaps we should change
> > svn_path_canonicalize to convert paths to absolute? Second, what
> > happens if the longest common ancestor path is not part of the WC.
> > (I.e) two targets in two different W.C's?
> >
> > Also, just in case you missed it, did you have any feedback on the
> > only committing directories(i.e. not files)?
> >
> > > snip my stuff=20
> >
> > --=20
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Kevin Pilch-Bisson
> > kevin@pilch-bisson.net
> > http://www.pilch-bisson.net
> > PGP Public Key At http://pgp.pilch-bisson.net
> >
> > --AhhlLboLdkugWU4S
> > Content-Type: application/pgp-signature
> > Content-Disposition: inline
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.4 (GNU/Linux)
> > Comment: For info see http://www.gnupg.org
> >
> > iD8DBQE6gCC4gJlk/lQdbnARAktbAJ49psjzx/thcmts75GypZOM0PMUugCeOSz3
> > PpvGmOpreIZ8UbrLKs1rtuk=
> > =BEID
> > -----END PGP SIGNATURE-----
> >
> > --AhhlLboLdkugWU4S--
Received on Sat Oct 21 14:36:21 2006