AaronV_NMR

Hello, We are trying to use Plastic SCM as a Git Server. We are able to connect to it via SourceTree. Items in red are censored from the real information. The file I'm trying to add is a text file with 4 characters in it. SourceTree error: git -c diff.mnemonicprefix=false -c core.quotepath=false push -v origin feat/Test:feat/Test Pushing to git://Computer:9418/repo Looking up Computer... done. Connecting to Computer(port 9418) ... X.X.X.X done. error: remote unpack failed: An error was raised by libgit2. Category = Odb (Error).? Invalid pack file - base entry delta is not in the same pack fatal: protocol error: bad line length character: Git push via cmd: Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 277 bytes | 277.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) error: remote unpack failed: An error was raised by libgit2. Category = Odb (Error).? Invalid pack file - base entry delta is not in the same pack fatal: protocol error: bad line length character: Any thoughts as to what I may be doing wrong? Regards, Aaron

Hello Pablo, Then yes, that is something I don't like about git, plastic, or really any scm I've used. When I branch I'd want the branch to well be branched. I guess this would involve either a branch containing an "empty" change set representing no differences or a commit like command that created a branch at the same time. Regards, Aaron

Hello Pablo, But main always have an initial changeset with the root dir. Indeed! Its a nice feature of Plastic. I guess I was thinking about Git at the time. also, if you create a branch from another one, they share the same location (like Git) but it is not dynamic or anything. So, not sure why you need the intermediate changeset 😉 My apologies if I am confused, but I am not sure what you mean by same location. Do you mean the same change set? Regards, Aaron

Hello Pablo, Your welcome. Hmm... I think git is closer to what I'd want, but I'm not a fan of how minimal branches in git. I don't like that to rename a branch I have to delete it in git. I like that Plastic treats branches more like "objects", but I think its a matter of workflow. For example the reason that I wanted no change sets on my develop branch is that I want the first change set on the develop branch to represent the first feature I add. I really would love no change sets in main either at the beginning. So my deal work flow for a new project would be: Create a repo. Create Main. Branch Develop off of Main. Branch a feature branch of a Develop. Create the initial directory layout and ignore files. Create a change set for the initial directory layout and files in the feature branch Merge the first feature branch into develop. Work on N number of new features. Merge these into Develop as complete. Merge develop into Main for the first release. Continue working in feature branches and develop until another release is ready. Instead I need to: Create a repo. Create the main branch. Create a commit in main. (Normally a readme.md or .gitignore to have something to check in.) Create the develop branch. Make something to create a commit in the develop branch. (Folder structure with descriptive markdown files.) Work on the feature I wanted to start with. Merge that feature into develop. Work on N number of new features. Merge these into Develop as complete. Then eventually merge develop into main on release. Not much different, but its weird that main needs something to create a change set against as a base line. Can't I just have an empty branch as a base change set? Shouldn't the starting point be nothing for the main and no difference for a new branch? Just my 2 cents. Regards, Aaron

Hello Pablo, It makes sense to have branches rely on change sets. An unfortunate, but reasonable requirement. " you can play with permissions to deny people creating child branches, or you can create triggers to control the branch hierarchy " Thank you for pointing out that there are permission options, I didn't realize you could customize the access options like that on branches. I also found a configuration option in the display options where I could uncheck "display full branch names" and I also found the vertical display option for branches. Its nice to see the client and server are flexible. So I'm sure I'll find a combination of display and permission options to get the repo into the state I want. "That being said: do you have a Perforce background? " No. I have a background in Git, SVN, TFS, and CVS (way back in the day). "And, why do you need this complex branch hierarchy? Have you read about our recommended branching pattern?" Not in detail, but from a high level it looks like the cactus branching strategy? The company I work for follows a modified version of Git Flow where we create a branch per task/feature (we work to make these changes small per branch and we keep the branches around) and then merge these branches into develop once they've been reviewed. The master branch holds releases. If a release needs to be modified, then we create a branch off the commit from Master to hold just those changes and treat it like its own "develop" branch. Its probably not all that different from what you recommend. However. we do a release every 1 to 2 years. I'd love to release more frequently, but the regulatory environment I work in prevents that. Regards, Aaron

Hello Pablo, Good to hear from you and thank you for the quick response. "You can create "develop" starting from "main", and it will be called "develop" if it is a top-level branch while it would be "main/develop"" Yes, this works exactly as you say. If I could turn this feature off, across all clients, that would be great. I don't want branches to inherit the names of their parent. So I'll likely need to use top level branches for everything. This is because I use a naming scheme for feature branches of "Project\FeatureName". This lets me easily sort branches between projects and shortens the branch names. As for the issue I encountered, I think I figured it out. However, as some feedback: If I create a top level branch from another top-level branch that is empty, instead of pointing to the first top level branch, it will point to the first branch in the hierarchy that has a change set. I'd consider this unexpected behavior or at least I didn't expect it to work this way. If I add a change set to an empty branch everything works I would expect when a new branch is created. Regards, Aaron

Hello, I'm evaluating Plastic SCM for the company I work for. I'm trying to create a top level branch from another top level branch. So I want: main -> develop (top level) -> project (top level) However, when I create the second top level branch instead I get: main -> develop (top level) main -> project (top level) Is there a means to create the branch hierarchy I desire? Regards, Aaron