Jump to content

Gerard Murphy

Members
  • Content Count

    50
  • Joined

  • Last visited

  • Days Won

    7

Gerard Murphy last won the day on September 2 2017

Gerard Murphy had the most liked content!

Community Reputation

19 Good

About Gerard Murphy

  • Rank
    Advanced Member

Recent Profile Visitors

3,790 profile views
  1. Hi Carlos - yes, I am - but I thought this only permits you to move a changeset from a branch head to a brand new branch. You can't move a changeset on to an existing branch that already has commits of its own. The latter has been my use-case for the three instances of this problem. (EDIT: ah - but I've realised now that you can make a brand new branch from the target branch the commit needs to be cherry picked on to - then you can merge the new branch back on to the original target branch. A bit roundabout, but it will do nicely.) Regards, Gerard
  2. Arrgh! I've just been hit by this problem again - forgot my own advice not to delete the original redundant changeset and lo! - ended up with a corrupt commit, only this time the commit was a few behind the latest commit on the new branch. I was lucky this time in that although the changeset was corrupt in the repository, I still had local copies of the files in the correct state for that changeset in my local workspace. I couldn't fix this in Plastic at all, but as I sync with GitHub, I was able to rebuild a correct history using file copying and Git's interactive rebase, force push it to GitHub, delete the recent commits on the corrupted branch in Plastic and resync from GitHub. Not a fun experience. This is the third time I've been bitten by this bug; can somebody please fix this? Alternatively, I can live with the workaround that if there is a changeset that is invisibly linked with an older one, then any attempt to delete the older one is blocked. I've noticed that Plastic does do this check for when a shelf is based off a changeset - you can't delete the changeset until the shelf is deleted first. This could be extended to checking dependent changesets created by applying a shelf; that would at least stop me from losing commits. I'd rather that applying a shelf made a genuinely independent commit, though - nicer behaviour without surprises. I'm using Plastic 7.0.16.1889 - Smashing Pumpkins - Cherub Rock.
  3. Gerard Murphy

    GitSync and GitServer on OSX Plastic

    The command line approach works fine, thanks Carlos.
  4. Hi, I'm using the OSX version of Plastic SCM - 6.8.16.1271 (The Faces - Stay With Me). It's the Cloud version. I can't see any option to sync via GitSync in the GUI - on the Windows version, one can get to this via the branch view and then right-clicking on a branch. Are either (or both) of GitSync / GitServer supported by the OSX Cloud version? Regards, Gerard
  5. Hi Wolfram, I've seen this idea being kicked around before - branching for the sake of maintaining multiple 'kinds' of a product, as opposed to parallel development streams of the *same* product. The latter has a notion of merging changes back together at some point - be they hotfixes on a release branch going back to the development mainline, or a new feature off a feature branch. The idea is that the product may at various times bifurcate into more than one parallel version, but this is a variation on simply having one line of development. Ultimately it's still just one product. You might get abandoned experimental branches and POCs too, but they don't get merged back. What you want, I think, is a set of never-ending branches that represent similar products that share code in common, but should not be regarded (and not sold) as one thing. As I'm sure you already know, you can start with a common main branch, make product line-specific branches off that and then have a rule that merges must flow from the main up to the branches, but never the other way (otherwise you'll end up creating a fused product). This takes some discipline, and if you detect bugs on a specific product (which will be the case for those reported in the field), then you'll have to make the effort to triage those bugs into those that are product line-specific, and those that are common. The product line-specific ones get fixed on the branches, and the common ones get fixed on main (or on temporary topic branches that flyout from main) and then get merged up into all the product line branches. Of course, this doesn't always work out in the heat of development, in which case you have to cherry-pick a fix from the product-line branch back to main, massage it to make sure that no fusion of product line-specific stuff occurs in the merge. It's achievable in Plastic if you isolate your bug reproduction tests and fixes in either single commits or topic branches that flyout off the product line-specific branches - you can cherry pick these without bringing in too much unrelated cruft. I really would stick to just that flow and avoid cloaks and subtractive merges - these things have their place, but you'd have to be very careful about code organisation, for example, if you want to use cloaking to make a merge back from a product specific branch back to main safe. Which brings me to... Have you considered factoring your codebase into a common piece and stuff that can be product-specific? I would hope that most of your code could be hived off into a library that has just one delivery branch (I'm ignoring release branches, you get the picture, I'm sure) in its own repository. The product specific stuff can then become completely independent projects with their own repositories. You can either go the route of delivering the library as a binary internally, or use an XLink to mount it within your individual projects. You can do both if you want - you'll know when you'll need to do that. You could go the route of keeping your product lines as one repository with line-specific branches here too; in which case I'd hope that having the common library would cut down on the ceremony of maintaining the branches and sticking to the merge discipline - less code to worry about. If you go down that last variation, consider using feature toggles and configuration so that the product specific-lines only vary in configuration files and not in main code - in which case you can start to think about cloaking again; this time it might be easier. So to summarise, it can be done but there is no silver bullet I know of. I'm curious myself now to know if anyone else has experience with this... Regards, Gerard
  6. Hi Manu, Thanks for the tip - I'll stick with the Cloud edition for now, as I think I'd have to have the full paid regular server license to run GitServer if I remember correctly - I went for the Cloud edition as an easier way to manage the fee. I'll wait for the fix to come out, please post an update when it does.
  7. I've rolled back Plastic SCM to the previous released version: 5.4.16.769 (Every Breath You Take) - this fixes the problem for me for now; I can start the Plastic SCM service and use GitServer. I looked through 'plastic.debug.log.txt' again after deleting the old contents and restarting the server; I'm still seeing the same assembly resolution failures as in the original post above, even though the service now starts up correctly and works, so I guess that information was irrelevant after all.
  8. Hi, I'm running Plastic SCM Cloud, 5.4.16.771 (Carry on my Wayward Son) on Windows 8.1. The installation proceeded fine, and I can use Plastic SCM up until the point where I wrote a 'gitserver.conf' to enable GitServer. I've placed in in directory 'C:\Program Files\PlasticSCM5\server'. When I restart the Plastic SCM service, it crashes after a second or so. This is repeatable each time, and is not affected by the contents of the 'gitserver.conf' file. Looking at the Windows event log, I see the following stack trace from the server's last error log entry:- Service cannot be started. System.NullReferenceException: Object reference not set to an instance of an object. at Codice.CM.Server.SystemRunner.b() at Codice.CM.Server.SystemRunner.Init(Boolean bInitInSeparateThread) at Codice.CM.Daemon.PlasticService.OnStart(String[] args) at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state) Looking at the log in 'plastic.debug.log.txt'. I see the following lines:- 2016-08-22 09:44:15,294 10848 (null) (null) INFO Daemon - Initialize Datalayer 2016-08-22 09:44:16,014 10664 (null) (null) INFO Codice.CM.Server.ComponentLoader - 50 components loaded 2016-08-22 09:44:16,045 4984 (null) (null) INFO ServiceGarage - Going to init services 2016-08-22 09:44:16,045 4984 (null) (null) INFO ServiceGarage - SecurityHandler started. 0 ms 2016-08-22 09:44:16,045 4984 (null) (null) INFO RepositoryHandler - RepositoryHandler InitService 2016-08-22 09:44:16,061 10664 (null) (null) INFO Daemon - Server listening locally only 2016-08-22 09:44:16,061 7620 (null) (null) INFO networkserver - Server listening locally on port 8084 2016-08-22 09:44:16,061 7620 (null) (null) INFO networkserver - Tcp Fast Path enabled 2016-08-22 09:44:16,076 10664 (null) (null) DEBUG GitRepo.AssemblyResolver - AssemblyResolve request 'clientcommon, Version=5.4.16.771, Culture=neutral, PublicKeyToken=null' 2016-08-22 09:44:16,076 10664 (null) (null) DEBUG GitRepo.AssemblyResolver - Loaded assembly from 'C:\Program Files\PlasticSCM5\client\clientcommon.dll' 2016-08-22 09:44:16,123 10664 (null) (null) DEBUG GitRepo.AssemblyResolver - AssemblyResolve request 'basecommands, Version=5.4.16.771, Culture=neutral, PublicKeyToken=null' 2016-08-22 09:44:16,123 10664 (null) (null) DEBUG GitRepo.AssemblyResolver - Loaded assembly from 'C:\Program Files\PlasticSCM5\client\basecommands.dll' 2016-08-22 09:44:16,154 4984 (null) (null) INFO DataConnection - SQLite version 3.8.6 2016-08-22 09:44:16,264 4984 (null) (null) INFO Transaction - Transaction timeout -> 120000ms 2016-08-22 09:44:16,295 4984 (null) (null) DEBUG RepositoryStore - Db for Repositories is correctly initialized 2016-08-22 09:44:16,295 10664 (null) (null) DEBUG GitServerConf - Loading git server configuration 2016-08-22 09:44:16,311 4984 (null) (null) INFO RepositoryStore - Repositories database already exists and is correctly initialized 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - GitServerConfData: 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - StorageBaseDirectory: 'C:\Windows\system32\config\systemprofile\AppData\Local\plastic4\gitserver' 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - HttpPort: '80' 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - TcpPort: '9418' 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - MappingInterval: '300000' 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - MappingCsetsLimitBeforeDumping: '0' 2016-08-22 09:44:16,313 10664 (null) (null) DEBUG GitServerConf - SkipUnresolvedXlink: 'False' 2016-08-22 09:44:16,313 4400 (null) (null) DEBUG Git - GitTcpServer listening on port [9418] 2016-08-22 09:44:16,313 9520 (null) (null) DEBUG GitRepo.AssemblyResolver - AssemblyResolve request 'LibGit2Sharp, Version=5.4.16.661, Culture=neutral, PublicKeyToken=null' 2016-08-22 09:44:16,313 9520 (null) (null) DEBUG GitRepo.AssemblyResolver - Loaded assembly from 'C:\Program Files\PlasticSCM5\client\LibGit2Sharp.dll' (STUFF TO DO WITH REPOSITORIES OMITTED - ITS THE SAME IN THE SUCCESSFUL CASE TOO) 2016-08-22 09:44:16,375 9520 (null) (null) DEBUG Git - GitHttpServer going to use prefix [http://+:80/] (STUFF TO DO WITH REPOSITORIES OMITTED - ITS THE SAME IN THE SUCCESSFUL CASE TOO) 2016-08-22 09:44:16,484 4984 dcad92eb-6d42-47c6-b515-0586c90d8593 Server:SAGESERPENTLPTP DEBUG GitRepo.AssemblyResolver - AssemblyResolve request 'securitymanager.XmlSerializers, Version=5.4.16.771, Culture=neutral, PublicKeyToken=null' 2016-08-22 09:44:16,484 4984 dcad92eb-6d42-47c6-b515-0586c90d8593 Server:SAGESERPENTLPTP DEBUG GitRepo.AssemblyResolver - Cannot be resolved assembly: 'securitymanager.XmlSerializers.dll 2016-08-22 09:44:16,484 4984 dcad92eb-6d42-47c6-b515-0586c90d8593 Server:SAGESERPENTLPTP DEBUG GitRepo.AssemblyResolver - AssemblyResolve request 'securitymanager.XmlSerializers' 2016-08-22 09:44:16,484 4984 dcad92eb-6d42-47c6-b515-0586c90d8593 Server:SAGESERPENTLPTP DEBUG GitRepo.AssemblyResolver - Cannot be resolved assembly: 'securitymanager.XmlSerializers.dll It looks like there is an assembly missing from the distribution. Any chance of a quick fix or workaround? - I want to show some work to the customer who uses Git this week, so it would be very much appreciated. Regards, Gerard
  9. 1. I've got an update on this - having just tried my own suggested procedure today, what I find is that once the original changeset is deleted (in step #6), this will damage the shelf created in step #3. 2. Furthermore, I'm fairly sure that the changeset created in step #5 (which is good at that point) will be retroactively damaged in step #6. The workspace also gets into a strange state where changes to a file referenced in the deleted changeset can't be committed (and the diffs claim that the file has been created from new). I don't want to repeat the verification of claim #2, as it's quite tricky to recover from. I think that Plastic shares the 'base' of the deltas somehow between the two changesets and the shelf - once step #6 is done, that shared information is no longer valid. I've seen this once before doing the same thing and put it down to a glitch / user error, but this is the second time, so I'd caution against using this procedure - or if you must do, don't carry out step #6, keep the redundant changeset instead. I'm on Plastic Cloud, version 5.4.16.756.
  10. Hi, I'm using IntelliJ IDEA 2016.1.2 (Have been seeing this problem in all versions I've installed through 2015 to the present, though). My version of Plastic is currently 5.4.16.749 (again, I've been seeing this problem in all releases of Plastic through 2015 to the present). The plugin for Plastic SCM is installed correctly and works - I can make commits, show diffs etc. Just after I commit changes via IntelliJ, the local changes tab in IntelliJ shows no changes, as expected, and a corresponding changeset is created in Plastic. However, when I make further changes, the diff views in IntelliJ pick up a mixture of the new changes since my last commit, plus older changes from the previous commit. If I commit the new changes to make a new changeset, only the changes I made since the last commit actually make there way into that new changeset. I can repeat this procedure with a running IntelliJ instance, after each commit, the local changes view clears, but the diffs roll up more and more old revisions - it gets very confusing to work on. Using Plastic standalone in tandem with IntelliJ is a workaround, but it would be good to see this bug fixed - when I'm in the flow it's nice to stay in the IDE and use Plastic more occasionally for the heavy lifting, such as merging. Regards, Gerard
  11. Gerard Murphy

    How do you install use Semantic Merge plugins?

    Three more things to mention:- 1. The F# Compiler Services library wasn't that well developed when I used this, but I'm fairly certain it's improved hugely since then. I would strongly recommend updating the NuGet dependency to track the latest version. There are other projects that use this library too, it's worth taking a look around to see what they do with it. 2. There is a comment in 'FileProcessor.fs':- type LineSpan = pos * pos // the second is a zero-relative character position within the line. // The second sub-pair points one past the end of the construct, // so the interval is [). It may either point past the end on the // same line, or may point to the zeroeth character position on the // next line, this depends on whether the construct is contained // within one line or spans several. type CharacterSpan = int * int // [] interval using zero-relative character position. The first part of this is *wrong* - the line spans used in the Semantic Merge specification are [] intervals - so the second sub-pair points to the end of the construct (so if the linespan is empty, it points one character in front of the start). I fixed this bug in the Scala plugin, but never got round to this in the F# plugin. It might be a useful familiarisation exercise if you fixed this bug yourself - just bear in mind that the spans that come from the F# compiler service parser really do obey that comment - in other words, the spans work slightly differently in the F# compiler services and Semantic Merge. If you read Scala, take a look at the Scala plugin, which is more developed port of the F# plugin - again, the Scala presentation compiler also has the same slightly different notion of spans, so the Scala plugin has to translate the spans - the F# plugin needs to have this fix back-ported into it. 3. What's definitely missing from the F# plugin is just a lot, a *lot*, more pattern matching on the various constructs of the abstract syntax tree - I stopped at the highest level, namely 'SynModuleDecl' for entire module constructs - what needs to be done is to decompose the sub-parts of the tree more to pull out classes and functions. Again, the Scala plugin does this and can be used as a reference, although I will say now that it's a lot easier to do this with the Scala presentation compiler than it was with the F# compiler services - but hopefully this may have changed on the F# side since I took a look. If not, it's a tedious but straightforward slog through lots of recursive pattern matching on the abstract syntax tree. I'm fairly sure that the F# source code formatter does exactly the same thing - I'd recommend taking a look at it, you may be able to either lift source code or even call it to do heavy lifting for you.
  12. Gerard Murphy

    How do you install use Semantic Merge plugins?

    Hi Nymaen - I'm the person who wrote that plugin - I'm glad you're taking an interest. You are right, I'm not actively developing that plugin any more, but please do fork the Git repo and take it further - that would be great. I'm happy to try to answer questions you may have in getting up to speed, so please post to this thread if you have more. Semantic Merge (and Plastic SCM) use a different configuration these days to incorporate external parsers - there was a post on the Codice blog not so long ago - see http://codicesoftware.blogspot.com/2015/09/custom-languages-in-semantic-version.html. That post is quite comprehensive - I use it myself for the companion Scala plugin, so on my machine I have the 'externalparsers.conf' file with contents of:- .sc=C:\Workspaces\Neptunium\target\neptunium.cmd .scala=C:\Workspaces\Neptunium\target\neptunium.cmd In this example, 'neptunium.cmd' is a self-executing JAR with a Windows command script preamble that runs the plugin on Scala files of suffix '.scala' and '.sc'. OK, that's for the Scala plugin - but you want to work on the F# plugin. In your case, you would build the Visual Studio solution from your cloned Git repository, the solution contains two projects:- 1. FSharpPlugin - this is the driver program that contains a 'Main' that is run from either Semantic Merge or Plastic SCM in the manner described by that blog post I referenced above. Its job is to run in a loop and process requests from either product, handing off a pair of input and output file paths to the 'real' parser that is provided by the library 'StructureDiscovery'. The input file path will reference some file (might be a temporary one, or might be part of your workspace - it depends on what you are doing in the GUI, the point is that it should be an F# source file), the output file path will be the path that Plastic SCM / Semantic Merge expects the plugin to write the transcribed YAML for that source file to. This is a very simple piece of code that is really a shim around the real parser. 2. StructureDiscovery - this is a library where the real work takes place. Right now, there is a single module, 'FileProcessor' in it, that contains an entry point 'DiscoverStructure' - this is what the driver calls. 'DiscoverStructure' uses the open source F# compiler services framework to build an abstract syntax tree describing the input F# source file. See here http://fsharp.github.io/FSharp.Compiler.Service for an introduction. It then transforms that syntax tree into YAML by recursive decomposition, starting with the function 'yamlForOverallStructure' that is applied to the top of the syntax tree. There is a bit of fixing up of the syntax tree that is done before that function is called - this is done with 'adjustSpansToCoverInputFile', this makes sure that the spans cover *all* of the text in the file without leaving any holes - you get these holes when you use an abstract syntax tree, it's the same for both the F# and Scala parsers. If you wondering what 'spans' are, read both the Codice documentation and the F# compiler services documentation - both use the same concept, although they have their own ways of representing them. Anyway, you build the Visual Studio solution, and the resulting command line executable, 'FSharpPlugin.exe' is what you'd refer to in the external parsers config file, so you'd end up with something like this:- .fs=C:\Workspaces\SemanticMergeFSharpPlugin\FSharpPlugin\bin\debug\FSharpPlugin.exe .fsx=C:\Workspaces\SemanticMergeFSharpPlugin\FSharpPlugin\bin\debug\FSharpPlugin.exe At this point, if you run Semantic Merge, it should pick up the plugin and do its stuff. I'm guessing that the SDK you refer to is either the description of the plugin protocol - see the first link above for that, or the F# compiler services - see the second. The Visual Studio project uses NuGet to pull down the F# compiler services dependencies, so that should work straight out of the box. If you run into problems with the configuration, the Plastic folks will definitely be able to help you, but I can also try to give you pointers. All the best, Gerard
  13. Gerard Murphy

    Missing YAML assembly when trying to use Semantic Diff in Plastic SCM.

    Thank you Manu - I can confirm that this has been sorted out in release 5.4.16.694 (In The Flesh). BTW - I've tried the latest Semantic Diff support in Plastic with my Scala plugin - it's awesome! I can now track those 'move class out of a file into its own smaller file' refactors that have always been a problem, as well as outright file splits. Roll on merge support...
  14. Hi, I'm using Plastic 5.4.16.691 (Beat It) on Windows 10. When I try to use Plastic's now Semantic Diff support, I get a pop-up stating that 'YamlDotNet.RepresentationModel, version=2.0.1.31095, Culture=neutral, PublicKeyToken=2b53052c5884d7a1' could not be loaded. I can't find that assembly in the GAC, nor in the directory that Plastic is installed in. As far as I can tell, the external parser (this is the Scala one mentioned on the Semantic Merge section) has completed its parsing successfully.
  15. Gerard Murphy

    Scala support

    Thanks for your encouragement, Manu - here's the latest screenshots, I think it is ready for people to try out (well, I'll be dogfooding it on my own code, anyway). I'm thinking of using Launch4J to package up the mess of Scala classes into a single executable - will make the configuration of Semantic Merge much simpler. Right now, it will detect renames and moves, and can cope with merging files with small syntax errors. I have tried some simple file rearrangements, these work too within limits. Looking good...
×