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