sync bug

[CG]

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).

 

 

 

 

[psantosl]

Hi,

 

Is this second diagram the result of a single replica? Or many?

It is not usual to see newer csets having older numbers, but it is not impossible.

Now, if you use a single repo, then changeset numbers are relevant. BUT, if you are in a distributed scenario, you should only care about GUIDs. Why? Because it is not possible to preserve the sequence, so we don't even try.

 

Suppose you start with changesets 0, 1, 2. You push to a different repo. Now both have 0,1,2. Now both create a new changeset on each side. It would be 3 on both. When you replicate again, the "3" in one of the sides will be "4" in the other. There is no way to keep the same number. That's why we fallback to GUIDs (which are in fact the real IDs used by replica behind the scenes).

 

We certainly could do a bigger effort to try to preserve the same changeset ids when possible (replica to a clean repo) but our algorithm is not taking that into account for various (non-trivial) reasons.

During sync, branches are replicated one by one, with no particular order. It means a newer branch could be pushed first, taking some changeset numbers, and then later an older one is pushed, and it will use newer cset ids. That's why the cset ids while unique, are not very relevant.

 

Thanks,

 

pablo

[CG]

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.

 

 

 

[CG]

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.

 

[psantosl]

Are you using Jet as backend? (I bet you do).

 

If so, it is possible to simply "copy" the repo.

 

That being said: you are better served by GUIDs than changeset ids for embedding the number in the executable.

 

We should rethink the clone to preserve the numbers (no reason not to, initially) but it would be a major redesign. I'm not saying it is not worth (it is, you are right in your points), but I'm not sure we'll be able to deal with it shortly.

 

Would it be possible for you to embed the GUIDs instead of the csetid?

 

This is what we do ourselves:

 

[CG]

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).

 

[CG]

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?

 

 

[psantosl]

Hey,

No, no worries. Underneath Xlinks use GUIDs 😉

[CG]

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

[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!

[psantosl]

Thanks for the kind words. It is extremely encouraging for the entire team that you take a minute to share such kind words. Thanks.

[smartvn2020]

Great. Thanks for the information you provided.

molds