Settings and activity
191 results found
-
3 votes
An error occurred while saving the comment -
3 votes
An error occurred while saving the comment While we evaluate this, what about taking a look into this? http://codicesoftware.blogspot.com/2014/10/how-2d-version-tree-works.html
-
3 votes
An error occurred while saving the comment Interesting. Not hard to add.
I really never miss this personally, because I don't really care in which cset I am provided I know the branch I'm working on.
Why do you actually need to know the changeset?? I mean, a number "per se" won't tell you much, but the Branch Explorer will, correct?? I always look the branch explorer to get this info.
Cheers,
pablo
-
1 vote
An error occurred while saving the comment Hi Johan,
Thanks for the suggestion.
A couple of questions though:
* You miss a "restart merge" inside our built-in merge tool, correct? Something like a button saying "restart" would be what you're looking for, right?
** Right now you can save without saving, then the merge will still be pending so you can restart it.* To restart an entire merge, what you have to do is undo all changes and merge again. I understand a "restart" would be good but it means it will undo changes... so we think it is better if the user actively does it, instead of just a "restart" which could be misleading.
-
5 votes
An error occurred while saving the comment If you want to keep your ignore.conf clean... then you shouldn't make mistakes adding what you shouldn't :P
We'll see what we can do.
An error occurred while saving the comment You can also right click and "remove from ignored list", then add to source control, correct?
-
6 votes
An error occurred while saving the comment It is an interesting suggestion, but I don't think we will implement it at this point. The entire GUI is (right now) built around the concept of the user refreshing stuff instead of Plastic doing clever things behind the scenes.
I personally hate tools that do things without being asked to do it, because they tend to end up killing your cpu or disk usage, or both.
-
13 votes
An error occurred while saving the comment At this point cloaked are not applied to the initial update (which is definitely something that could help in other cases).
You can add cloaked.conf to your repo, so everyone shares the same configuration.
I will double check again to see if we can find another solution.
An error occurred while saving the comment Ok, then there are several options:
* You can cloak the files, so the update won't warn you about them, and won't update its contents when you switch branches.
* You're worried about changing the files and triggering a build, but it will happen anyway when you switch branches with *other* files, correct?
* Or, you can always use shelves for this. It takes an extra step, but maybe you can have a shelve with your personal log and debug configuration...
An error occurred while saving the comment Jan,
Shouldn't these files be outside the version control? I mean, if they are autogenerated and everyone keeps their own, just delete it from version control, don't you think so?
We're just trying to figure out the best solution.
pablo
An error occurred while saving the comment Hi Jan,
Interesting, but this is a radical change in the behavior of undo checkout.
Question: what's your use case? You want to undo a lock or something? Otherwise I can't see why it is useful, I mean, why not leaving it checked out?
-
4 votes
An error occurred while saving the comment Thanks Göran,
Interesting idea. It would make listing repos way much slower, which would have an impact on customers with thousands of them, so we must be careful about this point.
-
6 votes
On the release 7.0.16.2077, we added the new server-side merge that extends the existing merge-to functionality.
Using the server-side merge, the file conflicts can be resolved and the merge resolution options (—mergetype, —keepsource & —keepdestination) are supported.
The server-side merge is still on preview so you need to enable it adding the following setting on the client.conf. Check how to do it on the release notes: https://www.plasticscm.com/download/releasenotes/7.0.16.2077
Remarks, the server and client version must be equal or newer than 7.0.16.2077 to use the server-side merge.
We comment option will be documented soon, we already plan a task to do it in the next few weeks. Sorry for the delay.
Best regards
Borja
An error occurred while saving the comment Ok, can then we discard this one and simply improve the merge command help?
-
3 votes
An error occurred while saving the comment Wow! Never thought it!
But it is useful for single lines only, right? I mean, side-by-side looks better for regular code blocks.
Look, right now we're redoing the mergetool. First we rewrote the diff tools (you saw now we have proper syntax highlight, folding, code completion and even semantic diffs built-in) and now we're on the mergetool.exe. One we have that finished we could definitely take a look at this.
I'll share this with our merge/diff experts and see what they feel about it :-)
An error occurred while saving the comment Hi Mario, could you please paste an snapshot of this WinMerge functionality. I tried it but I could not understand what do you mean. Thanks in advance!
-
1 vote
An error occurred while saving the comment Hi Marco,
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.
Thanks
-
7 votes
An error occurred while saving the comment Göran,
If you switch to the latest cset of the branch, you can work normally, do checkins and everything. Just checked.
-
5 votes
An error occurred while saving the comment Hey Göran,
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.
-
3 votes
An error occurred while saving the comment Hi Todd,
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.
-
175 votes
An error occurred while saving the comment 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.
Thanks,
-
47 votes
An error occurred while saving the comment * 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).
An error occurred while saving the comment Thanks Göran,
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.
-
4 votes
An error occurred while saving the comment Really good idea! Thanks.
We'll try to apply your suggestion asap.
-
65 votes
Plastic SCM 10.0.16.5668
https://www.plasticscm.com/download/releasenotes/10.0.16.5668Windows – Plastic: Auto-update!
Now you can update Plastic on Windows to the latest version from within the application itself.
When Plastic detects that a new version is available, the help panel will display a notification telling you which version is available. On the help panel is a link to download the latest version.
An error occurred while saving the comment An error occurred while saving the comment Hi,
You can always check the "about form" to see the version number.
Or use: cm version from the CLI.
-
3 votes
An error occurred while saving the comment Hi team!
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 :-)
Thanks!
-
4 votes
An error occurred while saving the comment Göran,
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.
An error occurred while saving the comment Thanks Göran,
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.
Not a bad idea... we also need to add the "default workspace path" to the config dialog. It is there on Mac and Linux but we didn't add it to Windows... (in order to avoid more GUI testing and so on).
While interesting, I don't really think this is high prio yet... so it will probably take a while.