Synfig Project Forum

Please feel free to kill the superfluous trunk folder. Windows scripts don't need it.

We do have a few references to SVN in the build process, but they don't seem to get in the way of anything....

Chris

Regarding to this, the .gitignore file is making me suffer a bit. It has some custom ignores that makes me difficult the tracking of the modified files. Also I think that .gitignore should only ignore (or just never ignore) the files that doesn't belong to the tracker and are produced during building time. Any other file that the user want git to ignore should be added to that file or by using a custom git exclude file.

See this to know hot to add custom exclude files. http://www.kernel.org/pub/software/scm/ ... gnore.html

So If you don't mind, I'll remove the custom ignore entries in .gitignore to match the proper meaning of that file.

-G

_________________
Synfig needs your help!
Developers, packagers, bug testers, translators, artists, web developers, wiki writers... you can contribute!

I don't understand. Can you give an example?

G.

_________________
Abstraction: The Biggest Lie in Computer Science.

For example the current .gitignore file has the following entries:




You have to forgive me because those lines were not added by you but by dooglus.

So I'll take ride of them to make the .gitignore more logical.

My excuses
-G

_________________
Synfig needs your help!
Developers, packagers, bug testers, translators, artists, web developers, wiki writers... you can contribute!

Looks like sourceforge.net will soon support multiple git repositories (the updates for git happen today):

http://sourceforge.net/apps/wordpress/s ... y-support/

Now would be the appropriate time for synfig get rid of the trunk dirs properly and to do a real conversion from multiple SVN projects bundled into one SVN repo into to multiple git repositories with one per project. I'm willing to do the conversion from SVN and the import of the git history from your current git repositories. Is there any interest at all in doing a proper conversion from SVN to git? The current conversion sucks in a variety of ways and I believe will discourage experienced developers from joining the project. If you prefer to work as-is, at the very least you should remove the SVN metadata from changelog entries, fix the authorship information (Name <email> instead of just SVN login names) and move the website synfigskin git repository to sourceforge.net.

_________________
bye, pabs

Hey, pabs! Thank you for your offer!



Can you be more specific and name particular disadvantages of having single git repo for ETL/synfig-core/synfig-studio?

_________________
Morevna project:
Recently completed tasks: Demo released
Top priority tasks: Website reorganization

I thought I explained this before, anyway. Synfig is currently 3 pieces of software (or has been in the past). It is logical to place them in 3 separate VCS repositories. This was not done with SVN due to the design inadequacies of SVN and the general set of conventions surrounding SVN. As SVN can overload the meaning of directories and use them for tags and branches as well, it is feasible and generally accepted to store multiple logical repositories in one SVN repository. With git, tags and branches are first-class objects so there is no need to overload the meaning of directories. Now that sf.net supports multiple git repositories, there is no reason to bundle all 3 pieces of software into one git repository.

As for converting synfig to one piece of software by merging ETL & synfig into synfigstudio (or similar), I would strongly suggest that is the wrong way to go. It prevents things like synfig render farms where there is no GUI installed, apache2 mod_synfig (automatic sif->png renderers embedded in the web server), synfig nsplugin (.sif rendering for browsers).

_________________
bye, pabs

Pabs, thanks for your explanation. It will allow clarify some things that have been missunderstood.

I speak for my self but I guess nobody will contrary me on this:

ETL is just a template library that doesn't produce any separated application. Anyway it is a separated piece of software and (at the moment) it is independent of synfig-core and synfig-studio. It has its own versioning number. Eventually it can be merged into synfig or replaced with external libraries if possible. But that will not happen in short time.

Regarding to synfig-core and synfig-studio I completely agree to have them into separated applications so all the benefits of have a CLI and its separated libraries still available (render farms, automatic sif(z) renders, etc.).

The reason to migrate to git in one single repository is that, unfortunately, synfig code and synfigstudio code are not completely independent (the second -studio- has a lot of code references of the first -core-). So from the point of view of the developer, manage ETL, synfig-core and synfig-studio from one single repository is better and easier than being with three git directories and changing from one to other when doing a big modification.

Maybe there is other solution that consist in have three git repositories managed by a master git repository in the common trunk part but I don't see any advantage/disadventage on that approaching.

Also manage the tree pieces of software with one single repository allows to keep them synchronized. So when someone does a modification of the code that needs a modification (let's say) in synfig-core and in synfig-studio at the same time, it is not possible to try to perform a build operation with a repository in one revision and other in on different one, that can be incompatible. Managing all them in the same repository ensures that every revision is possible to build, a thing that doesn't happened before with svn and that might not happen if three separated git repositories are maintained.

Manage the three etl, synfig-core and synfig-studio in one single repository doesn't mean to produce only a single binary. Now it produces two binaries and several libraries and it will continue this way. One single repository is just a question of developer preference not a change of the direction of the concept of Synfig (CLI + GUI applications).

So, you don't have to worry about any intentions to merge synfig-core and synfig-studio into one single application.

-G

_________________
Synfig needs your help!
Developers, packagers, bug testers, translators, artists, web developers, wiki writers... you can contribute!

Totally agree with Genete.

_________________
Morevna project:
Recently completed tasks: Demo released
Top priority tasks: Website reorganization

Glad to hear about going on, congrats!

I'd gladly help with documentation... following my progressive discoveries.

I could help with Translations too if you can set-up any web-based translation manager (ala "launchpad" or other), for I don't want to go for git - patches and others ... being too bad at command line :/

Thanks.
B.

_________________
- discovering, learning about and liking Synfig, open source animation software -
| feel free to browse my Synfig archive | running v0.63.05 on Ubuntu Quantal |

Cool! which language? We don't have a launchpad web system enabled. We do the translation in the classic way: http://www.synfig.org/Translation
If you know how to setup a launchpad translation system please let us know.

Thanks!
-G

_________________
Synfig needs your help!
Developers, packagers, bug testers, translators, artists, web developers, wiki writers... you can contribute!

I'm fluent in french and english. I can proof-read dutch. If you have any priority in the translation needs would you mind communicating them?


Sourceforge does not provide a hosted service of that kind (yet). I asked for one, we'll see where it goes. Please vote for this request in SF: https://sourceforge.net/apps/ideatorren ... /idea/232/ (edited for direct link).

Meanwhile it could be possible to host your own online translation tool. A popular one is pootle (http://translate.sourceforge.net/), used a.o. by Mozilla and OpenOffice teams. I never used it but explanation and requirements are detailed in http://translate.sourceforge.net/wiki/p ... stallation. It integrates with GIT: http://translate.sourceforge.net/wiki/p ... on_control

You should check the technical requirements with the SF hosting if interested. If you want me to do it please telll me.

Another option is to switch the source repository to bazaar, and become hosted at launchpad.net. Zero config other than switching devel environment (which is quite big change, I agree). I would personally not recommend to mirror your PO files only on launchap, as you might get into sync problems between GIT and BZR... possibly.

B.

_________________
- discovering, learning about and liking Synfig, open source animation software -
| feel free to browse my Synfig archive | running v0.63.05 on Ubuntu Quantal |

Ok, it is clear you don't want me to do the proper git conversion. I'll do it privately then so I don't have to deal with your git repo.

Could someone move the synfigskin git repository to sourceforge so that there is one less thing on the server? I no longer have access to sourceforge.

_________________
bye, pabs

Does it means three git repositories for etl, synfig-core and synfig-studio? Where will you store them and what will be the use?


We plan to do that after September release.

-G

_________________
Synfig needs your help!
Developers, packagers, bug testers, translators, artists, web developers, wiki writers... you can contribute!

Yes. I'll store them on my laptop and this will be for me to use.



Great, please let me know when that is done so it can be removed from the server.

I also suggest moving the forums and website to sf.net once they allow custom themes and importing databases.

_________________
bye, pabs