Yes, this is a really good idea. In fact we are already experimenting with it :-)
We will consider your specific suggestions!
Look, the thing is that in Semantic comments are linked to the next declaration. So, consider the following function:
// this is a comment
The comment is considered to be linked to the main function in this case.
Obviously for file-wide comments this is not good, so maybe we should add something specific to handle these cases.
Any thoughts will be appreciated.
Thanks Christian. We will take a look into it.
We are working on two sides here: one is adding native support for Plastic to Unity Cloud Build, something we are trying to move forward with Unity as I speak. Not sure when it will happen, though.
Second: we definitely want to add GitServer support to Plastic Cloud. In fact, it was the primary reason to have GitServer in the first place. But moving it to Cloud means refactoring some code, and we are still on it. We expect to have it in the next few months, we wanted to have it earlier but we got totally swamped.
Hi all, just in case you didn’t know, we just published a guide explaining how to write parsers for Semantic. Now it is possible to add any language you want :-)
Hi all, just in case you didn't know, we just published a guide explaining how to write parsers for Semantic. Now it is possible to add any language you want :-)
Please consider this suggestion https://plasticscm.uservoice.com/forums/15467-general/suggestions/8278431-preview-changes-for-changesets when implementing this. It is a duplicate of this one :-)
Hi Jan. Even clicking in the code section I'm unable to reproduce your issue. Look at the following video:
Please could you share with us some clues that can help to find what is happening? Really, thank you very much for your feedback!
Hi Chris. Thanks for your feedback. I tried to reproduce the issue that you're describing but unfortunately I was unable to reproduce it.
Here there is an small video that reproduces the behavior you explain, and it works fine.
Could you please explain give us some information about the issue?
Indeed one of the key things we must add soon.
Interesting suggestion. Dockable views are something we considered several times. They don't align that well on our quest for a simpler GUI, though.
Let's see if this request gets more votes from other users first :-)
Thanks for the remarks.
Did you know there was a time when Plastic had ways to show more than one view??
We never really manage to make people love it, though.
You can do what you are looking for if you use Visual Studio, since you can stack views freely.
What do you mean by "branch tab"? I mean, show the br explorer and then what on the right?
We can certainly add the "go to children" option in the Branch Explorer.
The BrEx is one of our strongest features, so I think we should focus on it. There are filters and subdiagrams to make it easier to understand. Onf of the weaknesses of Mercurial/Git tools is precisely the lack of proper visualization, IMHO.
That being said, I'm not against adding this info as properties on the changesets view, something added on the right panel. But while implementing it is not hard, there are tons of requests, so we should prioritize it. And we do based on votes from users and mixing it with our own personal view of the product evolution.
We will need this request to get slightly more popular to start working on it :)
Why would you like this instead of taking advantage of the Branch Explorer?
It is definitely an interesting suggestion.
Since it means a radically different way of displaying the changes, we should probably add it as an option. Options means introducing more complexity and... well, you know, always hard to deal with :-)
So, here is what we can do: this issue has 1 vote now, we can wait a few weeks and thing if it is something other users are interested on.
But once you click on the link, you see the extra info, don't you?
We have a big redesign of the entire code review stuff in progress.
So I take note of your request and add it to the list of notes.
Yes, it probably should.
Problem is that tracking the attributes which is what I think you are missing, or the labels, to check whether the replica should be fired or not, would greatly impact performance.
Not something we are against, of course, and we should probably find a solution that is fast enough and good enough.
We need to wait for users to vote it up, though.
Well, showing deleted files is not something I really like. Anyway, it is very easy for you to achieve: diff with an older version, find your file, and act from there.
This looks like a really great proposal. I discussed it with the team today and we really like it.
I will try to push it to make it happen soon :-)
Additionally, you should take a look at our 2D version tree. It is not the same as P4, but, well, we don't miss P4s feature having this :)
Hi Jan and all,
We just published the following in Facebook so we can continue the conversation about this topic adding images and so on :-)
So, to summarize: the merge link will just stay for information purposes so developers can see it, but wouldn't be used by merge-tracking, correct?
There is a way to achieve this and it is by deleting the destination changeset. You can delete it, then the merge link will disappear. Of course, only the last changeset on a branch can be removed, so if you want to "undo" a merge that happened a few csets back, you are not good to go.
How would you like it to be handled?
* Like "right click" on the merge link and say "delete"? That wouldn't undo the merge.
* Maybe a combination of subtractive + delete the original merge link? (this would "corrupt" history since it would be hard to understand why the originally merged cset was created.
* Maybe mark the "merge link" as "obsolete" somehow?? - this would do it.
If you can read and check the Triggers Docu, maybe we can close this request.
It works well for me... :-O
We already support before-checkin and after-checkin triggers, and they can happen both at client side and server side.
You can write them in any language you want, including C#.
So, not sure if we should discard your request.
Now, off-topic: the per-project settings issue you are facing is precisely why I always prefer to use NAnt or something similar to build releases, instead of relying on IDE settings. More often than not you end up with configuration issues due to these environments. NAnt scripts are the solution... Or something not touchable by hello-world-designed UIs :-)
Sure, we can do that. Not high prio, I'm afraid, since nobody ever asked for it, but yes, why not.
There's a fundamental issue with the cm find branch where name like 'release%'.
It works provided that the name of the branch (the actual name, nor its parents) matches the query.
Look at my command:
>cm find "branch where name like 'Release-%' and date >= '1 months ago'"
7616825 7/1/2016 11:01:19 /main/Release-220.127.116.111 jesusmg codice T
7621981 7/5/2016 14:14:38 /main/Release-18.104.22.1682 jesusmg codice T
7626620 7/7/2016 10:58:08 /main/Release-22.214.171.1243 jesusmg codice T
7632847 7/11/2016 12:52:16 /Fix-5.0/Release-126.96.36.1994 jesusmg codice T
7639164 7/15/2016 09:58:21 /main/Release-188.8.131.525 jesusmg codice T
7643011 7/21/2016 10:03:46 /main/Release-184.108.40.2066 jesusmg codice T
BUT, if you expect to search on the "parents" names, then it won't work. It doesn't because the query is run just on the branch name, nor its parents, because the branches just store their names, while parents are built looking up in the tree, so there's no easy way to SQL-it in a portable way.
In case of "changeset->branch" different happens. "cm find changeset where branch=" only allows "=" because the branch is resolved on the client side, and the id of the branch sent to the server. We do not allow multi-value entries there, I'm afraid.
So, your request actually affects 2 very different objects: branch hierarchy on one hand, and a way to solve specs on the other.
We never forgotten this, but we weren't unable to tackle it so far.
Hope this helps.
For reviews it always worked. Look:
C:\Users\pablo\wkspaces\four\01nerva\build\client>bcm find reviews where title like '%for%'
1653304 11/15/2012 10:40:54 ruben Status0 pablo "Review for SCM11714" Branch id:1628828
1654020 12/12/2012 10:31:06 ruben Status0 violeta "Review for SCM12064" Branch id:1653990
1756476 4/1/2013 10:08:49 ruben Status0 borja "Review for SCM12389" Branch id:1746241
1757256 4/3/2013 16:08:51 ruben Status0 borja "Review for SCM12448" Branch id:1746263
1781018 7/17/2013 14:46:50 ruben Status0 borja "Review for SCM12876" Branch id:1780995