Open GoogleCodeExporter opened 8 years ago
Ok migration to another repo takes time and effort and might confuse people
having the repo URL in some config file. So I don't want to dive into this
without being sure it can improve the project significantly.
So I need some more information / advices on this.
Some inputs :
* Googlecode allow switching to git repo if needed
* git-svn works fine locally to interact with a svn repo
* downloads are already hosted at sourceforge ... Is a complete switch to
Sourceforge also an option ?
* what about migration tools ? We would need to migrate all repo history of
course, but also issues, opened and closed
Original comment by antonin
on 16 Sep 2014 at 1:55
git is only useful when dealing with complex branching/merging strategy.
OpenJPEG has very very limited usage of branch (patch from 1.x to 2.x are
manually merged since code is so different).
I doubt there is any real advantage in using git as main VCS for openjpeg. BTW
nothing prevent users from using git-svn and have full git power on there
client.
Please submit single, well tested, clear patch on the mailing list. The github
workflow may work for others, we did not required it for the past 10 years or
so.
Footnote: I am biased since github is a closed-source platform.
Original comment by mathieu.malaterre
on 16 Sep 2014 at 2:01
Mathieu - you are right regarding bug fixes, where SVN more than suffices. But
from my experience with working on new features, branching helps immensely.
If the feature is complex, then it will require multiple commits, and this
context is lost when submitting a patch. Github allows patch developer and
repo maintainers to make comments on the code being submitted (these comments
appear right next to the relevant lines), request changes, re-submit the
changes, and the history of this code conversation is saved and available for
viewing.
Since SVN has such poor branching support, it is not surprising that OpenJPEG
has not used many branches over the last 10 years. But this doesn't mean it
will not be useful in the future, if it is easy to use. There is a reason why
SVN adoption is dropping and many new OS projects use Git.
Gits excellent branch support encourages other developers to fork the code and
add features they are interested in, and easily keep up with changes in the
forked repo.
Another nice feature is git rebase - when developing one often wants to make
checkpoint commits where the code is at a sane state, but the feature is not
complete. After the feature is ready, it is possible to combine these commits
into one polished commit using git rebase. I use this feature a lot when working
on a feature branch, just before I merge into the master branch.
I could go on, obviously I am a git fanatic!
Regarding Antonin's questions:
Yes, googlecode supports git, but the Github workflow using pull requests is
really nice. To submit a patch, you simply fork the parent repository, make the
changes in a branch, and press a button to submit these changes as a "pull
request". If the maintainer likes them, they can often automatically merge the
changes in. Otherwise, they can request changes, and go back and forth until
everyone is happy. I have found it much easier to use than manual patch
submission.
We can port over the entire SVN repo with history into a git repository. I have
already done this on my mirror: https://github.com/OpenJPEG/openjpeg
Under the "branch" button you can switch to all of the SVN branches.
The only thing missing would be the author information, since I don't have
access to the authors file.
Regarding moving the issues, there are scripts out there to do this, but I
haven't tried them.
Downloads can be hosted at github too.
And yes, there is a learning curve. It will take some time to get used to the
new tools. But, well worth it, in my opinion.
Finally, last time I checked, google code and sourceforge were also closed
source platforms :)
Kind Regards,
Aaron
Original comment by boxe...@gmail.com
on 16 Sep 2014 at 3:03
Here is an article outlining the rising fortunes of git, and the decline of SVN:
http://readwrite.com/2014/01/21/git-subversion-developers
Original comment by boxe...@gmail.com
on 17 Sep 2014 at 1:28
[deleted comment]
Hi,
I do not use git myself (for now) as my company heavily relies on Subversion.
Nevertheless, when dealing with opensource libraries, I can sense that I spend
more & more time on GitHub to browse source code/check changes/retrieve tags...
The adoption of Git by the opensource community has been growing for the last
few years & is now (from what I've read) used more often than Subversion.
Since I don't really use git, I rely mostly on what I've read here & there. But
what I could sense while browsing GitHub, and as Aaron pointed out, the GitHub
workflow encourages developers to fork, make their own branches for new
features or bugfixes. Git being much more "merge friendly" (that was one of the
reason it's been developed in the first time) than Subversion, it will be
really easy to merge back fixes & new features in the mainline SVN (& for those
developers, to merge the mainline in their branches on the go).
As I said, this more of a feeling than concrete experience. Nevertheless, seems
the way to go.
As Aaron pointed out, GitHub, GoogleCode, SourceForge are all closed source
platforms relying on opensource software so no difference there.
Regards,
Matthieu
Original comment by m.darb...@gmail.com
on 17 Sep 2014 at 7:52
@Aaron: we're investigating migration to github. One thing I couldn't find is
how to attach files to issues ? This is something we use *a lot* in OpenJPEG,
attaching corrupted J2K files, and so on ... Do you have any comment on this or
advice for a solution ?
Original comment by antonin
on 23 Jan 2015 at 9:24
https://github.com/blog/1347-issue-attachments
Original comment by boxe...@gmail.com
on 23 Jan 2015 at 2:28
@Aaron: This is only for image attachments (png, gif, jpg). By any chance, are
you aware of any solution to attach other files (like JP2 files ... Which is
very often the case when opening an issue in OpenJPEG) ? Thanks
Original comment by antonin
on 27 Jan 2015 at 2:06
sorry, don't know how to do this.
Original comment by boxe...@gmail.com
on 27 Jan 2015 at 2:16
I stumbled on this page while looking for something else, but this may be
useful to you for attaching files:
https://github.com/ljosa/issues-with-attachments
In particular, it might be integrated with github's Large File Storage:
https://github.com/blog/1986-announcing-git-large-file-storage-lfs
Original comment by tho...@gmail.com
on 21 May 2015 at 1:00
Original issue reported on code.google.com by
boxe...@gmail.com
on 6 Jul 2014 at 1:18