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
    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. Unlike Git, the local repo (if you're working DVCS that is, you can also work centralised like Perforce if needed for file locking) is stored in the server install folder by default, not inside the project folder like with .git. I think you'll be familiar with the concept of Plastic workspaces if you've used Perforce. Also, just adding to what Francisco and Carlos said. You'll get Gluon as part of your cloud or on-premise subscription anyway, so don't worry. Even though you can't automatically trim the database (yet) - don't worry, artists don't have to deal with whole repo like with Git. If they use Gluon, they'll automatically be dealing with just the files they need, and if they use the regular GUI they can "cloak" files to prevent them downloading to the workspace. Also, I haven't used this feature myself, but it looks like you can manually archive revisions to the external storage if needed: https://www.plasticscm.com/documentation/administration/plastic-scm-version-control-administrator-guide#Chapter10:Archivingrevisions Hope that helps, definitely recommend giving Plastic a try. David
  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 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
  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, 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
  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 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!
  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 "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.
  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, 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
  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 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
  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... 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
  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 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
  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 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).
  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 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
  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 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!)
  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 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!!)
  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 space...
  • Create New...