Jump to content

David Yang

  • Content Count

  • Joined

  • Last visited

  • Days Won


David Yang last won the day on October 30 2019

David Yang had the most liked content!

Community Reputation

2 Neutral

About David Yang

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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!
  3. 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. 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.
  4. @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
  5. 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/ David
  6. 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
  7. 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
  8. 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).
  9. For me, it was because (a) I didn't have a static IP address and (b) would have needed to keep both computers running. But yes, only really something to consider for purely solo projects (where you don't need to be able to work in parallel). Otherwise definitely Plastic Cloud or a computer/server that is always on.
  10. Hi MaybeGreat, I'm just a user (not Plastic staff), but it sounds like you might be trying to do something similar to what I was trying to do before. It's just yourself but you'd like to work between 2 computers (eg, home and office), right? An easy way to do this: Install Plastic on both computers (using localhost server and local storage for both). When finished with one computer, follow the backup procedure and backup to external HDD or OneDrive / DropBox (very easy for default Jet database: just stop service, copy files, then restart service). At new computer, restore the backup before resuming work (ie, stop service, copy files, restart service). At first I tried to simply move the repo storage to OneDrive and just checkin there directly, but couldn't get that working for some reason. But the above is pretty quick and easy if it's just yourself and you're not changing computers frequently (besides, it's a good idea to regularly backup your repos anyway, and this way you'll always have a pretty recent backup!) David
  11. 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!)
  12. 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!!)
  13. Thanks Pablo, that seems fair. At the time of asking, I was playing around with a free-tier Windows EC2 instance (and Windows itself took up most of the available storage), so was very conscious of space! But yes, can understand why this would be much better for performance, and good trade-off when compression works so well for text files. For big binaries, perhaps a hybrid approach could work? Eg, store a full revision every X revisions, and deltas in between? That way it would limit the amount of tree-walking / delta rebuilding needed, but still save up to X revisions worth of space...
  14. 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!!
  15. 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?
  • Create New...