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
Problem is that "private files" are not restricted to files you want to add. What happens with objs, exes, and all the intermediate compilation results?
If you have a perfectly configured workspace with everything private being ignored except what really needs to be added, then this solution will work, but otherwise it won't.
It can be a way to enforce that you don't leave files behind, and to force users to correctly setup their "ignored.conf", or Plastic will never let them switch branch...
From that angle, it looks doable and good :)
Are we on the same page?
Ok, not hard to do and definitely useful. Something like: ok, you can pull using Git but never push back.
Have you tried "semantic method history"?? Not sure if it does part of what you need already: http://codicesoftware.blogspot.com/2013/10/new-semantic-methodhist-is-now-out.html
"When using the "No-Checkout" workflow, it has been recommended to choose the option "Allow" or "Allow, showing a warning" for this setting"
Well, indeed, this is TOTALLY discouraged.
You should never leave changes behind unless you're really sure of what you are doing. What does it mean? If any of the files you left in your workspace with changes is meant to be checked in later on, chances are you will be in trouble if the loaded revision doesn't match the revision that should be really loaded.
This is because how merge tracking works. Merge tracking works on a changeset basis, not a item per item basis (as older versions and ancient version controls used to do). So, if a revision doesn't match the one that should be loaded on the working changeset, you can't checkin, because you would be overwriting newer changes and there's no way to merge them.
But, there are times when files that are not meant to be checked in (like config files, log configuration files, debug files, etc) should stay around during an update or switch to branch. That's why we have introduced this setting. It can be used for other scenarios but it requires a deep understanding of what is happening behind the scenes.
Onto more of your topics: scenarios (1) and (2) are exactly the same one, no differences.
Scenario (3) is what we call "update-merge" (also triggered by "2"): it basically makes sure you can go to the latest changeset, and moves the checkouts to the latest in case there aren't conflicts.
Anyway, thank you for the feedback. This is not a cheap change, initially, so let's see how interesting it is for the rest of users out there.
Synced with ... which server??
I can replicate my branches to several servers, so... it is not easy to say "which one is not pushed".
Why don't you just use the sync view for that??
Why don't you just CTRL-D on the file? Or do you mean in the "commit view"??
Why don't you just link your branches to an issue tracking system?? You get this out of the box :-)
Do you mean an icon on the repositories view? Or do you mean whenever the repo is displayed?
The tab you mention is the "workspaces view", not repos...
But why don't you use a replica? I mean, DVCS is superior by design to centralized development... That's where most of our effort goes. You just pull and then all connection issues are gone.
Well, we'll definitely not add a progress dialog for this, since we're trying to remove all extra dialogs from the GUI, but we'll definitely find a solution for the "hanging".
Now, onto your workflow: why are you using a server connected to the internet?? I mean, don't you work in distributed mode with a local repo on your machine to make every operation blazing fast?
Looks like this one is duplicated of https://plasticscm.uservoice.com/forums/15467-general/suggestions/7180704-to-have-the-possibility-of-add-general-comments-pe
We have a bunch of improvements to apply to the code review system, so I'll add this to the list.
Not sure if we'll implement it as you point, or if it is enough to add a single comment to one of the files for the same purpose, but we'll check.
Have you checked "semantic diff" integrated in the new releases of Plastic? It is able to skip even format changes.
Uhm... quite interesting indeed. In fact we're working on a bunch of improvements in diff, so no reason not to support this one...
What we'd appreciate is if you can sign up as a named user instead of "anonymous" :-)
Yes, that's correct, it is a current limitation, although I'm not sure how widely used transaction tables are.
If you need to replicate a full repo with translation, you can use the command line. You can automate the process, or you can do it in a single line using the new --clone (still not visible at this point, but already integrated in the product for a while) in cm replicate. Let me know if you need more info about this.
Yes, probably we shouldn't use icons at all on views. In fact that's what we're doing in both Linux and Mac, and Windows is expected to follow soon. They're just decorators created only for aesthetic purposes.
Now, onto your suggestion: yes, it is doable, but it will radically change how the view is implemented, it is just a query at this point, like all basic views, and it would have to be changed to something else. Interesting point, anyway, since actually showing whether the changeset is involved on a merge or not, seems to be a good idea.
The "cm find" translates the queries into sql queries. The branch only stores its name, not its parents, so this sort of query is not as trivial as it might sound.
We could solve the branch first and get its id and translate
name = '/main/task001/subtask_1'
on client by
and send that to the server... that would be doable.