[Lazarus] Re: Development of other revision control

[Dawson]

Hi ... a few more replies ...

On 12/04/12 1:06 PM,

Marcus wrote ...
>>
>> I for my part prefer to use a VCS that comes with its own GUI, like Git or
>> SVN (TortoiseSVN). Actually I use both, i.e. SVN for FPC and Lazarus itself,
>> and Git for my other projects, and invoke them in the Windows Explorer
>> whenever needed. Other platforms may not come with such comfort, there an
>> IDE integration may make more sense.
> 
> +1
> 
> Marcos Douglas
Some good points there. Again, I note that some developers (maybe all?)
workflow includes the use of external tools to do SCM. Thanks for your
comments.


Martin wrote ...
> And there he needs to communicate with the git program, to parse the data what 
> git returns, to build caches and the like where the MSEgit project provides 
> GPL'ed Free Pascal code.
> 

thanks for the pointer to the MSEgit project, I wasn't aware of this one.


Reinier wrote ...
> 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.
> 

yes, my bad .. I played a little loose with my terminology. sorry.
> 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?
Yes, one thing that appears to be missing is user / password control.

> 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.
> 
Yes, that is more like what I had in mind, a more generic approach which
would allow the user to make use of the SCM method that he/she likes or
needs to use for a given projcet. Flexibility is what I'm after here.

> 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)
Ok, at this point, I

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

Thanks, that sounds good. As I mentioned before, I sent my initial
inquiry with the view towards getting a sense of what people have done
already, find out who's in charge of what as far as code goes, and who's
interested in contributing.


Ludo wrote ...

> 
> What is missing is the functionnality to create a new repository from the
> current project. 

I totally agree. In fact that seems to be a big problem with every gui
implementation that I've seen so far, including the standalone
applications. (Now, to be fair, I might not have tried all the right
combinations, but I couldn't get things to work if I had a project
already in a folder. If I use the command line versions I could. So I
actually found the command line tools easier to use than the guis. Hmmm
something seems wrong there. I want to make things as easy to use as
possible, so that the user doesn't need to stand on their head and count
to a million while looking at a blue moon. Just joking, but seriously, I
think a good SCM should be fairly easy to learn how to use even for
someone who is just beginning.

That would the biggest value add of an integrated version
> control plugin. Explorer plugins like TortoiseSVN don't know what a lazarus
> project is (or any other project) and can only create new repositories from
> a complete directory tree. This means: weeding out unnecessary, non-source
> files from the directory, add whatever third party code needed which is not
> already under version control and then create a repository from the
> directory and check it out again to make it a working copy. The IDE knows
> the project and its dependencies and could make this step very easy for the
> user. 
> 
> Adding or deleting a file to/from a project and doing the same in the
> repository would also be a logical extension.
> 
Thanks for your thoughts on this. I was thinking that the SCM could do
some automagic stuff, but also be flexible enough to let the user choose
which files to care about as far as updating/commiting etc.
Michael wrote ...

> And this is the reason I disabled version control in Delphi.
> 
I can understand your point of view here.
> I often do a rename of a file, and then this mechanism bites you in the leg more than
> it helps.
> 
> If subversion (or whatever) automatisms are added, please make sure the behaviour
> can be fine-tuned to a high degree. I agree that the initial repository
> setup is a very good thing, but for the rest I prefer that the IDE does not try
> to be too smart.
> 

I couldn't agree with you more. This is a very helpful comment. Thank you.



Hans-Peter wrote ...

> An API may be required when multiple CVS shall be supported at the same 
> time. Then somebody (the IDE?) has to determine which of the installed 
> packages is used by a project.
> 

Yes Hans-Peter,
I was thinking that just like you have project settings, you could have
SCM settings on a project by project basis (somewhere ... either in a
separate file, or in the lpi [that might be a touchy subject ... I don't
know) that would keep track of whatever stuff the SCM doesn't know
about. Or, the SCM module could simply look for the appropriate folder
such as .SVN, .GIT, or whatever and extract whatever is needed from
there to do the job.

Again,

thanks so much for each of your kind replies.
I appologize in advance if I haven't quite got it right about how to
reply to these.

Dawson (aka abudeveloper)