Whoops, forgot to include the list just now. Sorry for the confusion. > How do I do it?
I've explained this in my previous post, and you appear to have understood. If there's something still unclear, please let me know. >> (And I REALLY don't want to have to install >> bzr or hg or perforce on my machine to update a package, EVER.) > > You don't have to if you don't want to. > The option I described is only valid in case there is software > hosted in Subversion which one wants to package for CoApp. I do if I want to update a fork that YOU have published by converting the history from bzr or hg, or if I want to fork an existing bzr or hg project without offending someone. If I want to update one of your forks from Subversion, I have to learn git-svn, instead of just having to learn git. My intention in listing requirements was to illustrate that all of them can be satisfied by importing snapshots. They are also satisfied by your approach. > Indeed. That's why we need to host complete sources of upstream in > revision-controlled system, > in GitHub, with tags and branches from upstream. We need to host the complete sources, but I don't see the need to host the complete history. We only need to preserve enough of the structure of the history that we can understand our own changes and use Git effectively with them. I would argue that the individual patches in an upstream project do not matter to us at all. > Just look how Subversion workflow works. > 1) trunk -> upstream, development > 2) I want to release 1.0, feature freeze, make branches/1.0 > 3) I release, then I tag form branches/1.0 as tags/1.0.0 > 4) I have fix for 1.0, then I merge fix into trunk/ and into branches/1.0 > 5) I make bugfix release from branches/1.0 so I create tags/1.0.1 > > If we have mirror of this SVN repo in GitHub, then we just release new > package updated > from tags/1.0.0 to tags/1.0.1. We don't have to maintain > releases/version of upstream on our own. Except that someone has to keep that mirror updated, which is a different sort of work from the rest of it. Someone who understands git can import only those tags, but can't necessarily update an svn mirror. AFAICT the only advantage for you is that you can automate the process of updating the svn mirror, but updating another person's svn mirror is harder. I've actually failed at updating a git-svn clone before, and had to start over (which would be unacceptable for anything but a private repo, as the resulting commits are different). I'm sure it was fixable, but apparently I was not smart enough to fix it. Cherry-picks from upstream may also be more convenient, but you should be able to backport any change you need without Git's help. >> That approach looks like this: >> * Create a new Git repository with a branch named 'upstream' (or >> something like upstream-2.6 if we need to track multiple upstream >> branches). >> * Download a tarball of a release of this project, dump the files in >> the repository (without the project-version prefix they usually add), >> and commit them. >> * Create a master branch based on the upstream branch, and do the >> packaging work. >> * Create a repository in the coapp-packages organization containing >> both the master and the upstream branch. You can have mirrors in your >> own github account if that is how you like to use github. I won't >> judge. > > If this workflow is sufficient to what we need, it makes sense. I believe it is. > Do we consider having -devel packages from development version of codes? > I think it is important to be able to create CoApp packages for mylib-devel. That would require updating more often, but one can certainly do that with snapshots. It doesn't require having every point in the history, just every point where you want to make a -devel package. Instead of using a tarball, you would need to get the files from the project's RCS. > AFAIU, you are proposing Vendor Branches, aren't you? I've never heard the term, but the description does sound like what I'm proposing. I just saw the approach used elsewhere and thought it made sense here. > Basically, there are two common approaches to maintain thrid-party sources: > 1) git svn > 2) vendor branches made from release packages of third-party sources > > They are similar but slightly different: 1) preserves complete history > and may make it > easier to generate patches and contribute changes back to upstream. > Thus, this is my preferred appraoch. I don't think preserving complete upstream history is important, and I don't understand how it makes it easier to generate a patch. > My general point is, let's not reinvent the wheel for new workfllow. > The problem we are trying to solve is an old one, well-solved > and developers are familiar with solutions. It is like with design patterns. > If CoApp uses common approach, it will be easier for contributors to adapt. I think we agree on most of it, and it is only on the use of git-svn that we differ. I think git-svn (and any other automated tool that converts complete history to git) adds unnecessary complexity and shouldn't be used. _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
