Re: [fossil-users] Preferred way of dealing with upstream projects maintained in different VCSes?
On Wed, Jun 15, 2016 at 09:02:54PM -0500, lvh wrote: > I’m interested in exploring the possibilities of moving to a Fossil > monorepo at $dayjob. One of the things I’m not sure how to deal with > appropriately is dealing with projects managed upstream in some other > VCS (which, de facto, appears to be just git). The primary question is whether you want to apply local changes and how often you want to update. If there is any chance for the former, it is often a good idea to follow the vendor branch approach from CVS to a degree. That is, create a branch from the initial (empty) revision with the unmodified upstream state. Merge the new branch head into your normal development branch (e.g. trunk) and adjust as necessary. For updaptes, go back to the vendor branch, commit the new version and merge it again to your development branch. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Preferred way of dealing with upstream projects maintained in different VCSes?
On 16 Jun 2016, at 04:02 , lvh <_...@lvh.io> wrote: > I’m interested in exploring the possibilities of moving to a Fossil monorepo > at $dayjob. One of the things I’m not sure how to deal with appropriately is > dealing with projects managed upstream in some other VCS (which, de facto, > appears to be just git). For example, I’m currently working on Azure > (Microsoft’s cloud) using REST APIs, defined by a bunch of Swagger files > (https://github.com/Azure/azure-rest-api-specs). > > These are important to the software we’re building, so they ought to live in > VCS, or at least a reference to them should. How do you manage this? Just put > the .git dir in version control? Bare checkout? Something that references the > repo + commit but keeping the actual checkout out of source control? I usually simply copy the git clone into the fossil repo. The .git dir is not checked into the fossil repo, instead I commit the whole folder into fossil as well. From then on one can keep the same folder structure synced in git as well as fossil. Can become messy if you’re not attentive, but works. Cross referencing the commit hashes in commit messages of the DVCS counterparts makes sense too. ;-) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Preferred way of dealing with upstream projects maintained in different VCSes?
On Wed, Jun 15, 2016 at 10:02 PM, lvh <_...@lvh.io> wrote: > > These are important to the software we’re building, so they ought to live > in VCS, or at least a reference to them should. How do you manage this? > Just put the .git dir in version control? Bare checkout? Something that > references the repo + commit but keeping the actual checkout out of source > control? > The .git dir is the local copy of the git repository, so that could be a huge thing to keep in another VCS - Fossil or other. If you are only "reading" the upstream projects, you could export the git repo and import it to Fossil. Once done the first time, you should be able to do it incrementally. Other VCSs can be exported to Fossil. Fossil recently acquired support for importing from SVN. Other VCSs would require exporting to either git or SVN export format, then importing to Fossil. Would be simpler to just fetch tar/zip files of the other projects as needed. Then you could either untar/unzip those and commit in to Fossil locally, or just reference in your makefile (or whatever your build system uses) by defining a "pointer" to where the files were untared/unzipped. To make contributions to the upstream projects, you could send patch files. But many projects - especially those on github - expect pull requests, so you'd need to have local copies of the repos. When I make contributions to git based projects, I update my local copy of the repo, update my Fossil repo of the project and manage my changes with Fossil. When I'm ready to submit my changes, I update my local git repo, merge any upstream changes to my changes and commit to my local git repo (and to Fossil). Then, if applicable, push to my github "fork". Then,send out the pull request. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
