psantosl

My feedback

  1. 0 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →

    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,
    Miguel

    psantosl commented  · 

    We read this and commented it before starting sprint 213... we'll see again what we can do in 214 starting on Monday.

  2. 50 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    Uh... good point!

    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

  3. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    I'll see what we can do :-)

    But look at the items menu... it is already way too big :-S

    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.

  4. 26 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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.

    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.

  5. 27 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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

  6. 19 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  semanticmerge  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  7. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  semanticmerge  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  8. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  semanticmerge  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  9. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  semanticmerge  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  10. 13 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  semanticmerge  ·  Flag idea as inappropriate…  ·  Admin →
    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

  11. 27 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    Why don't you just cherry-pick from the cset?? Ok, to be able to delete it, correct?

  12. 18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    We've been discussing this feature with another customer last week too.

    This is something we certainly have in mind :-)

  13. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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?

  14. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    Hi Diego,

    Can't it be done already through the plugin from the guys at RedGate software?

  15. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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?

  16. 37 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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

  17. 875 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    19 comments  ·  semanticmerge  ·  Flag idea as inappropriate…  ·  Admin →
    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

    psantosl commented  · 

    JavaScript is HUUUUGE. What would you guys recommend to parse JavaScript??

  18. 48 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    Yes, you're right. We should make it faster :-/. I'll check with the team in next sprint

  19. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    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

  20. 49 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    14 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    psantosl commented  · 

    So, basically, it is just about files that:

    1) can be changed
    2) but won't be checked in at all

    If 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 in

    I still don't see what it has to do with merging.

    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??

← Previous 1

Feedback and Knowledge Base