Settings and activity
-
4 votes
An error occurred while saving the comment -
6 votes
An error occurred while saving the comment Not yet there, but hope you enjoyed this: http://codicesoftware.blogspot.com/2015/08/track-refactored-code-across-files-with.html
-
6 votes
An error occurred while saving the comment Good point.
We've a few major changes at hand right now, but we'll get back to this to see what we can do.
-
81 votes
An error occurred while saving the comment 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).
An error occurred while saving the comment 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.
pablo
-
4 votes
An error occurred while saving the comment 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...
-
1 vote
An error occurred while saving the comment Hi Jan,
I don't see the F5 issue, but I see you switch to the newly created wk and the items view (is this what you mean by "workspace overview"?) is not shown.
What do you mean by update it? Download to disk?
-
15 votes
An error occurred while saving the comment Yes, it is a good idea and in fact it is not a new one.
The only reason why we didn't do it yet is because it means breaking compatibility between client and server because it means adding a new field, so we're delaying it to group it with more changes once we break 5.4.16 (16 is the compat number) compatibility.
-
27 votes
An error occurred while saving the comment In https://www.plasticscm.com/download/releasenotes/5.4.16.656 we released the option to group repostories.
-
129 votes
An error occurred while saving the comment There is a setting to force everyone to be on the same version even if the older is compatible. You know we keep all 5.0 compatible and 5.4 has been keeping compatibility for a year already.
-
50 votes
An error occurred while saving the comment You're right and in fact we've a bunch of notes referring to how to improve it. It is on the top of the list now.
-
9 votes
An error occurred while saving the comment Do you know you can use another client.conf to achieve this?
-
3 votes
An error occurred while saving the comment Why don't you just start two different Plastic clients?? And move each of them to a different window?
-
7 votes
An error occurred while saving the comment Do you mean label colors in branch explorer, correct?
-
9 votes
An error occurred while saving the comment Hey!
While it is certainly a good idea, I wonder if it shouldn't be implemented through scripting. Thoughts?
-
6 votes
An error occurred while saving the comment Hi,
I guess you mean the one on the left, since the one on the right is typically the working copy, correct?
A slider is a good option for a linear history, but not valid for branches (not very comfortable) which is what you tend to use with Plastic.
The idea is good, but we have to find a way to make it happen.
Any additional ideas would be great.
-
13 votes
An error occurred while saving the comment This is actually something we have on the roadmap but has been postponed several times. It is not trivial but neither very difficult to do.
What we have in mind is to have something like: split repo A into different subrepos, creating new ones.
-
106 votes
An error occurred while saving the comment Yes, you're right. We have to work on a major rewrite of the code review system, adding extra features, making it more usable... and supporting the review of xlinked revisions :-S
-
23 votes
An error occurred while saving the comment Are you using the latest versions of 5.4 and 5.0? Because now you can drag from Plastic to the explorer.
But what you're pointing is different, isn't it? You would like to add a file to the pending changes view?? Please clarify
-
59 votes
AdminCodice Software (CEO / Founder, plasticscm) supported this idea ·
-
9 votes
An error occurred while saving the comment Hi Robl,
Do you know why we show the "U" marked revisions, correct?
The thing is that the merges happen between changesets, not between revisions, and hence you can be merging changeset 104 which contains a revision from file 'foo.c' which was created in cset 100, and then 101, 102, 103 and 104 are marked with a "U" because the file wasn't modified there, but the merge happens between 104 and the destination cset. Is that clear?
Hi!
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...