![]() I am thinking GPLv2 might be the correct way to go anyway?ĭepending on how useful and how many features I can put in it I may want to charge for a full-featured version.Īlso to be able to put it on the VI Package Network do I need to use VIPM to package it? I was going to just zip up an an install for it so it can auto configure the mercurial ini file to point to the program. So would the BSD apply to an exe distribution? It is not really meant to run as source code, but as an interface application between TortoiseHG and LVMerge. ![]() I am actually not even interfacing with Mercurial, only with LVMerge.exe and the Mercurial.ini file. ![]() It would make sense to use their logo as part of mine for the application, but didn't want to open that can of worms. If you are just calling the Mercurial command line interface you don't need to use the GPLv2+ license. One thing to remember is that Mercurial itself is licensed as GPLv2+, this license includes the Mercurial logo. Is the code for the full merge available somewhere so I could have a look? I am working on the details, but the NI system is quite tricky! I am working on an interface in the LabVIEW Project window (NI calls them Providers), as a set-top of my Mercurial API. On a final note.no annoying "status" files in my working directory! When updating to different changesets you do have to revert all your files manually (I usually have everything closed when performing updates). I just make my updates for a certain feature or bug, then commit all files from explorer. One of the main reasons I think it is easier is that you don't have to "check in" and "check out" every file individually. Is anyone else working on an implementation of the "LVMerge" for mercurial that supports multi-file merging?Īs far as an API for the project I don't really see a need except for maybe a hotkey shortcut to commit. Now I just need to trick out the interface to "wait" until the merging is finished, cancelled, or errors out. I was thinking a hierarchy ordering of the vi's to merge might be necessary in order to get it correct, but LVMerge (at least in 2010) is very good. The only way I see is to use the Mercurial commands directly to "update" to each of the changesets being compared in their entirety and then compare them in different directly structures. Unfortunately LabVIEW's compile at edit time and sub vi dependency means that if multiple related files are different then the single file diff won't be entirely accurate. A diff tool also needs a little work to support to diff changesets when multiple related files are different. The merging is a little lacking, but I am working on a simple tool to allow multi-file merges with TortoiseHG (LVMerge ends execution before the merge is actually complete and you miss the next file merge). ![]() Meanwhile I have another branch where I am gutting the entire structure of the program. I have a major project where another developer is making sweeping changes that are not all backward compatible yet, but we are working from the same repository and I can still perform stable maintence releases. It has literally saved me days of work because of how easy it is to manage releases, bug fixes, major changes with the branching and merging features. The ability to go back to a tagged release, make a small change, perform a build and release (and tag), and then merge that change to the mainline is so easy in mercurial and next to impossible in the other environments I have used. It is really easy to manage when I am the only developer, but also isn't too bad in a multi-developer environment either. I've been using Mercurial with TortoiseHG and Kiln (Kiln is free for two developers) since this last summer and I love it! It sometimes surprises me how easy some activities are compared to how I used to have to do them with VSS / Perforce / Surround SCM / DesignSync (don't ask about that one.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |