David Yang
-
Posts
31 -
Joined
-
Last visited
-
Days Won
1
Posts posted by David Yang
-
-
Not sure if you're still working on the GUI redesign, but wanted to share some thoughts.
Left side panel
Please keep this, at least as an option. Most IDEs/editors default to some kind of left panel for navigation (eg, Visual Studio, VSCode, and I think Unity as well), so a left side panel is something that will be familiar to both existing/new Plastic users.
Tab system
Agree that the current GUI opens too many tabs.
To be honest, I am not quite sold on the benefit of tabs for the primary views. It is just as easy to click Branch Explorer or Pending Changes on the left side panel than it is to click an already open tab (in fact, it is easier since the button is bigger and more visible). Similarly, CTRL+1/2/3 is just as easy as Alt tabbing.
I think the main benefit of tabs is easier to resume views that are more difficult to get to, eg anything you need to get to via the right-click context menu, etc.
So, I have got 2 alternative ideas for a better tab system:
-
Option 1: Similar to the approach used by VSCode. All tabs are reusable (ie, the tab changes when you navigate away rather than opening a new tab), until they are either "pinned" by the user or because there is unsaved data on the tab (eg, partly resolved merge conflicts).
- Option 2: Primary views (eg, those on the left panel) reuse the current tab. All other views (eg, those you get to via a context menu) open in a new tab. This is similar to the approach taken by a photo management software that I'm using, and it generally works pretty well.
Other GUI issues
In general, I don't think the current GUI is too bad. The main initial hurdle I think is understanding what all the words mean, since Plastic uses different terminology to other VCS.
If you are going to redesign the GUI though, here are a few other changes that I think would help new user on-boarding, and also some other changes that I think would benefit everyone.
For on-boarding new users
-
More consistency between views. Some views have an "option" button (eg, pending changes), whereas others have options buried in a side panel (eg, branch explorer).
-
"Forever" option for "Since" field in branch explorer. Should probably be the default option for new repos. I remember when I was a new user working my way through the "getting started" guides, this tripped me up because the training repo is very old, so by as a new user you are greeted with "no data found" until you figure out the problem. Not the best introduction for a new user.
- More universal help/info icon. Eg, a question mark or "i" with a circle around it. I had no idea what the current "soccer ball" was supposed to do at first.
For all users
-
Easier ways to add attributes to branches/csets. Currently it is buried in the side panel. Maybe combine the attributes and properties side panels so you can view/change comments and attributes on the same screen, and/or add a way to add attributes in the right-click context menu (without having to create an external tool command first.
-
Ability to customize some columns. Eg, add labels column in the csets views. Or ability to make the description column only shows text before a line break (for those of us who are used to writing Git commit messages with a "subject line" and "body").
-
Keep line breaks in hover tool tips. Sometimes I will format checkin comments with bullet points, etc. The line breaks are not kept in the hover tool tip. Similarly for the description at the top of the diff window, very small and hard to see.
-
Show clickable links when descriptions reference other objects. Similar to the "review scripts" idea that you mention in your blog. Ideally, the plain text should reference the GUID (so links don't break if branches/labels are renamed, or if csets are replicated with a different number), but have the GUI display this as a clickable link showing the friendly name instead.
-
Code review status in branch explorer. I think this has been a top-rated uservoice request for a while now. Currently, would have to use triggers to apply attributes and conditional formatting, but an icon would be much nicer.
-
Option to show attributes in branch explorer. Conditional formatting is nice for most things, but sometimes it would be better to be able to see the actual attribute details.
-
Some tweaks to branch explorer diagram. Mostly one of the best parts of the GUI experience, but a few small nits:
- Lots of crisscrossing arrows can look messy. Eg, when starting a branch from an older cset on main. Maybe the gmaster arrow style would look nicer here? I also remember there was an older forum thread on different ideas to sort branches (eg, keeping parent and child together, instead of sorting top level first).
- Label names on child branches sometimes get hidden by the branch name. Maybe have label names render underneath the branch instead?
-
Independent label drawing: I think multiple labels on the same cset are currently just rendered as one shape, so can't conditionally format those labels differently.
Kind regards
David -
Option 1: Similar to the approach used by VSCode. All tabs are reusable (ie, the tab changes when you navigate away rather than opening a new tab), until they are either "pinned" by the user or because there is unsaved data on the tab (eg, partly resolved merge conflicts).
-
Hi Pablo,
Was revisiting this thread because I was helping another member, and just realised the question I had about "checkin with reviewers in mind" didn't seem to get posted to the blog (I think it got lost in the approval process somewhere).
Was still hoping to pick your brain on that if you don't mind?
Anyway, the question was - I really like the idea of methodical checkins, but I find in practice I often don't "get it right the first time". Eg, sometimes I won't realise until after a few checkins that there is a problem with my approach, and I have to change course a bit, etc. I've come up with a few ways to deal with this, but each have their issues:
-
Don't checkin until I'm almost finished with the task and sure that everything works. But this kind of defeats the purpose of "checkin often".
-
Checkin often, and if I make a mistake or change my approach, go back and edit the comment in the original changeset so it's clear that the approach has changed, etc. This works if I'm working centralised (which I've started doing because of this), but push/pull doesn't handle editing comments well as I mentioned here: https://forum.plasticscm.com/topic/21698-love-the-recent-changes-some-thoughts-and-suggestions/
- "Checkin" often, but use temporary shelves instead. Then, when sure everything works, recreate the steps and checkin properly. But this approach creates a lot of rework for the times that I do get it right the first time (which is hopefully, more often than not).
So was wondering what you guys do? Or perhaps, you've all gotten really good at just getting it right the first time?
I was reading the most recent Release Notes about the new Incoming Changes feature, and it sounds like you might already have the code to allow some basic "rebasing" even when working centralised. Perhaps you could leverage that somehow to allow people to amend/rebase/combine changesets on task branches before submitting for code review (to reduce the pressure to get things right the first time)?
Obviously it wouldn't be a good idea to allow changing history on main branch, but often only 1 or 2 people work on any given task branch. So perhaps there is a way to "lock" task branches for editing (at least those that don't have merge links), so that you can do whatever you want to your task branch without affecting other people and their task branches?
Best,
David -
Don't checkin until I'm almost finished with the task and sure that everything works. But this kind of defeats the purpose of "checkin often".
-
3 hours ago, jwvanderbeck said:
Yes I am working solo at the moment. To some it may seem silly to use tools like Jira and Plastic when all alone but I appreciate the structure it gives me, plus it lets me expand easier later in a project if necessary.
Haha yep, pretty much same as me so I totally get where you're coming from
.
At the start, I spent a lot of time trying different issue trackers too, including Jira, YouTrack, HacknPlan, Azure DevOps, etc. But the self-hosted versions all had pretty high system requirements (no chance of running on a free/cheap AWS server so that I could access from home and office), and with the cloud-hosted versions I didn't like the idea of locking myself and my data into another product subscription.
(I was happy to pay for Plastic SCM because I liked it so much more than Git and its diff tools are quite helpful even for checking own work, but I was less keen to pay the same or more for essentially a glorified todo list!)
So that's how I ended up with the approach I describe above. It also keeps everything in one place so I don't have to worry about having my data stuck behind different product subscriptions. Definitely good enough for solo dev, but should also be workable for small teams as well.
In case you or others are interested, @psantosl and I actually had quite a long discussion about Plastic, issue trackers and keeping track of the bigger picture (see forum thread below). In the second last post, Pablo makes a good points about why he prefers simply mapping out big features in a cheap list "in a text file, an excel, whatever". It's actually what got me to ditch using an external issue tracker - if I'm going to use a text file / spreadsheet anyway, why not just keep it inside the repo and track task progress there!
Anyway, hope some of that helps. And if you come up with something different that you think works well, I'd be interested to hear about it too!
-
Ah, sorry I missed the part about the Jira plugin (I'm not familiar with the plugin, sorry - I played around with the plugins when I first started but soon found it easier just to manually name the branch and copy the description, etc).
I think Option 1 could still work for Windows, but you'd need to make sure Jira task titles contain the relevant prefix going forward.
10 hours ago, jwvanderbeck said:On Windows it displays the Jira Task title but that is often long so doesn't fit very well in the display as most branches are shorter than the "info" lol.
Are you working solo or with a very small team? I've had this same issue before, but that was on a solo project where each task was fairly short and I didn't have concurrent checkins from other people to "lengthen" my task branches.
This is the approach I came up, which might work for you as well if you only have a few people working concurrently:
-
When creating a new task branch, immediately create a new checkin adding a plain text file called 'task-info.txt' or something. This file can contain all the info that you would put in the bug tracker. You can also do a checklist style approach, eg:
<Title> <Description> Requirements: - [ ] requirements or sub-tasks needed to complete the task - [ ] ... Review: - [ ] things to self-check/test at the end before merging or submitting for peer review - [ ] …
-
When a requirement or sub-task is completed, mark it as complete in 'task-info.txt' and checkin together with the relevant code changes. Eg, while working on a task, if I've finished requirements 1 and 3, I would also update 'task-info.txt' and check that in as well:
Requirements: - [x] requirement 1 - [ ] requirement 2 - [x] requirement 3 - [ ] requirement 4 - [ ] requirement 5
-
After completing the task, go through each self-check items and mark as complete in 'task-info.txt' as you go. When all self-checks are complete, checkin the completed 'task-info.txt' as the final checkin before merging or submitting for peer review.
- Finally, when ready to merge back into main, delete 'task-info.txt' (after processing the merge but before checking in the merge). Pending Changes view won't let you delete the file, but you can delete it normally from File Explorer and it will let you checkin on the second attempt. This way, the task info is preserved on the task branch, but doesn't pollute main branch.
What I liked about this approach:
-
Keeps everything together in one place and saves on setting up / maintaining a separate bug tracker (if you have a very small team and don't need a lot of coordination).
-
Easy to check that you've done everything you need to, and helps prevent some basic errors that I found I kept repeating (if I found I kept making similar mistakes, I'd add it to self-check list going forward).
-
Easy to update a task with additional requirements, etc 'mid-task'. Simply update 'task-info.txt' and checkin. It's impossible then to forget about these requirement changes as you'll see them before making the final checkin. With the new ability to colour code changeset/labels by attribute/etc, it's also easy to distinguish actual changesets from task info changes
- Branches are at minimum 3 changesets long (two for the initial and completed 'task-info.txt', and at least one with the actual content), which I found long enough for most task descriptions to show up.
-
When creating a new task branch, immediately create a new checkin adding a plain text file called 'task-info.txt' or something. This file can contain all the info that you would put in the bug tracker. You can also do a checklist style approach, eg:
-
@jwvanderbeck I do something similar with assigning branches a category and there's 2 ways I've found to have that show up in Branch Explorer without using colours:
- In the right hand pane where you can select Display Options, there's an option to 'Display branch task info' which displays the branch description (comment field) after the branch name. Eg, you could have a branch named 'task0001' with its description/comment as '[feature] implement cool new feature' and both will show up in Branch Explorer.
-
Alternative option if you can't use the above, is to use a long branch name. Eg, you can name the branch something like the following. This works fine if you just use GUI/scripts, but not a great idea if you use 'cm' console command to do stuff with branches...
task 0001 | [feature] implement cool new feature
-
1
-
Hi Pablo,
Probably confusing because of different terminology to Git, but when @jwvanderbeck talks about "local state", I think he means seeing if there is any differences between the local repo and remote repo (DVCS), rather than seeing if there are local workspace changes compared to the active changeset (which is I think what Pending Changes and cm status show you).
For push/pull distributed mode, from memory the "Sync repositories" view shows you which branches differ between the local/remote repos (source and destination repos in Plastic parlance). At least that's what I remember, I haven't used distributed mode in a while.
For direct checkin centralised mode, the release notes for the latest version talk about a new "Incoming Changes" view which I think will tell you if there are new changesets in the active branch (https://www.plasticscm.com/download/releasenotes/8.0.16.3636).
David
-
Hey guys,
I've had more of a chance to play around with the code review system now. Love it!
I think you guys have done a really good job making it so user-friendly. Love being able to quickly see which questions / change requests are still pending and double-clicking to the correct diff. Great job guys.
A few minor bugs I've noticed:
- The "Close change requested in review" dropdown isn't showing up for me in the Pending Changes view, even when there are active change requests (latest Windows version)? Can still close change requests by typing the comment manually though...
- The "Review entire branch" mode doesn't refresh when a new changeset is created. The bottom review pane and the "review changeset by changeset" mode do though 👍
- The Code Review view highlights "rework required" code reviews in green (I'm guessing this is a new status and someone forgot to change the if-statement for the highlighting 😜)
Some minor improvements that would make the experience even better:
-
Automatically change code review status in some cases, eg:
- Change to "rework required" if a new change request is made.
- Change to "pending review" if a new changeset/question is created after already marked as "Reviewed".
-
Since Branch Explorer is the main view, it would be great if there was better integration of the code review system with this view, eg:
- "Display option" to show some kind of visual indicator of the code review status (eg, not created, pending, etc) and number of open questions/changes
- A way to easily open an existing code review from Branch Explorer, eg either from right-click menu or by double-clicking (perhaps if a pending code review exists for a branch, launch that when double-clicking the branch rather than the branch diff)
- Prevent changes to code review comments once a branch has already been merged to main. (But unlock the code review if a new changeset is created on the branch after merge - not the recommended approach, but in case anyone does this.)
- Only semi-related but noticed this when playing around with the new attribute default values (thank you!!! and can finally edit attribute comments 🤣). Colours automatically update when applying new conditional formatting rules, but not if just changing attributes (have to manually refresh the view). Can you make it so changing attributes automatically triggers a refresh?
Lastly, is it safe to start using the new code review system for actual repos? In your latest blog posts, it says it's still a prototype and so comments won't be stored. But they seem to be stored just fine for me? Or is there a possibility you'll introduce some breaking back-end changes down the track?
Great work guys, loving all the recent useability changes 😘
David
-
Hi @psantosl and team,
Super excited to see all the improvements you've been making lately, especially the new conditional formatting of changesets/labels (yay!!! 😘) and of course the new code review system!
My time's been taken up with some other things these last few months, and I haven't had much time to play around with Plastic unfortunately (or coding in general for that matter), but I've been keeping an eye on the regular release notes and can't wait to get back into things soon.
I had been keeping a small list of thoughts and suggestions when I was playing around with different workflows, and more recently when reading up on the new code review system, but it looks like you've beaten me to a lot of those already (like conditional formatting of labels/changesets, and hiding non-question and non-change code review comments to give more screen space)!
So since you guys are moving much faster than me, I thought I'd share some of the thoughts that I've had for some time now, in case any of it is helpful. I've been reading the release notes diligently, so I don't think any of these have been implemented already, but apologies (and great job) if you already have!
-
Updating changeset comments in DVCS scenario
I have an unfortunate habit in that I often check in something and only realise I made a mistake a few changesets later (I'm sure I'm not the only one 😜). Colour coding changesets is great for warning about these "bad" changesets (thanks!!), but another thing I like to do is edit the changeset comment to identify the error and which changeset it was fixed in, eg I used to add something like this to the end of the comment: ERROR: forgot to update comment to reflect changed code. [Fixed in cs:1234]
In many ways, I think this is very similar to the "review scripts" feature you guys are implementing for the code review system (which I really like by the way), eg [refactor: Check how I extracted the method and changed order: BranchExplorerLegendItems.cs : left:167-174@cset:170, right:180-187].
The issue I've come across is the way that edited comments are handled in DVCS scenarios. It's fine when working centralised, but with push/pull model it doesn't check whether comments have been changed - presumably this is for performance reasons as changeset history is not stored so there's no easy way to tell if a comment has changed?
I imagine once "review scripts" become a thing, more people might want to tidy-up changeset comments ahead of reviews (rather than having to get it right the first time - which I often don't, especially if I've had to change my approach because there was an issue I didn't anticipate). I have changed to centralised model because of this and that's ok for me, but others might prefer to stick with distributed model.
Ideally, the ability to track and diff comment history would be neat - perhaps using a simplified revision tree for comments but without needing to worry about branching/merging etc. I think possibly that might be more performant than checking all changesets in br:main/ for comment timestamp (yikes!), but understand this would probably require non-trivial architectural changes...
-
Review script cset numbers in DVCS scenario
On a related note, an issue I anticipate with specifying csets in "review script" comments is that cset numbers can vary between replicated servers. Not sure best way to fix this since specifying GUID would be long and ugly...
Something that I was doing before (and which might help here), is to basically label every meaningful changeset, even on task branches. (The reason I was doing this is because I was trying out this approach where I'd track, inside a text file, a list of things that needed to be done/checked/tested before the task branch was allowed to be merged into main. Changesets with actual changes would be labelled, but changesets that just updated the checklist because I'd thought of something new would not be labelled. By the way, I'd then delete the text file when merging so main branch wouldn't get polluted with all these checklists - I'd have to delete the file via File Explorer and the Pending Changes view would pop up an error, but the merge would work on the second try.)
Reason I mention this is because referring to labels neatly gets around the inconsistent cset number issue. Another benefit of this approach is that label names show up in Branch Explorer, so it's easy to see at a glance which changeset is being referred to in a comment, etc. The convention I was using is "M-1" for changeset 1 on main and "2-1" for changeset 1 on task branch 2 - which is easy to understand and reference. (The new conditional formatting for labels is great for this by the way, as it means you can easily distinguish between these "regular" labels and "release" labels 👍)
Related GUI issue: label names on child branches often get hidden by the task branch name in Branch Explorer. Perhaps move the label name so it appears below the changeset/branch (rather than above, which is where the branch name goes)?
-
Preserve line break formatting in multi-line comments
Something I already have a lot of, and think will be used even more once "review scripts" are standard (eg, you give the following example on your blog):[file: Simple.cs] Contains the redesign of the calculation. [file: Calc.cs] Contains the code extracted from BaseCommandsImpl. [group: Just method renamed: Bar.cs, Foo.cs, BaseCommandsImpl.cs]Currently (or at least last time I tried), line break formatting is discarded in the popup when mousing over changesets in Branch Explorer, etc. It is also very hard to read multi-line comments at the top of diff windows (although I understand that is probably done to preserve screen real estate).
It would be great if both the formatting and "clickability" of review scripts is preserved in all places where comments are displayed (not just the code review window).
-
Server-side trigger for "on comment update"
Related to suggestion 1 above - would be helpful to be able to create a trigger that automatically applies an attribute if a certain phrase is added (eg, [error: …]). Less important now that I've recently discovered you can create custom "External Tools" to apply attributes (http://blog.plasticscm.com/2019/06/archive-branches-in-plastic-scm.html), but before it was a real pain having to navigate to the "Attributes" side panel each time.
As an aside, why not combine the "Attributes" panel with the panel that shows/edits the comment field (which is the panel I usually have open so I can see comments easily)?
-
New trigger exit code that warns user and gives option to proceed or cancel
Came up with this one with @manu a while back. For client-side "before checkin" trigger, I was able to create a simple powershell script that pops up a window and gives user option to proceed or cancel (returns exit code 0 or 1 depending on which button user clicked). This is useful for warning about some things that are usually bad (eg, trailing whitespaces, weird characters in file names, etc) but which might not be appropriate to enforce in all cases - hence warning the user and giving them the option to proceed or cancel.
The above is the most important use case, but it would also be helpful for some server-side triggers (eg, checking comments when something is created/updated). Perhaps returning a new exit code 2 or something could make the Plastic client pop up a window that lets you proceed or cancel the relevant action?
-
Add "labels" column in Changeset View
I know we Plastic users don't use Changeset View much, but I still find it useful occasionally when I want to see a quick summary of recent changes on main branch (probably a leftover habit from Git 😜). Being able to see the labels would be helpful in this situation.
On a related note, either adding an easy "show main only" toggle button or making the Changeset View remember the filter would be helpful (last time I used Plastic, it wasn't remembering my filter so I had to keep manually typing it out each time).
Thanks again guys for continuing to make Plastic better and better. Love what you guys have been doing!
David
-
Updating changeset comments in DVCS scenario
-
Hi @tucny,
You can create a top-level branch from any changeset using the command line (I don't think you can specify the changeset in the GUI though). This means you could create a new top-level branch from changeset 0, and it would be empty.
See this forum post:
Obviously being in the same repo means making changes to V2 will increment changeset numbers for V1 (not sure if you care about that).
Alternatively, you could do a hybrid approach of what Pablo suggested. Replicate the entire V1 repo into a separate V2 repo. Then use the above approach to create the top-level branch from changeset 0 (inside the new V2 repo, keeping the V1 repo unchanged).
Kind regards
David
PS: I personally label all changesets on main (eg, label M-1, M-2, M-3 etc), which you can automate with triggers. I find this easier than referencing cs:id numbers, which aren't visible in branch explorer and which can also differ across replicated servers when working distributed (meaning you have to refer to them by GUID, which is not easy to read or type).
Main downside is it makes things look a bit busier, and if you use labels for releases then those no longer stand out as much (unless the Plastic team also introduce the ability to colour code labels and/or changesets by attribute or custom filter rules *wink wink nudge nudge* @psantosl).
-
1
-
-
Hi Pablo
Thank you very very much for taking the time to share that. Lots of good wisdom 🙂
You make a very good point about not assigning task numbers / entering into issue tracker too early. In that case, I guess it is not much more work to enter the task number manually into the planning document/list once ready, since the plan will probably need to be updated to reflect the current thinking anyway.
And yes, I guess you could just sort/filter tasks by a custom field or prefix to get the list of tasks for the big feature/thing. (Nothing wrong with prefix btw 😜! When I was using Azure DevOps, I also just used prefixes like [bug], [feature] or [doc] instead of using a different work item type for each type of task.)
The "live" updating of tasks with Confluence or HacknPlan is still nice, but on the other hand as you say, something simple and vanilla has the advantage of just "always working" without extra setup. I might have a play around with OneNote for design/planning instead - I've never used it before but looks like you can organise pages like wiki and collaborate both real-time and offline. And it has the benefit of being included free with Windows, no setup needed...
(I used to hate all the bloatware that comes with Windows so I had uninstalled OneNote without trying it, but maybe I should have given Microsoft more of a chance - been playing around with Edge browser recently and it actually has some pretty nifty features! I'm typing this in a Windows Defender Application Guard sandbox right now - not because I think your forums are dodgy and malware infested, but because I'm playing around with a fresh OS install and haven't installed antivirus yet 🙂).
Thanks again for all your help and suggestions!
(PS: While I'm picking your brain, I also had a quick question about your blog post on checkin with reviewers in mind, but I'll post that to the blog comments. Thanks again!)
-
Hmm yeah, you're right. Simple is best. I got drawn in by the prospect of a cheap/free perpetual license - which would have been really nice - but it's getting to the point where I just need to pick something... anything... and just get a move on!
Do you mind me asking how you organise/track tasks in the context of a bigger picture design goal? What I mean is, take for example your designs for the new code review system - now obviously that would involve a very large number of bite-sized tasks to implement incrementally. How do you (a) make sure people keep the overall vision in mind while chipping away at the individual tasks, and (b) track progress of the overall feature?
I'm not sure what you think of this article, but I stumbled upon it while looking into issue trackers, and that's what initially got me excited about using either HacknPlan or Confluence+Jira. Both allow you to create a moving/living design vision by organising pages (which could contain anything from detailed requirements to UI mockups or just rough notes/ideas) into a tree. Then you can link tasks to those design pages, so people working on a task can easily see how their task fits into the bigger picture. And similarly the design page shows the live status of all linked tasks so you can quickly get a feel for how the overall thing is progressing.
It's this bringing together the macro and micro that has me a bit stuck. If it wasn't for this, to be honest I probably wouldn't even be thinking about something as powerful as Jira. Almost any issue tracker would do - heck even google docs would do! (As you say, Plastic works well just using "naming convention" for tasks/branches, and the benefit of simple vanilla is that it always "works" without having to maintain software/subscriptions/plugins/etc!!)
-
Señor Pablo - are you trying to get my hopes up by bumping this old thread? 😜
You will not believe the roller coaster ride I've been through these past few days trying to get a good issue tracker up and running alongside Plastic (it's kind of necessary for the task branching workflow you keep banging on about!)
- First got excited about your Spanish compatriots at HacknPlan (which you could probably tell from my rambling email) - linking tasks directly to the design model seemed like a really neat idea (and good way to keep the bigger picture in mind while picking away at tasks)! 📈
- But after using it a bit more, I realised it was still pretty "new" and missing some important features, which made it difficult to use it for maintaining several small projects... 📉
- Then discovered Confluence - which combined with Jira would also allow organising tasks under a design document tree. And only $10+$10 perpetual license for self-hosted small teams! 📈
- So tried setting up an entry-level Azure Windows VM, and almost gave up because it was unbearably slow (even with nothing installed and full bursting credits)... 📉
- Then someone suggested I try AWS instead, and the comparable entry-level Windows EC2 instance was pretty snappy! Installed Plastic SCM no problems and even working centralised (direct checkins) was pretty fast! 📈
- Then tried installing PostgreSQL + Jira + Confluence and it absolutely crippled my EC2 instance. Oops, forgot to check the system requirements for Jira + Confluence. They need HOW MUCH RAM??? EACH?? Checks price for an EC2 instance with that much RAM... 📉
- As a last attempt, learned how to set up a Linux EC2 instance with SSD swap file in hopes that maybe that would work better. Get a minimal GUI and XRDP remote desktop running in Centos despite never having used Linux before - pretty chuffed! 📈
- Then tried installing chromium so I could use web admin tools. Takes several minutes to load. Uninstall and try Firefox. Same... (What? I thought Linux was meant to be lighter and faster - even Internet Explorer on Windows server was very fast and responsive...) 📉
- (Seriously contemplated going back to one of the all-in-one Git solutions and just getting on with my life...)
- (... but I like Plastic too much 😔)
- Finally this morning found Jetbrains' YouTrack. Similar to Jira in many ways but easier to setup and "only" needs 1.5GB RAM. No Confluence-style linking of tasks to design model, but self-hosted version is free for small teams and at least on my EC2 instance it's... responsive. Kind of. Is this the answer then? Time will tell.
If you thought that was painful and long just to read... (you and your branch-per-task workflow *shakes fist*)
So as you can see, surprisingly, by far the hardest part of moving to Plastic SCM isn't directly related to Plastic at all! Plastic Server was an absolute breeze to get up and running (thank you btw for making Plastic Server so easy to set up and so gentle on system resources!! Why can't all software be like this!)
PS: But yes, despite the above, also starting to realise why you wanted to focus on SCM and not have to worry about maintaining an issue tracker product. Such a saturated market these days!!
-
Update 24 Jan:
Found a potential solution. Just found out that FogBugz (now called Manuscript) is free for up to 2 users with free hosting on their servers. It's pretty hidden though - they don't seem to advertise it anywhere on their site except in the FAQs - which makes me a bit nervous about whether they intend to keep offering it. The next step up is $75/month for 5 users 😨
As long as the free offer remains though, it would be a viable solution alongside Plastic Cloud (for those who don't have on-prem / VPS). Personally though, I am probably going to stick with Azure DevOps' issue tracker (I prefer its simplicity) and just live without the integration or ability to link issues with changesets/branches. Or go old school and just use a spreadsheet.
(Reason being that I really dislike having my data locked into a proprietary format that requires an ongoing subscription. So far Plastic SCM has been my one and only exception because (a) it is so much better than everything else that I'm not worried I'll want to move to another product in future, and (b) worst case scenario I could always push my Plastic repos to Git - though the only conceivable reason I'd ever do that is if Plastic became crazy expensive, but you would never do that to us right 😘?)
But thought I'd let you guys know about FogBugz in case it helps anyone else.
David
@psantosl - I still stand by my above comments btw. When you guys are ready to take the fight to Git big time, I honestly think having an issue tracker you can use out-of-the-box with Plastic would be a big thing for all the Git users who are used to having one built-in to their Git hosting service. Being able to "one-click import" open issues would also be a big selling point, I'm sure. (You'd only need to support importing from the major Git hosting sites too - eg, GitHub, BitBucket, Azure - since those are the people most likely not to have their own server or standalone issue tracker).
-
Many thanks @psantosl.
QuoteAs far as I know, there shouldn't be a problem to connect your Plastic with a Mantis. Remember that the "integration" happens on the client side, so there will be the same integration whether you are on Cloud or on-premise.
Just want to make sure I understand this (sorry if I've got this wrong, some of this is still new to me). While the "integration" is client side, most of the free issue trackers require a server to host the issue database so different computers can access it (similar to how Plastic requires a server to host the repo database).
Now for those who already have an on-prem server or a VPS, that should be fairly easy (can just use the existing server for both Plastic and issue tracker). But for someone like me who comes from the Git universe and doesn't already have on-prem or VPS, if I decide to use Plastic Cloud as my Plastic server, I would still need to set up another server to act as the issue tracker server.
Does that make sense?
Wouldn't that sort of defeat the benefits of choosing Cloud Edition (ie, convenience and not having to deal with server setup/maintenance, etc)? Also from a cost perspective, I would then need to pay for 2 servers (Plastic Cloud + separate issue tracker server), even if for example I was only using 1GB out of my 5GB Plastic Cloud allowance.
QuoteAnd... you can develop your own integration in almost no time (emphasis mine)
Ahh, the curse of knowledge 🤣. This may very well be true for yourselves and a lot of your existing customers. But I bet for many people like myself, it would involve learning something we've never done before and take quite a bit of time (please remember, even server set up was new to me coming from the Git world!!)
Not insurmountable, but just one more "barrier" for Git users to make the move to Plastic 😉
QuoteWe've dreamed about making it public, but... well, too much work. We struggle with Plastic already
Yeah, this is a tough one...
I recently read your blog about all the new features on your roadmap (http://blog.plasticscm.com/2018/04/2018-backlog.html), so can understand when you say too much work. You know your product/customers and priorities best. But if I may offer one suggestion and possibly a different perspective to consider:
I really love Plastic (as I'm sure you know by now), but have to say I've struggled at times with the move from Git to Plastic (and that is with a relatively small and unimportant code base without significant time pressure). It is not the UX or lack of a Plastic SCM book which has made onboarding hard at times - it is things like having to learn how to set up a server, having to research cloud compute and VPS options, having to set up a new issue tracker, thinking about whether I'll lose anything I care about when making the move (eg, open issues and pull requests / code review comments).
Might sound trivial to you guys, but these were things which were completely new to me and had to learn in addition to a new SCM tool.
The planned features to make workflows even more flexible sound nice, but even without those, Plastic is already so much more flexible than workflows possible with Git. It is really great to see you focusing on new features for your existing customers, but as someone who would love to see more people using Plastic, perhaps it's also worth thinking more about the current "barriers" that discourage potential new users?
For example, see this forum post from another Git user, who says he thinks Plastic is one of the best VCS's but "learning a new toolset and switching the whole organization workflows is not something we can afford to do just to gain a few extra features". Perhaps Plastic's core features are already good enough, so it is no longer about adding more and more flexibility/features to attract new users, but more about making migration easier and less disruptive for new users (not just for migrating the repo itself - which you've already made easy with GitSync/P4sync - but for associated stuff like issue tracker and code reviews)?
-
Hey guys
Loving Plastic so far. Pretty much the only thing stopping me from grabbing a Plastic Cloud subscription or the Cloud Edition right now is the issue tracker integration.
I'm currently a hobbyist / solo developer but work 50/50 between two computers on different networks, so Plastic Cloud would be really handy for me (I'm used to the world of Git repo hosting, where I don't have to worry about server setup and maintenance). But if I have to set up a server for the issue tracker anyway... well that kind of defeats the purpose for me.
So, wondering if any of the following options are planned for the near future (or already included and I've just missed it):
- Ability to use Plastic Cloud as the server for one of the free issue trackers (eg, MantisBT). That would save people like me from having to pay for Plastic Cloud + pay for server rental or another cloud service for the issue tracker.
- Or even better, if Plastic Cloud came with the issue tracker server already set up and integrated, so we could just use it out-of-the-box like with most Git hosting services. Setting up and using Plastic SCM has mostly been a fantastic and painless experience, but the same can't be said for trying to get a free issue tracker up and running.
- An issue tracker extension for Github, Bitbucket, Azure Boards (part of Azure DevOps formerly VSTS) or one of the other free web-based issue trackers for Git repos. (Yes I realise I can create my own extensions, but only if by 'can' you mean 'theoretically possible' rather than 'realistically able to'. Also would sort of defeat the cloud convenience factor.)
Anyway, look forward to hearing back from you on my options. Really loving Plastic SCM and keen to get started properly as soon as possible.
Kind regards
David
PS: on a slightly unrelated note, if I get Cloud Edition (or cloud extension with Personal Edition), that still comes with a localhost clone so I can checkin/branch locally (quickly) right? Also, if I get Cloud Edition for now but want to switch to Team Edition on-prem server in future, I can do that without losing any data right?
Features on personal/small project among friends.
in General
Posted
Hi Barron,
I'm a Plastic user that came from Git as well - I think you'll find Plastic quite easy to get the hang of if you're used to Git.
Definitely recommend giving it a try. Just be aware of a few differences between Plastic vs Git, and you should be all good:
Also, just adding to what Francisco and Carlos said.
Hope that helps, definitely recommend giving Plastic a try.
David