CG

And just because it should be said...in my opinion this is hands down the best version control system available today. Keep up all the good work and innovative ideas!

That's great! Good to know! Thanks!!

One more point/question...since you recommend not using changesets and say they aren't very relevant...is there an alternative method for creating xlinks that uses the GUID instead of a changeset? Cloning a repo to a new server where "relative xlinks" are used means that the changeset link will break, right? Since the changesets will be different after a clone?

I still use SQL Server as the back end. It fits within our existing backup scheme without issue (each repo database is automatically included in the backup and maintenance scheme--tran logs every 15 minutes, diffs each night, weekly fulls, snapshots to SAN, then weekly/monthly/quarterly/yearly tape archives, etc). So it's just easy to stick with SQL. I like your method of using the GUI and placing it in the product name. I'll switch over to that. In the past the changeset wasn't a big deal because the builds were all run against the central "gold" repository of truth. So clients syncing with it is a non-issue since the official builds come from it, and a changeset won't ever change it's number once it is made. So by embedding it int he product version info (instead of the product name) we can always tie it back. My issue with this post was that by trying to move the repo to a new location (not snycing it with an existing repo with contents, but really moving it) I lost the changeset link to the builds. It's not that big a deal because we still have labels for every build that was released so we can tie back, it's just not as clean. So yes, good tip about the GUID, and that makes sense (it's just a little unwieldy to put the GUID in the build instance names in our devops tool as seeing a repo and changeset number was simpler). But it makes more sense as it truly is unique across all working instances of the repo (it's just harder to search on and say to someone over the phone).

As a followup, this makes it impossible for me to move a repository to a subrepository and maintain an accurate copy. We include the changeset from which a build was made in the version info of an .exe or .dll. If we want to move a repo then that breaks that metadata link since there's no way to copy/clone the repo to a subrepo and preserve changesets. Unless you have another suggestion on how I can get a 1:1 copy of a repo into another new empty repo (or sub repo). Thanks.

Just one sync view, pushing all branches from a single repo to an empty repo. I had expected the changeset ordering the remain the same since the target repo was empty. I understand changesets might change with merging repos that had to be reconciled with changes in each, but having no changes in one I thought I could get an exact copy. So....I wiped it out and tried clone instead. I expected clone to make an exact copy...but even that fails. Clone is not preserving changesets. As far as I can tell they are chronologically correct (i.e. every changeset is greater than the changeset that can before it). However if my source repo has gaps in changesets (due to a delete for example) then those gaps don't propagate via clone. Example, my source repo I'm cloning has changesets 1,2,5,7,8 then after cloning my destination repo has changesets 1,2,3,4,5. I understand why changesets with replication can be off (but I don't like that they chronologically off), but I would expect clone to actually clone and that I'd have an exact copy of what I'm cloning. Changesets shouldn't change with a clone.

You have a bug with your sync views where they don't synchronize as expected (at least I would consider this a bug). I just synced an existing repo into a blank sub repository. The behavior was not as expected. Changeset numbers DO NOT match up! In fact, the head (latest changeset) in my source repo does not even exist in my destination repo. All of the changesets themselves seem to be present, but the numbers are all over the place. For example, my last changeset on my last task branch in the old repo was 807. I merged that into my main branch and the very last changeset there is 808. In the new repository (that was previously empty before the sync) my last task branch changeset is 727 and the last changeset on main is 349! How can changesets go down in number for later commits? As another example see the attached screen shot showing a short section where changests are not sequential in time (later numbers show as earlier commits). It's my understanding that changesets should always increase with chronological commits. Is that not the case? In normal operation (outside of a sync) changeset work this way. Also, sync view is listed as being a way to keep repos in sync with one another. If my "mirror" repo has different numbered changesets then it's not a mirror!! Attached are snippets from then branch explorers of the "correct" (i.e. the original repo) and the incorrect (the new repo) changesets (I manually labeled the changeset in black since I didn't see a way to get the branch explorer to display the CS numbers).

Nice. I never had an occasion to create a subrepo, that makes sense. Thanks! Regarding Jet...it sounds great for speed but I like the transparency and accessibility of SQL Server (being able to use TSQL). I've had minor issues in the past (regarding dangling workspaces when clients were removed without removing their workspaces) where directly modifying the data for a workspace in the SQL table fixed the problem (this was a few years ago). Not having the ability to query/modify Jet data could be an issue. At least with SQL I know that I have an extra layer of visibility into the underling storage system so that if anything goes wrong (corruption for example) and I don't have a recent enough backup for some reason (or a backup wouldn't help, like in my above problem) then I still can potentially fix the issue. The completely closed nature of Jet keeps me relying on my trusted SQL server. Do you have Jet tools (even command line would be fine) that allow for query/update capability if needed? Or do you publish the Jet structure/standard anywhere?

At some point years ago in an early version of Plastic I seem to vaguely remember discussion of an undocumented ability to configure Plastic to use a single database on a server and use multiple schemas within that database for repository objects. But I can't seem to find any of that discussion in the forums anywhere. Is this possible? Could I, for example, have three separate repositories all using one SQL Server database but each using a different schema name in that database? This would greatly simplify database backup management for large numbers of repositories.

I want to merge two repositories (or more) into a single repository without losing history of either repository, but have the full history of both available in the new repo. I have project1 and project2, each in their own repo (repo1 and repo2). Each project’s folder structure is set up the same—i.e. there’s a “/src” folder, a “/build” folder, etc in each. I want to bring each project (along with history) into a new repo where the /main will eventually (after some tweaking) have a folder structure such as: /project1/src /project1/build /project2/src /project2/build So, in Plastic I imagine doing this as follows: I’d like to have a new repo with a /main branch. And then create two child branches off that (called say “/main/repo1” and “/main/repo2”). And then on each of those child branches import the “/main” branch of each of the two repositories. This would let me have the full history of both on their own branches and then I could merge those two branches together after making changes to the folder structure in each so I could merge as above. However I can’t figure out how to do this in plastic. Attempting to “pull remote branch” or replicate a repo doesn’t work as desired in this case (I can’t sync a src repo to a specific branch in a target repo, at least not I am aware of). So first question, is there a way to synchronize an entire source repository to a specific child branch in a destination repository that I want to map as the main for the source repo? If so, how do I do that? Second question, if there’s no way to do that, then is there any other way to do what I want? I’m sure others have wanted to combine or split repositories over the years, how have you preserved history in that case?