DaSHTech

I have a repo that I need to hand off to someone else who will only store their files in Git. I see a lot of ways to pull Git into Plastic but am unsure how to go the other way. Is there a procedure to export a Plastic repo to a blank/new Git repo? Thanks!

Hi Wolfram, thanks for the tip - I hadn't noticed it updated a separate window if you clicked through the timeline. I think that's a workable solution for me.

I would be happy with simply a list of the changed files for each changeset. at that point, you could either perform a code review on the file you found or run a diff, etc. from a right-click on the file in the file list for that changeset. An alternate way to do it would be to add a second tab on the right, next to properties, that could show the changed files for each changeset. That would take no extra screen space and you could choose which info to look at as you click through the tree.

First, let me say I've ended up using SmartGit for my office and really don't like the merge function - I think Plastic works way better! I would really like to recommend PlasticSCM for our Git work, with one giant exception: I would love to see the list of files changed in the branch explorer. There is so much wasted vertical space under the branches, if I click on a changeset in the explorer timeline, I would love to see the window split to show something like the pending changes list, but just for that changeset. That way, you could click through the branch explorer and nearly instantly see the files that were updated in that change.

Is it possible to read the .exe version of a file and automatically log that to the changeset label or description for future search? I would like a way to easier match errors logged in my app to the specific version in code that the user may be running.

OK, I feel like a dummy and figured out how this works now. I thought the wxlink was purely symbolic and actually manipulated the tools directory, but now I see that it created a subdirectory within my main program directory and is updating there. I guess that makes sense as it makes it less likely that I might lose something in that original repo if there are uncommitted changes. This tools directory hasn't changed much over the years, so I've never noticed how this works as my main program references the jpatools directory directly, thus ignoring my wonderful wxlink directory. Time for some refactoring!

so, I need to move over to the jpatools repo and switch manually as I move around in the main repo? Because as I switch now, those are the two views I get: the top is my latest changeset (cs784) in main which shows cs40 in tools and the bottom is a different branch (cs785) in the main repo which shows cs2. The directory for the jpatools repo is unaffected when I switch, even if I update workspace. Is that expected behavior? I assumed that if I switched to the bottom branch that shows cs2 in tools, that it would update the tools workspace to cs2. I don't seem able to affect the jpatools repo unless I switch to it separately.

Maybe this will help - I have two snapshots of my workspace, the first is my current changeset, the other is from an old branch that is basically an old maintenance version of the app that gets occasional maintenance updates. In the current version, the link to jpatools is at changeset 40, the old version it's at 2. That's all as expected. However, when it's displaying changeset 2, I check the actual tools directory and the files are still dated this month and have the most recent changes, which is obviously a problem for a build expecting 2017 files. I hit "update workspace" I guess I don't see a lot of difference as my workspaces seem to be local copies of repositories, but hopefully this gives a clearer picture.

I am trying to figure out if my xlinks are working properly or if I just don't understand. first off, I am using the cloud edition, so don't know if that makes a difference as all my workspaces basically check directly in to Plastic Cloud. I have two workspaces named mainpg and tools. In the mainpg workspace, I have an wxLink set to my tools workspace. I have made a few changes along the way to some text files in tools while I was in the mainpg workspace but haven't seen the tools changeset move. Question 1: Do I need to switch over to my tools workspace to commit the changes separately, then update the link manually in mainpg to reflect the proper changeset? When I do the above and switch between historical changesets, the wxlink appears to update with the rest of the changeset items. However, when I check the actual tools folder, no changes have been made to the files. updating the workspace has no effect either. Question 2: is there something wrong here or am I just not doing it correctly? I love Plastic for my mainpg workspace and it has worked flawlessly through many branches and merges. I just don't seem to have any luck with the wxlinks. Thanks in advance, Steve

I have JIRA integration working to see tasks and to mark as open when I create a new branch. However, I am having trouble getting my merge changeset to mark the JIRA card as closed. I have setup the status transition as: [DONE]-DONE as my final status is DONE (I have tried all caps and proper case). I also have tried marking my branch changeset as [DONE] before merging, thinking it may not tie back to the proper card# after merge, but that didn't work either. Am I missing something? Thanks