[gschaider]

Originally Posted by olesen

Until fairly recently (Feb 2009) sourceforge had svn/cvs but no git for their repositories. Given the choice between cvs or svn, they (OpenFOAM-extend) made a wise choice.

If you've got the choice between CVS and SVN then there is no choice

One of the advantages of SVN that I still see (at least for the Breeder-part) is partial checkouts: if someone wants the SIG_Turbo-stuff he can checkout only that, if he only wants funkySetFields he gets that, but if he wants the whole breeder he can get it all.

Bernhard

[zeliboba]

Originally Posted by gschaider

One of the advantages of SVN that I still see (at least for the Breeder-part) is partial checkouts: if someone wants the SIG_Turbo-stuff he can checkout only that, if he only wants funkySetFields he gets that, but if he wants the whole breeder he can get it all.

right... but what is the trade-off? manual merge and loosing history (btw, one of the purpose for version control --- to keep it). technical solution for git-svn (or svn-git) interaction can be found. anyway this thread has different subject. and I vote for freefoam fork + OF-dev in git + testing sistem (I do not belive in manual review).

[olesen]

Posting Removed

[olesen]

Posting removed

[alberto]

Originally Posted by zeliboba

right... but what is the trade-off? manual merge and loosing history (btw, one of the purpose for version control --- to keep it). technical solution for git-svn (or svn-git) interaction can be found. anyway this thread has different subject. and I vote for freefoam fork + OF-dev in git + testing sistem (I do not belive in manual review).

I quickly took a look at the freefoam build system, and indeed it looks a good idea, and it makes building distribution-specific packages much easier.

I have only a suggestion: the list of settings is quite long, so it would be better to have an "easy installation path" (maybe I did not see it), so that the script assumes the worst situation (lack of all the dependencies on the system) and proceeds as a consequence. This could simplify the proecess for new users.

Of course my doubts on the name are still there

Best,

[alberto]

I was reading this
http://www.lenzg.net/archives/285-As...tems-DVCS.html

where other two version control systems are discussed:

Bazaar - http://bazaar-vcs.org/en/
Mercurial - http://mercurial.selenic.com/

Maybe we should take a look at them too?

Best,

[gschaider]

Originally Posted by olesen

Hi Bernhard,
I would turn the paradigm around the other way.
If the SIG_Turbo-stuff and funkySetFields work independently of each other, they could be in their own separate repositories. Assuming that they are in separate repos, the issue would be about pasting them all together into a single entity later.
This is what git-submodule is about. An alternative would be to use a script to pull in a particular version of external repos. This is what raduko does to pull in a svn from parrot. This is what I remember enGrid doing as well.

The point why I was stressing this was ease of use for those who just want to use that stuff (which is >90% of the population): He wants something, copy/pastes "svn checkout <URL>" to the command line and is ready to go. The only thing he has to have is svn (and that is a one-click-install on most distros).

PS: don't get me wrong: I'm using git for certain projects so I'm not completely opposed to it. I just think that for a certain group of people (developers) the benefits outweigh the steeper learning curve but not everyone is a developer. And I don't see the point to create for each small utility a separate repository. That's why I was explicit mentioning the breeder part

[gschaider]

Originally Posted by zeliboba

right... but what is the trade-off? manual merge and loosing history (btw, one of the purpose for version control --- to keep it).

Depends on what you mean with "loosing history". Did a small experiment: if I do a "svn cp FileA FileB;svn commit" then FileB keeps the information from his ancestor (a "svn blame FileB" will tell me for lines that come unmodified from FileA when this was written/commited). With a "cp FileA FileB;git add FileB;git commit" (which I believe is equivalent) "git blame FileB" says "all these lines were written at the same time".

I'm still suspicious that I'm doing something wrong, because somewhere I read (some git-mailinglist-archive) "Git doesn't need 'git cp' because the purpose of git is tracking content not files" and this seems to contradict my experience.

[zeliboba]

Originally Posted by alberto

Bazaar - http://bazaar-vcs.org/en/
Mercurial - http://mercurial.selenic.com/
Maybe we should take a look at them too?

what's the point? My concern is integration of all development lines (OF, OF-dev, FF) into one with less efforts, not about "best distributed version control system".

[zeliboba]

Originally Posted by gschaider

Depends on what you mean with "loosing history". Did a small experiment: if I do a "svn cp FileA FileB;svn commit" then FileB keeps the information from his ancestor (a "svn blame FileB" will tell me for lines that come unmodified from FileA when this was written/commited). With a "cp FileA FileB;git add FileB;git commit" (which I believe is equivalent) "git blame FileB" says "all these lines were written at the same time".

what I mean by "history" during manual merge is clearly explained at the end of this post. IMHO "svn vs. git" or "how to use version control properly" are not the subject of this thread.

[madad2005]

Is it just me, or does anyone else think the discussion about which revision control system to use when no formal decision has been made yet is both premature and getting slightly off-topic?

[pauls]

Originally Posted by madad2005

Is it just me, or does anyone else think the discussion about which revision control system to use when no formal decision has been made yet is both premature and getting slightly off-topic?

Not quite. You see, a few possibilities have been suggested, how the documentation project can continue. For a formal decision, why albertos setup is the one and only acceptable solution, it is quite helpful that all other revision systems are evil.

In the end, everybody will link to their documentation contributions in this forum as they did before. This worked quite well, and there is no reason, why it won't in future. I hope the documentation project is declared dead rather sooner than later, so that folks can be productive again instead of discussing solutions that will be defeated by one authority or the other.

[alberto]

Originally Posted by zeliboba

what's the point? My concern is integration of all development lines (OF, OF-dev, FF) into one with less efforts, not about "best distributed version control system".

The point is simple: if the idea is to switch, since switching a CVS is not fun for anyone, it is better to evaluate what is available before eventually decide.

Best,

[alberto]

Originally Posted by madad2005

Is it just me, or does anyone else think the discussion about which revision control system to use when no formal decision has been made yet is both premature and getting slightly off-topic?

Yes, I agree. The discussion is going off-topic, if a formal and shared decision won't be reached.

[alberto]

Originally Posted by pauls

Not quite. You see, a few possibilities have been suggested, how the documentation project can continue. For a formal decision, why albertos setup is the one and only acceptable solution, it is quite helpful that all other revision systems are evil.

I'm sorry, but I did not propose "the only acceptable solution". If I wanted to do that, I could have forked already, launching a new project, with a new name and completely different direction from the existing one. It would have saved a lot of the time spent in this discussion, which, frankly is not moving towards a solution.
I still hear proposals of "informal forks" like freefoam, which do not solve anything in practice, since they do not exclude the issues Holger faced with the documentation project. The ideas behind freefoam are good, but if we are going to make an effort to fork the project, it is better to fix the problems related with trademarks once for all, so to avoid any further problem.

In the end, everybody will link to their documentation contributions in this forum as they did before. This worked quite well, and there is no reason, why it won't in future.

The reason is simple: it did not work. There is no valid reference for OpenFOAM that can provide formal, organized and clear documentation to allow new users to rapidly start to work with OpenFOAM.

The forum is a perfect instrument to clarify doubts and short technical questions, but surely not to provide documentation. Your idea of linking contributions here would simply maintain the current situation, where only incomplete and not organized information is available.

I hope the documentation project is declared dead rather sooner than later, so that folks can be productive again instead of discussing solutions that will be defeated by one authority or the other.

Who should defeat these decisions? A formal fork is perfectly possible, since OpenFOAM is a software released under the GPL 2 license.

To conclude, you can disagree with the idea, but I find your hope in the documentation project death disrespectful for who invested time, money and efforts in trying to set it up. After all it is an initiative to help the community, you included.

Best,

[olesen]

Posting removed

[alberto]

Originally Posted by olesen

I think you are quite right.
Since the topic has now shifted to SCM systems and how to organized things (documentation, code) between various people, I would propose we start an entirely new thread.

The new thread is here: http://www.cfd-online.com/Forums/ope...tml#post235394

Thanks for opening the thread. Hopefully this does not mean that the discussion on what to do is closed, since it would not make any sense to think to how we organize efforts, since we still have to understand what is the direction of these efforts.

In particular, before thinking to how to organize the efforts, it would be better to find answers to the following questions:

• How do we want to proceed with the project?
  • Do something as -dev but including the documentation, and maintain the dependency on upstream/official OpenFOAM?
  • Formally fork and proceed independently, under a new name?
• What to do with the documentation project?
  • Do we want a formal documentation project?
  • Will be simply included in the "new version" of the code? If so, how do we plan to organize it?

I think that without these answers, discussing on what versioning system we want to use is a bit premature.

Best,

[thinktank1985]

maybe I dont understand the full implications but isnt it possible to temporarily host the documentation project on wikibooks. there are already some precedents here such as http://en.wikibooks.org/wiki/MATLAB_Programming.

Completing the fork or whatever decision, the community finally takes will take some time, in the mean time the project can be hosted on wikibooks site, and nobody specific can be targetted

[thinktank1985]

http://en.wikibooks.org/wiki/Categor...tific_software

[frafridr]

Hello.


In contribution #96 Alberto made suggestions to OpenCFD Ltd. It later appeared that similar suggestions were proposed by OpenFOAM-extend developers in 2007, see #101. In #111 Alberto summarized his experience.


With regards to other information we can find on the web I think that conclusion made by Alberto in #111 is rational and logical. I think that we should admit that the code which is provided according to GPL is successfully restricted by the trade mark policy. OpenCFD Ltd repeatedly declared its position.


By my opinion the OpenFOAM-extend project and the OpenFOAM Workshop are community initiatives that can significantly influence the future of the fully open code. The discussion here shall be focused on providing valuable information for them.


Frantisek