Unshelve operation support

[Ivan Danilov]

I've just tried to make quick-move to support unshelve from old Matt's branch - rebased it onto master. See here.

It seems working after some merge-work but one thing is slightly bothers me: we are making branch in current position. Shelve on the contrary can have changes based on earlier versions. Moreover, different files in single shelve can be based on different versions. For example lets say we have files a.txt and b.txt that were changed in changesets 1, 2 and 3. Someone had taken changeset 1, made changes to a.txt then got version 2 of b.txt (while a.txt still based on version 1), made some changes to b.txt also, then shelved these changes. Other guy got latest, 3rd version with git-tfs and tries to unshelve. He will see changes like first guy taken a.txt and b.txt, reverted 2 and 3 in a.txt, reverted 3 in b.txt and made some changes...

It's a hell! TFS still frustrates me to no end... again.

[Ivan Danilov]

Btw, could someone take my version to test it please? I'm afraid of 'works on my box' syndrome :)

P.S. Compatibility with 2008 could be broken. I will check and fix today if something is broken. I don't have TeamExplorer2008 right now, so can't check myself.

[Ivan Danilov]

In git we can't have part of the files based on one revision and part on another. I think it is very good (otherwise it would be a mess), but TFS' authors seems to think otherwise.

Currently Matt's implementation just takes _changes_ from shelve and applies them to commit in tfs/default branch. As a result - we have a good chance of having some files from shelve and some from latest version. Which can be a problem if shelveset was based on earlier version...

Look at change variable. 'change.PendingChanges' is an array of PendingChange instances. Each instance has Version property which equals to latest changeset ID where this concrete Item (essentially item is a file for our discussion) was changed last time before shelve changes were introduced to it. So in order to get correct state we should for each PendingChange instance (lets name it change for clarity) make these steps:
1) find hash for git-commit that corresponds to change.Version changeset. Note that such commit may not exist - for example due to quick-clone.
2) get file named change.LocalItem from commit found in previous step. If commit was not found - we should take it directly from TFS
3) apply changes from shelve to resulting file.

Well, it is still absolutely not clear for me where should we take other files from... From latest version? What if latest version is not consistent with other versions?

Thus said, if we get other files from somewhere and were able to perform above-mentioned steps correctly - we will have correct state at least. Diffs still can be incorrect because we have only one parent for everything in git. And to get absolutely correct diffs we should have a parent on each PendingChange instance.

[Ivan Danilov]

Shocked. Really. TFS is a crap, really. It doesn't know which version of other files were there when shelve created. So it just applies changes from shelve on current version and leaves other files as they are...

Well, that means two things:
1) we have one problem less;
2) TFS is a crap. I think I've already mentioned it. Nevertheless.

[Matt Burke]

If there's a clean way to roll back to some point and apply the
shelveset, that would rock, but I ran into what you ran into. I assume
TFS does the same thing (just copy in the changes on top of latest),
except that it tracks enough meta-data that it can bring the file
forward on update, sometimes.

When we first started using TFS in 2005/2006, we were going to
review-with-shelvesets. That didn't last long, due to the crappiness
(i.e. not real branching) of shelving.

> --
> You received this message because you are subscribed to the Google Groups
> "git-tfs-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/git-tfs-dev/-/FSmrlQczVhUJ.
> To post to this group, send email to git-t...@googlegroups.com.
> To unsubscribe from this group, send email to
> git-tfs-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/git-tfs-dev?hl=en.
>

[Ivan Danilov]

If to state things that way... I didn't see a point to improve git-tfs for cleanliness of diffs if we can't even guarantee correct state. TFS' support for that thing is only on the 'put bunch of files to the server so I don't loose them if my box go down' level, and what you've done is probably enough then. We just have to mention that it is not entirely safe, so that people be warned.

[Ivan Danilov]

If you have no more ideas - probably we should integrate the thing to mainline. I've checked it on two machines. Unfortunately both were using VS2010, but VS2008 version is also compiling without errors.
If something is broken though, I hope someone will give us feedback about not-working thing :)

[Dan Rigby]

There's been a lot of new feature support added to git-tfs in the last couple of months. Unshelve support is something I've been especially looking for. 

Would it be possible to create a new binary drop in the near future?

Thanks.

On Wed, Aug 3, 2011 at 7:13 PM, Ivan Danilov <van.d...@gmail.com> wrote:

If you have no more ideas - probably we should integrate the thing to mainline. I've checked it on two machines. Unfortunately both were using VS2010, but VS2008 version is also compiling without errors.
If something is broken though, I hope someone will give us feedback about not-working thing :)

--
You received this message because you are subscribed to the Google Groups "git-tfs-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/git-tfs-dev/-/87mZ8puQc_wJ.

[Ivan Danilov]

I'm somewhat concerned with stability. I want to receive some feedback on latest changes before announcing 0.12 version.

Could you test latest sources for testing please?

[Dan Rigby]

For the unshelve -l command, it would be helpful to have the option to sort the list of shelvesets optionally by date created.

(We use shelvesets for code reviews, so the most recent is likely to be the one I'm most interested in)

On Thu, Aug 4, 2011 at 1:14 PM, Ivan Danilov <van.d...@gmail.com> wrote:

I'm somewhat concerned with stability. I want to receive some feedback on latest changes before announcing 0.12 version.

Could you test latest sources for testing please?

--
You received this message because you are subscribed to the Google Groups "git-tfs-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/git-tfs-dev/-/vYjvtreIFQcJ.

[Ivan Danilov]

One thing that might be possible, but i have no idea how difficult to
implement, would be to treat each change in the shelveset as a
mini-cherry-pick... In other words, we could (theoretically) take each
change, get its base version and the updated contents, generate a
patch for it, then apply the patch to the current version. I'm not
sure how easy it would be to deal with renames, but I think git does
sometimes. An easier approach might be to guess at a base repo
version, based on the base versions from the shelveset, and use that
for the point where the branch gets made.

Of course, I could be just imagining that tfs stores base versions for
changed items in a shelveset.

To make this mini-cherry-pick possible we need to make new root commit (no merge base with any of existing commits) with all of the base versions of the shelveset changeitems and the second commit with changed ones. Then it would be ideal representation of the changes saved in shelve. Just a clean tree object with several files. And then user could easily invoke cherry-pick himself and it will apply wherever he wants. Or does not if there're conflicts.
If I understand correctly - that shouldn't be even very complex...

Correct me if I wrong somewhere in concept, please.