On Fri, Aug 08, 2008 at 08:56:07AM -0500, kmradke_at_rockwellcollins.com wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> wrote on 08/08/2008 08:27:20 AM:
> [snip]
>
> > So, I am (and have been) struggling very hard to see a meaningful
> difference
> > between what is being proposed here, and what we did in the past. I see
>
> > people with direct experience in dealing with vendor releases speaking
> in
> > favor of what Mark and Senthil are trying to do, and I see people citing
>
> > zero relevant experience with the same speaking against it.
>
> If the changes are server only changes, I think confusion will be minimal.
>
> If the changes are client libs as well, things will get a lot more
> confusing.
The changes do indeed affect client libraries.
> I.E. what should TortoiseSVN link against?
That is their decision. I think this is essentially the same
story, just a different vendor.
> The Collabnet beta binaries were nice, but they were in fact just
> early releases, not containing features that potentially won't
> be merged into a future release. (I have no reason to believe
> they wouldn't be merged eventually though...)
There seems to be a big misunderstanding here:
AFAIK, CollabNet is _not_ planning to add features which are not
in trunk already. No one has ever said that this was intended.
So, yes, the features will be present in a future release, namely 1.6.
They are already in trunk, and essentially complete (i.e. mainly need
bugfixing). The fact that they are in trunk today means that the
community has accepted them. It would not make sense to exclude
them from the next release.
> There is already a fair amount of confusion in the user community
> that are considering the Collabnet binaries "official". (Based
> on the complaints about requiring registration).
It's more of a de-facto standard than an "official" standard.
This is an unrelated problem, I believe. It seems to be a
combination of the facts that not many people apart from CollabNet
provide binaries for Windows, and that people using Windows seem
to depend heavily on binaries because they don't want to, or
cannot, compile from source.
The problem does not affect users of UNIX-like systems much, for example.
These systems usually provide their own packages which don't contain
CollabNet's binaries. I never had to depend on binaries provided by
CollabNet in my entire life.
> Would Collabnet now provide "unmodified" binary releases along
> with their "enhanced" binary releases? Only their "enhanced"
> binaries? Nothing at all?
I'm afraid that's entirely up to them.
> I guess I'd like more details on when Collabnet wants/needs
> a release with new functionality. I'm making an assumption
> that the changes they want/need require API and or WC format
> changes, which is why 1.6 is being discussed...
The changes under discussion are related to client-side authentication
features, and do not require WC format changes.
Some new client-side public API has been added. But as usual,
the APIs are backward-compatible, so if a client compiled against
stock 1.5 libraries does not run with the modified ones, there's
a bug.
The most user-visible change is that the client configuration files
understand some new options. Old clients will just ignore these
options. Subversion 1.6 will be able to use them.
Hope this clarifies things,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-08 16:47:14 CEST