Yes, you're right, the revision type information is cached on each workspace.
It means that the client first looks into the workspace tree, so it won't get the new filetype info until the file is updated with a new revision (or if the file is locally deleted and re-downloaded).
It is certainly inconvenient in many scenarios.
We need to make a change on this mechanism. Probably storing the file type is not so useful after all, and we can take advantage of the filetypes.conf mechanism and expand it as the single source of truth through the rest of the system.
If you switch to the latest cset of the branch, you can work normally, do checkins and everything. Just checked.
Nice one! In fact I've written query editors myself several times... days before the last ice age or so :P
We were also thinking on using some of the new textboxes to do autocompletion... which will be probably fancier for more coders.
Thanks for the great explanation.
Yes, definitely you made a point here. Not easy to implement, by the way, but it will sure add a lot of value to the product.
I'll keep you posted about it. We'll need to discuss it internally, but it is all a matter of timing, it definitely makes sense.
Although the more seasoned users already know this, keep in mind the situation is as follows:
* You add a file /src/foo.c on a branch, then make whatever changes to it.
* You add a file /src/foo.c on a different branch. They are totally different *items*, not the same one, not the same file or anything. They'll have different histories.
When you try to merge, they don't have a common ancestor, and the files can certainly be different.
One option is to use some sort of 2-way merge (yes, the kind of baseless merge we old hate from svn, where you have to solve every single conflict manually) and keep one of the two files with the 2-way-merged result while discarding the other.
This option would be relatively simple to implement.
The other option is to go and rebuild history, making the two files become actually the same item. This is a very hard problem, because while the simple case could be simple, it is full of corner cases as soon as you consider replication, partial replication, complex branch hierarchies and many more.
And I only covered files... directories would make the thing even more complex, because you could have full hierarchies inside, so, should you also recursively reconcile the children files inside using the same technique? Doable, yes, complex, yes.
I must admit I'm slightly biased against this, and that's the reason why it has been hanging around for too long, because we obviously use Plastic very intensively, and we almost never have this issue.
I don't think it will be something happening with code often, only, maybe with config files, and then... discarding one of them will be probably enough.
Would you guys be happy if we consider the first solution I exposed for files only? 2-way merge for the conflicting file, and keeping one of the two as the result.
* Use a tooltip box to display log message (and branch, date etc) when hovering the mouse pointer over a changeset/line.
** DISCARDED - info already displayed in the bottom area. No need to show a tooltip (hard to read since it disappears and hides the underlying code).
We appreciate the suggestions.
Yep, good-ol SVN wasn't able to handle branches decently but it made a good job "blaming" :P
We'll discuss this internally and try to implement it.
Really good idea! Thanks.
We'll try to apply your suggestion asap.
You can always check the "about form" to see the version number.
Or use: cm version from the CLI.
Interesting suggestion once again, thanks!
Again, scheduling it is a matter of handling priorities. It is a "nice to have" but not a "must" or something making the product stronger on a visible way, so we'll consider it on every sprint and depending on how much time left we have, we'll try to do it sooner than later :-)
We appreciate your suggestions, what you're asking is very interesting, but also very specific to your needs. We didn't detect such a need so far. We don't use it this way, and it seems others don't either.
Let's give some time for this request to go up and otherwise let's check again whether we should discard or not.
Explore changesets was inspired by this - http://codicesoftware.blogspot.com/2012/09/self-documented-development-through.html You checkin often and "telling a story" on each checkin and then you can help reviewers by following your same train of thoughts.
But, the same can't be applied to the full history of a file... because then you're not restricting changes to a file, but extending to the entire repo.
That being said, we should update the history view so that a diff is displayed on the same window.
We've just fixed this for Linux, where it was an issue for some releases.
Will this get the problem fixed?
Yes, I can tell you some users will find this extremely annoying. We just got an entry in StackOverflow complaining about how disgusting the confirmation after clicking "switch to branch" is. :-O
While I really appreciate this suggestions, please keep in mind this small points tend to be time consuming and steal time from creating big features, the ones that you can explain when someone asks "why is plastic better than X"?
Loved the idea!
Let's see when we can implement it :)
It should only work if the webui is configured... uhm... maybe we should add some sort of custom field so that users can build extra info to pass to the issue tracker somehow.
Other option is to write your own extension: https://www.plasticscm.com/documentation/extensions/plastic-scm-version-control-task-and-issue-tracking-guide.shtml#WritingPlasticSCMcustomextensions and then be able to tweak it as you need :-)
Creating branches from tickets already there! :-)
All good ideas.
While most of us prefer a branching convention, definitely creating a branch from a list of tickets looks like the way to go.
Would it be possible to merge them using Altova's XML merge tools? If so, automating the merge would be a matter of just a couple of scripts...
Not yet there, but hope you enjoyed this: http://codicesoftware.blogspot.com/2015/08/track-refactored-code-across-files-with.html
We've a few major changes at hand right now, but we'll get back to this to see what we can do.
Well, I don't consider it a bug but a pending feature, because it is not failing, it simply isn't there :-) (I mean, unless sync with SVN is also a bug :P).
Yes, this is a must... As soon as we finish a few open projects we have in the works, we'll work on this one. In fact I'm eager to get this done... it has been supported since Vista at least and we never took advantage of it.
Yes, not a bad point.
I don't specially love it because it means making the menu even bigger, which I don't like but...