Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2012-04

Development of other revision control

22 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Dawson

Reinier wrote ...

What are your plans? (Note: haven't used the Lazarus SVN plugin yet)

Well, at this point, I'm trying to get an idea of what has been done in Lazarus. I wanted to answer the question of how to do revisioning on my projects (one of which is in collaboration with another developer, my son). Also, I wanted to find out who has done what and who is interested in doing what.

Then, I had planned on looking at how other IDE integreated projects such as Eclipse, Netbeans, QT, (maybe even Visual Studio Express on my wife's windows machine), and stand-alone applications such as TortoiseSVN, SmartSVN, and also some web-based repo access is done such as in github, beanstalk (etc). Ok, let me be honest, I am not really familiar with using revision control systems ... I have a couple of projects on SourceForge which I use Git, and SVN on. But it hasn't totally become part of my workflow yet, since it just is a pain right now, and I wanted to make revision control less painful when developing in Lazarus.

See here for a message on an extended SVN class that might serve as a basis for porting functionality: http:/msg28007.html

thanks for this ref. ... not quite what I was looking for, but it all helps to put it in the learning bucket ...

I might well be interested in helping with a mercurial port...

Thanks for showing interest ... I guess I wasn't thinking of ports per se, I was thinking more along the lines of a generic tool for handling traffic and management of revision control systems.

Thanks again for your message,

Dawson

Reply by email

Dawson

Hi Martin, et al,

I looked at your FPC based git frontend, I must say I'm impressed. Thanks for sharing that bit with me.

Hi Graeme,

You are right, I am thinking about a "source code management API" for Lazarus, and your suggestion about checking out previous work is exactly what I plan to do, or glean off others.

At this point in the discussion I don't even know who all might be involved, or what work is going on in this area of Laz. development, that is why I've raised the issue. For that matter, I'm relatively new to the "source code management" tools out there. As for who all is involved in this kind of discussion ... I guess I'm learning that as I go too!

I'm very thankful for everyone's speedy and numerous responses to this question.

Thanks again,

Dawson

Reply by email

Dawson

Hi again Reinier,

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.

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.

And you are right, I think this prior work is a real great place to start from.

Thanks again,

Dawson

Reply by email

Juha Manninen
to Dawson: I looked at your FPC based git frontend, I must say I'm impressed. Thanks for sharing…

Some time ago Bernd improved LazSVN package and removed memory leaks. I added generics containers and removed some more memory leaks. I think they are all removed now.
See this mail thread where LazSVN package is an out-of-topic issue:

http:/msg27869.html

I have understood the package has no maintainer now. The position is open for someone who takes the effort and learns the code.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120411/5adab34f/attachment.html>

Reply by email

Dawson

Dear Mattias, et al.

Thanks for your helpful comments, and for your offer of help about the IDE interface, that is a very kind offer. I'll keep trying to learn what I need to learn, and plug myself into whatever I can do to help with this project.

I'm green here on this list, I just signed up today, so I want to make sure that my ideas are not at cross purposes with anyone else's project, and I'm happy to join the bandwagon, or encourage from the sidelines if other people are already involved ... I don't want to be pushy.

As I have mentioned in a previous post, I'd really like to see a well-integrated and generic "source code management" tool in Lazarus that people can use with whatever revision control system they want and with whatever repository they want to use. I would like it to be easy to use, so that people don't have to read 400+ page books (like one I downloaded on SVN) in order to do revision control in a lone developer project, or a collaborative effort.

Thanks again,

Dawson

Reply by email

Sven Barth
to Dawson: yes, I know what Darius (et al.) have done in lazsvnpkg is a plugin, and I really think…
Dawson wrote 5 lines
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.

It's not exactly plugin vs. API, but more "making a plugin which will provide a SCM API". Not everyone wants to use the IDE for version control (I personally prefer to use TortoiseSVN or the respective commandline tools for SVN and Git), so by providing the API as a plugin you aren't enforcing anything on other users. And that the plugin system should be powerful enough for a SCM API is shown by LazSVNPkg. If certain functions you need are missing then I'm sure one of the IDE developers will implement them for you. ;)

Regards,
Sven

Reply by email

Hans-Peter Diettrich
to Dawson: yes, I know what Darius (et al.) have done in lazsvnpkg is a plugin, and I really think…
Show quoted text 12 lines
Hi again Reinier, 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. 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.

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.

DoDi

Reply by email

Marcos Douglas
to Hans-Peter Diettrich
Hans-Peter Diettrich wrote 21 lines
Dawson schrieb: > Hi again Reinier, > > 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. > > 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. 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

Reply by email

Reinier Olislagers
to Dawson: yes, I know what Darius (et al.) have done in lazsvnpkg is a plugin, and I really think…
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.

Show quoted text 5 lines
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

Reply by email

Ludo Brands
to Reinier Olislagers
Show quoted text 8 lines
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?

What is missing is the functionnality to create a new repository from the current project. 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.

Ludo

Reply by email

Unknown author
to Ludo Brands
Ludo Brands wrote 22 lines
> 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? > What is missing is the functionnality to create a new repository from the current project. 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.

And this is the reason I disabled version control in Delphi.

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.

Michael.

Reply by email

Reinier Olislagers
to Hans-Peter Diettrich: An API may be required when multiple CVS shall be supported at the same time. Then…
Hans-Peter Diettrich wrote 11 lines
Reinier Olislagers schrieb: > 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? 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.

You propose having multiple packages, each supporting a separate revision control systems?
Then build in revision control support into the IDE? Seems like an unwieldy solution.

I'd rather have a single package that supports multiple systems - if necessary with extensions for certain systems (e.g. things that git can do that SVN can't).
This package would talk to various revision control system classes (using an API/interface/factory model, however you want to call it/implement it).
The project directory could contain a file (or perhaps an extension to the .lpi file, don't know if that is allowed) that specifies which RCS to use, as well as URLs, usernames, perhaps passwords etc.

Then again, it's not my decision.

Regards,
Reinier

Reply by email

Ludo Brands
to Unknown author: And this is the reason I disabled version control in Delphi. I often do a rename of a…
Show quoted text 11 lines
And this is the reason I disabled version control in Delphi. 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 completely agree. The only assistance I would expect when adding a file to a project is to pre-check the box in front of the filename in the commit window. Just to avoid searching in a list of sometimes hundreds of un-versioned files. If it is pre-checked it is much easier to find.

Ludo

Reply by email

Hans-Peter Diettrich
to Reinier Olislagers: Looking at <lazarus>\components\lazsvnpkg, the .lpk file states it's GPL, so yes, it's…
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?

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.

DoDi

Reply by email

Sven Barth
to Reinier Olislagers: You propose having multiple packages, each supporting a separate revision control systems?
Reinier Olislagers wrote 29 lines
On 12-4-2012 11:43, Hans-Peter Diettrich wrote: > Reinier Olislagers schrieb: > >> 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? > 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. > You propose having multiple packages, each supporting a separate revision control systems? Then build in revision control support into the IDE? Seems like an unwieldy solution. I'd rather have a single package that supports multiple systems - if necessary with extensions for certain systems (e.g. things that git can do that SVN can't). This package would talk to various revision control system classes (using an API/interface/factory model, however you want to call it/implement it). The project directory could contain a file (or perhaps an extension to the .lpi file, don't know if that is allowed) that specifies which RCS to use, as well as URLs, usernames, perhaps passwords etc. Then again, it's not my decision.

I personally would prefer if it would be designed the following way:

* have a package that provides a general SCM API and dialogs for the IDE
* have each SCM have it's own package which uses the SCM API package and wraps the SCM somehow (e.g. by using the tools or - if provided - a library)

This way one can easily leave out SCMs that one does not need. E.g. if one only uses Git and SVN then you don't need to have Mercurial and CVS support compiled into the IDE.

Regards,
Sven

Reply by email

Dawson

Hi ... a few more replies ...

On 12/04/12 1:06 PM,

Marcus wrote ...

Show quoted text 10 lines
> > 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.

Show quoted text 14 lines
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.

Show quoted text 8 lines
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.

Show quoted text 6 lines
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

Show quoted text 12 lines
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.

Show quoted text 8 lines
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)

Reply by email

Reinier Olislagers
to Dawson
Dawson wrote 12 lines
Hi ... a few more replies ... On 12/04/12 1:06 PM, 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.

No worries!

Show quoted text 5 lines
> 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.

In the architecture I proposed you'd simply extend the SVN class (and the git, mercurial etc classes) to add that functionality, then add username/password management to your component. No need for an extra API.

Show quoted text 11 lines
> 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.

Glad to hear it ;)

Show quoted text 17 lines
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.

Totally agreed that this is very relevant functionality. Functionality in stand alone Have a (probably
TortoiseSVN), that allows you to start a new repository, then select all your files, then add to repository.
However, this functionality need not be copied as Lazarus already knows all source files you put in your project so the plugin should just be able to come up with a list of them (and other files in the directories) so you can add e.g. readme files and then create your repository. Note: still haven't looked at the SVN component in Lazarus - guess I just don't use SVN...

Show quoted text 15 lines
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.

Depending if you want to go that way (and how the current component is set up): have a look at the SVN class I linked to see functionality that figures out if there's an svn repository (i.e. checks for .svn directory) and gets local revision etc.

Dawson,
thanks for your detailed feedback,
Reinier

Reply by email

Hans-Peter Diettrich
to Dawson: Hi ... a few more replies ... Marcus wrote ... Some good points there. Again, I note that…
Show quoted text 15 lines
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.

That sounds like a reasonable separation. The IDE should allow to put a project under control of a VCS, and then puts all related files and directories (source, config...) under version conrol (or removes them again, when deleted or moved).

Afterwards the IDE should know when to commit changes, e.g. it could ask on IDE/procject close whether the changes should be committed, if something has changed.

Remains branch management and switching revisions. This IMO should be better done outside the IDE, i.e. when the IDE is closed, so that the user doesn't have to answer dialog boxes about files changed on disk, and no changes can get lost on the files, which have not yet been saved by the IDE.

DoDi

Reply by email

Dawson

Hi Reinier,

(wrote on Date: Sat, 14 Apr 2012) ...

thanks for all your specific and encouraging comments, and taking the time to comment even though you are quite busy right now. I've looked at the link you suggested, it looks helpful.

In order to try to get lazsvnpkg to do something for me, I might just set up an SVN server that I can have full control over on my printer sharing box at home (it's not doing too much else). I'll also play with the basic gui based SCM's such as TortoiseSVN (on my wife's windows box, I'm using a mac) just to get familiar with what others have done.

Reinier, thanks again for all your help and suggestions

==============

Hi Hans-Peter,

(who wrote on Sat, 14 Apr 2012)

SNIP ...

The IDE should allow to put a project under control of a VCS, and then puts all related files and directories (source, config...) under version conrol (or removes them again, when deleted or moved).

Yes, I also think all these standard operations should be able to be handled by the IDE in Lazarus.

Show quoted text 5 lines
Remains branch management and switching revisions. This IMO should be better done outside the IDE, i.e. when the IDE is closed, so that the user doesn't have to answer dialog boxes about files changed on disk, and no changes can get lost on the files, which have not yet been saved by the IDE.

Yes, I think these "less than trivial operations" would be better handled "outside of the box".

Hans-Peter, thanks for your comments and suggestions.

Dawson (aka abudeveloper)

Reply by email

Graeme Geldenhuys
to Dawson: Hi ... a few more replies ... Marcus wrote ... Some good points there. Again, I note that…
Dawson wrote 6 lines
> 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.

IntelliJ IDEA does this without any problems if you are using a Git repository. I haven't tried IntelliJ IDEA with SubVersion or Mercurial though. Like I mentioned before, take a look at IntelliJ IDEA and Eclipse IDE's. They have been around for ages and have pretty good SCM integration support. I am sure you can learn a lot from then and get get a good idea of a working SCM API for a IDE like Lazarus.

Regards, ? - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net

Reply by email

Marco van de Voort
to Dawson: Hi ... a few more replies ... Marcus wrote ... Some good points there. Again, I note that…
Dawson wrote 9 lines
>> 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. 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.

I also fall in that (external) category. If you start working on SCM plugins, writing a word on two what the advantages are, might be worthwhile too :-)

It auto adds files (which I hate however), and can instruct the IDE to save files before commit. That was about as far as I got.

Reply by email

Dawson
On 15/04/12 Graeme wrote 6 lines
IntelliJ IDEA does this without any problems if you are using a Git repository. I haven't tried IntelliJ IDEA with SubVersion or Mercurial though. Like I mentioned before, take a look at IntelliJ IDEA and Eclipse IDE's. They have been around for ages and have pretty good SCM integration support. I am sure you can learn a lot from then and get get a good idea of a working SCM API for a IDE like Lazarus.

Ok, that is my next stop. I'll play with both of those. It doesn't matter much to me whether it is GIT, or SVN, or Mercurial, although if there are commendable gui implementations of these of course I am interested to look. I am aware that they are differing approaches to SCM, but at this point (is it my ignorance perhaps?) I think that there should be a fair degree of overlap in the functionality of the systems and the gui would just build appropriate command lines for whichever system the user is working with. Thanks for the heads up on IntelliJ, and Eclipse. I haven't used Eclipse for ages, but I think I'll go grab a copy and play. I don't recall ever using IntelliJ I think there is a community edition, so I can give that a go also.

Thanks again Graeme,

Dawson (aka abudeveloper)

Reply by email