Jump to content

David Yang

Members
  • Content Count

    31
  • Joined

  • Last visited

  • Days Won

    1

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
    Advanced Member

Recent Profile Visitors

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

  1. 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: Plastic uses slightly different terminology, eg commit = changeset, push/pull = sync or replication, etc. Plastic branches are commit/changeset containers rather than simple pointers (ie, changesets belong to a branch), which I prefer over Git branches because it makes it easier to understand merge history, etc.
  2. Hi @psantosl and @danipen, 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
  3. 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,
  4. 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 a
  5. 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 "len
  6. @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,
  7. 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 remembe
  8. 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...
  9. 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 dif
  10. 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 b
  11. 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.
  12. 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 comput
  13. 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
  14. 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 whil
  15. 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 spac
×
×
  • Create New...