You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@galois.collab.net> on 2001/02/06 14:28:44 UTC
Re: Passing Targets into libsvn_client
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 <ke...@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--
Re: Passing Targets into libsvn_client
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
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 <kf...@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 <ke...@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--
Re: Passing Targets into libsvn_client
Posted by Karl Fogel <kf...@galois.collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> big deal. In the meantime (while you guys work on the repo), I will
> work on coming up with some decent implementations for the two functions
> Ben said we needed. If the interface to them has to change later, that
> shouldn't be too big a deal. But at least that way I can contribute
> something while you are all involved in the repository.
That would be awesome! Whatever the overall interface is, it's highly
likely that those two functions will be needed by it, so having them
done already would be wonderful.
Thanks,
-Karl
Re: Passing Targets into libsvn_client
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Feb 06, 2001 at 08:28:44AM -0600, Karl Fogel wrote:
> 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.
See comments below.
>
> 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.
No problem.
>
> (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 think the two of you should be involved as well.
>
> 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.
No problem about being hard nosed. The reason I'm not getting involved
in the repository stuff, is that I don't think I really understand
either subversion itself, or all of the issues involved as well as
any/all of you. The subversion code I have seen is probably some of
cleanest I have ever seen, which is one of the reasons I thought it
would be a good project to get involved with. Also with that in mind,
I don't want to be the one changing the interface for libsvn_client,
(at least without a little guidance from you guys). I feel I
understand the client stuff a little better, so that is where I am
focusing my attention. If you don't have time for feedback, that is no
big deal. In the meantime (while you guys work on the repo), I will
work on coming up with some decent implementations for the two functions
Ben said we needed. If the interface to them has to change later, that
shouldn't be too big a deal. But at least that way I can contribute
something while you are all involved in the repository.
>
> Subversion is *not* going to be one of them. :-)
_GOOD!!!!_
>
> -K
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net