Idiot install guide?

[chrismalek]

This project looks very interesting. However, I am not a Dot Net developer. Any chance you have an "idiot's guide" to installing and using this?

[tslater2006]

Hey there, unfortunately I do not. I will try to work on something this week though and update the issue when I have one. thanks for the interest!

[coltonfischer]

I did a write-up on Getting Started with Pivet on Windows that documents the steps that I took get up and running with Pivet. You might find this post useful for getting Pivet working in your environment.

[jsavage86]

@tslater2006 - like chrismalek I'm very interested in this project, but the instructions don't provide enough info to install and use (unless I'm missing something). Did you ever write up the "idiot's guide to installing? And, once installed, what's required to save a version of PeopleCode to git? Thanks for you help!

[tslater2006]

Hey, I don't have a guide written yet, but Colton Fischer has put together a guide based on his experiences. https://peoplesoftmods.com/utilities/getting-started-with-pivet/

Thanks for your interest in the project!

On Wed, Jul 6, 2022, 8:07 AM jsavage86 @.***> wrote:

@tslater2006 https://github.com/tslater2006 - like chrismalek I'm very interested in this project, but the instructions don't provide enough info to install and use (unless I'm missing something). Did you ever write up the "idiot's guide to installing? And, once installed, what's required to save a version of PeopleCode to git? Thanks for you help!

— Reply to this email directly, view it on GitHub https://github.com/tslater2006/Pivet/issues/19#issuecomment-1176200877, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANGZAV4AVXQTD3AZMTWDA3VSWAJTANCNFSM4LRAUX7A . You are receiving this because you were mentioned.Message ID: @.***>

[jsavage86]

Thanks for the quick response! Am I understanding this project correctly: Pivet should be installed on each developer's local computer which then pushes to git?

[timmclaurin]

Yup. It commits to git for each dev. So you can track who is doing what.

[tslater2006]

Hi @jsavage86, multiple developers can run Pivet against the same git repository, the critical part here is that they must have the same configuration settings. When Pivet executes for a "job" the following steps happen:

1. Check for repository on disk
2. If not on disk, try to clone from remote (if configured)
3. If no remote is configured, create a new repository (this happens on the first run)
4. Once a repository is on disk by 1, 2, or 3 delete everything in the working folder
5. Execute the job's configuration against the specified database. This dumps out all defintions that Pivet will version control (HTML/PPC/CSS/SQL/Raw Data entries/ etc)
6. Ask Git what has changed in the working directory (Git will report deleted files, new files, changed files)
7. Bundle up the changes into commits**
8. Push commits to remote (if present)

The problem that arises with multiple developers is if their configuration settings are different, Step #5 above ends up versioning completely different things. Items that Developer A versioned that Developer B didn't will be shown as deletes any time Developer B runs Pivet.

So, the ideal situation we've found is that if a developer wants to use Pivet to version their own stuff. They should do it to their own Git repository, and not one shared by others. Alternatively (and this is how we use it internally) we actually have our Application Servers setup to run pivet every night, and the configuration set to capture all of our objects since we have a consistent naming prefix internally. This provides us nightly snapshots of the objects which we can inspect if we need to later.

I hope this helps clarify, but if not I'm happy to clarify anything (and I promise I'll actually get a guide written up!)

** There are a couple of ways to bundle the changes into commits. SingleCommit puts all Adds/Changes into a single commit of "Changes Captured by Pivet" and then all deleted objects into a "Deleted Objects" commit.

PeopleCodeSeparate puts all PeopleCode adds/changes into a commit, all other adds/changes into a commit, and then all deletes into a commit

TopLevelSeparate puts all adds/changes per top level folder into their own commit, in practice this makes HTML changes their own commit, and CSS their own, etc because those are usually in their own top level folders.

There is a legacy feature of "CommitByOprid" but this is not recommended, mostly because a lot of things Pivet can version control do not have a lastupdoprid, but even in the event they do, it only captures the last person to touch it before Pivet was run. If 2 people touch it before Pivet is run, all changes get attributed to the last person to touch it.

[tslater2006]

One additional comment @jsavage86, currently Pivet only clones/pulls from the remote repository if it does not exist on disk. In your scenario of multiple developers running Pivet, if they are operating with the same config as mentioned above, and against the same repository, they will need to do one of the following currently:

• Delete the repository from disk before running Pivet
• Do a git pull themselves before running Pivet

The delete will cause Pivet to do the clone from remote by itself, or they can update their local repository themselves first. This is needed to catch any changes the other developer has versioned and pushed into the remote.

If the local repository is missing changes that have been pushed by other developers, Git will refuse to push the changes in the local repository, since it is missing things that are already in the remote.

I may consider adding a mode where it will always do a fresh pull from remote before running in the future.

[jsavage86]

Thanks for all your feedback @tslater2006 ! That gives me some things to think about in terms of setup.

You mentioned that your setup simply has Pivet on the App Server, not the individual developer's machines. That is an option for us too. When running this way, does Pivet track who made the changes?

[tslater2006]

@jsavage86 I've updated the readme as well as put some sample configuration files in the samples folder. Some of the linked documents dont exist yet (like Configuration File Format and Using RawDataProcessor) but they'll be coming soon.

In general Pivet is not very good for tracking who made what change, but is great for tracking what changed and when it changed but not so good at who changed it. Pivet does have a legacy option of "commit by oprid" but I would strongly discourage its use for reasons I mentioned above. If multiple developers touch an object between runs, all changes get attributed to the last person to touch it. I would prefer that Pivet gives you less data instead of incorrect data, nothing worse than data you can't trust. As well as some items you may want to version simply don't have an LASTUPDOPRID field to use to attribute the change to someone.

We use the "Single Commit" style where all adds/changes are commited in a single commit, and then all deletes are commited in their own commit. But for new setups I would highly recommend using the "Top Level Separate" commit style as it makes it easier to look through changes in a hosted git environment like Github/Gitlab/etc.

[jsavage86]

@tslater2006 thanks so much for all the info, I really appreciate it. I do have one important question that I have not seen addressed in the documentation - is there any way to roll back PeopleCode or any other object?

[tslater2006]

Pivet itself doesn't provide a way to revert definitions like PeopleCode/HTML/etc. But you can use a front end Git tool to go to prior versions and then its a manual effort to apply that through App Designer.