Settings and activity
38 results found
-
0 votes
Hi Seto,
First of all, we’d like to thank you for your interest in improving Plastic SCM!
We’ve studied your proposal and we’ve found this new VersionOne functionality really interesting. However, it seems that they’ve selected only few version control systems to be natively supported, all of them web-based and build around Git.
Since the new CommitStream appears to be deeply git-oriented at the moment, we believe that it should be the VersionOne team who takes the initiative to decide whether they would consider to support other version control systems. We would be really happy to work with them and connect our systems, but we’re afraid that this request is beyond our reach :-(
We’ll wait for a while to see if there are some movement on their side and we’ll let you know if we hear something.
Again, thank you for your suggestion!
Regards,
MiguelAn error occurred while saving the comment -
60 votes
An error occurred while saving the comment 
psantosl
commented
Uh... good point!
An error occurred while saving the comment psantosl
commented
Yep, thanks for the suggestion, I miss it very often. In fact I normally add it manually to the slideshows whenever I have to do a training :-)
Problem is with big cset numbers, because they won't fit.
Let's see what we can do!
pablo - plasticscm
-
14 votes
An error occurred while saving the comment psantosl
commented
I'll see what we can do :-)
But look at the items menu... it is already way too big :-S
An error occurred while saving the comment psantosl
commented
Thanks Göran,
We're always concerned of overloading the menus with too many entries (and IMO there are already too many in the items view).
Frankly, this is not a common scenario: normally cloaked content stays cloaked and updating it is not frequent (or at least it shouldn't be), so we think the CLI is good enough for this.
-
41 votes
An error occurred while saving the comment psantosl
commented
Hi Göran,
As I said, I don't think it is worth the effort. Cluttering the GUI with options is a bad design choice, and while you now find it is a must-have feature, in a few months, once your old svn habits are gone, I bet you won't miss this anymore.
We'll keep it around as an idea, but at this point I'm reluctant to put development efforts on this.
An error occurred while saving the comment psantosl
commented
Thanks for the suggestion Göran :-)
We already discussed it by email, let's see what we can do.
You know that Plastic undoes unchanged transparently each time you checkin. So, no need to worry that much. You just go, checkin the files you modified, and Plastic takes care of undoing them.
It all depends on your workflow, though.
In my case:
* I edit some files, make changes, undo some...
* Then I checkin my changes to my branch.
* Repeat (checkins every 5 to 20 minutes).So, if I modified I file and I canceled the change, no problem, it will be gone on next checkin.
-
36 votes
An error occurred while saving the comment psantosl
commented
Wow, wow. Comparing the branch head to the master head will only work if all your merges come from "main", which I doubt will be the case under real circumstances.
BitBucket (the mercurial part or the git part??) probably does that because as a visual layer on top of a version control they can't do any better. But we do: have you checked this?? http://codicesoftware.blogspot.com/2015/02/using-history-to-better-explain-branch.html. This probably solves all your problems and is simply much more powerful than any other alternative available :-O
pablo
-
19 votes
An error occurred while saving the comment psantosl
commented
Hi James,
It is a good option to add.
I've been checking it with the team today. We'll try to work on it on a couple of weeks.
-
6 votes
An error occurred while saving the comment psantosl
commented
Hi John,
Well, the thing is that the parsers we use for .NET (C# and Vb.net) are not ready to handle C++. Roslyn can't handle it and neither the other parsers we used on Linux.
-
10 votes
An error occurred while saving the comment psantosl
commented
What you mean is some soft of multi-file semanticmerge which is something we're working on.
But, this feature requires a strong integration with the version control, maybe even building a full GUI client. Anyway, it will be dependent on the version control, so not a general solution for SVN, git, plastic and so on, but one custom one for each.
-
6 votes
An error occurred while saving the comment psantosl
commented
Hi Tom,
You mean being able to detect code moved between different files and things like that, right? We've multi-file semanticmerge for this in the works.
-
13 votes
An error occurred while saving the comment psantosl
commented
Well, semantic doesn't work at this level. It doesn't consider semantic diffs inside method blocks.
That being said, for C# there's an option to ignore "format changes" as the one you propose. Check http://blog.semanticmerge.com/2014/05/skip-format-conflicts-with-new.html
-
33 votes
An error occurred while saving the comment psantosl
commented
Why don't you just cherry-pick from the cset?? Ok, to be able to delete it, correct?
-
24 votes
An error occurred while saving the comment psantosl
commented
We've been discussing this feature with another customer last week too.
This is something we certainly have in mind :-)
-
6 votes
An error occurred while saving the comment psantosl
commented
Hi Diego,
This is certainly a great idea.
In fact we already had it in mind since our goal is to extend some of the semantic features to the pending changes view so it is capable of displaying the information in a more "semantic" way.
Didn't think, though, about using Semantic as a "comment generator" which looks like a clever idea :P.
A first step would be just printing the diffs in text format, don't you think so?
-
3 votes
An error occurred while saving the comment psantosl
commented
Hi Diego,
Can't it be done already through the plugin from the guys at RedGate software?
-
3 votes
An error occurred while saving the comment psantosl
commented
I'm confused about your last sentence: do you mean moving files to a different changelist so that you avoid checking in them at all?
Your main point: marking the cset as "unmergeable"... uhm... we could probably consider the "merge-from" permission cset by cset (at the risk of making the merge slower).
But what if you have a branch like this:
cset 0 - cset 1 - cset 3 - cset 4
You mark cset 1 as "non-mergeable" but then you try to merge from cset 4 ... should it let you merge?
-
39 votes
An error occurred while saving the comment psantosl
commented
Ok, you know you can do it for branches like this: cm find branch where name like '%task%'
But yes, when we introduce a 'reference' (like the branch in the csets query), then it is slightly different... We'll see what we can do
-
881 votes
We’ve started working on the Java parser!!
An error occurred while saving the comment psantosl
commented
We have a Javascript parser up and running, but we never made it public. We shared it once with this list. If anyone is interested... drop me a tweet @semanticmerge
An error occurred while saving the comment psantosl
commented
JavaScript is HUUUUGE. What would you guys recommend to parse JavaScript??
-
48 votes
An error occurred while saving the comment psantosl
commented
Yes, you're right. We should make it faster :-/. I'll check with the team in next sprint
-
9 votes
An error occurred while saving the comment psantosl
commented
Hi SWSBB,
I understand you can't use cherry pick from changeset either because your changes are not isolated on changesets, but spread through different ones, correct? And, also, I guess you can't pick just a set of changesets and cherry pick each of them because you made unrelated changes together on the same cset, right?
Well, the first thing here would be: please, checkin only coherent changes together, so that you can do clever things with them later on.
That being said: what you're asking for is 'history rewriting' (more or less), which is a pretty interesting point (Git implements this) but so far didn't fit our model.
I'd like to continue the conversation about this, so please let me know your thoughts here.
pablo
-
65 votes
An error occurred while saving the comment psantosl
commented
So, basically, it is just about files that:
1) can be changed
2) but won't be checked in at allIf they're not checked in, then of course they won't be merged, correct?
In order to avoid them to be checked in you can use several options:
* hidden changes -> so you just modify them but never checkin.
* a trigger -> to avoid certain file types to be checked inI still don't see what it has to do with merging.
An error occurred while saving the comment psantosl
commented
Well, basically what you're describing is not locking, what you're describing is that you don't want the file to be branched at all, correct??
I mean, as soon as you have several branches and you do not lock concurrently, you'll be able to branch.
You need "foo.max" to avoid any sort of branching, correct??
In order to do that the easiest is to implement a before-checkin trigger so that certain files can't be checkedin on any branch other than main.
Makes sense??
We read this and commented it before starting sprint 213... we'll see again what we can do in 214 starting on Monday.