[Lazarus] Development of other revision control

[Reinier Olislagers]

On 11-4-2012 20:54, Dawson wrote:
> yes, I know what Darius (et al.) have done in lazsvnpkg is a plugin, and
> I really think it will be helpful. In a message from Darius, I got the
> impression that his work is open source, and it certainly would be a
> great building block.
Looking at <lazarus>\components\lazsvnpkg, the .lpk file states it's
GPL, so yes, it's open source.

> Is there a reason not to make an API, as opposed to a plugin for
> Lazarus? I guess in some ways the plugin system is nice since it doesn't
> force anything on anyone, but on the other hand it seems odd to me that
> a developer wouldn't want access to a "source code management" system
> built into their IDE.
Don't know if we're talking at cross-purposes here...

First: a plugin and an API do not necessarily exclude each other.
They're independent concepts. A plugin can provide an API, and a plugin
can use an API. This may have been the cause of some confusion.

lazsvnpkg is a plugin in the sense that it is an optional component (a
package) in Lazarus.

IIUC, the SVN package (plugin) lets people use SVN with their Lazarus
project, e.g. check in and out his project code from within the IDE.
Yes, a developer might be interested in doing more with SVN, but
managing his project source code in SVN would be the most important
thing, right? IIUC, that's already possible with the SVN component.
If I read your mails right, you're actually interested in this part, right?

If you want to expose SVN functionality further, and if there's any
need, adding an API to the component/plugin would be possible. It's just
that I don't directly see the use for that - perhaps for other IDE
component writers?
If you mean what Sven deduced in his other mail: provide an API for
revision control systems at a lower level that an IDE plugin/package can
use... that's a good idea, that's certainly already partly executed by
separating the lazsvnpkg SVN functionality in a separate unit.
I'd suggest having a look at class I sent you a link for earlier to see
some ideas for extensions (i.e. getting current local revision number,
combining SVN checkout and update) that could be possible.

I'd suggest trying to work with lazsvnpkg to manage your projects source
code in subversion; if you need another revision control system, adding
support to the backend would seem sensible - with e.g. a common base
class that represents basic revision control functionality (local
directory, remote URL/directory, check in, check out, merge, resolve
conflict) and is your API. (That's what I called a port)

And, as mentioned, if you need help with a mercurial version, I'd be
interested in helping ;)

Regards,
Reinier