|
Re: synchronizing a single repository with multiple projects [message #755243 is a reply to message #755132] |
Mon, 07 November 2011 18:46 |
|
All synchronize operations work on repository level, but not all presentation models will show all changed resources. The 'Workspace' presentation model (one that is selected by default) will not show non-workspace resources (eg. if one of projects is not imported into eclipse then it will not show in results), also changes in closed projects will not appear in results. In case of 'Git Commits' model all resources in git repository will be presented even if they are not imported in workspace or are in closed projects.
|
|
|
Re: synchronizing a single repository with multiple projects [message #755254 is a reply to message #755243] |
Mon, 07 November 2011 19:51 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
OK, that makes good sense. Thanks for the clarification. Now on to the next problem
I do: "Team -> Advanced -> Synchronize -> Custom..." and for the destination I pick the reference of interest from the pull-down menu, which in this case is refs/remotes/trunk. Then I click "Finish" and nothing happens. No error, no sync. All I can do is cancel.
As you might guess, this reference was produced via SVN bridging. I understand that jgit doesn't support svn bridging, but once created the references are like any other: it's just a file whose contents is a SHA, exactly the same as any other Git reference, with nothing SVN'ish about it.
So why wouldn't synchronize work? Shouldn't I be able to synchronize against an arbitrary SHA?
If not, if there's some issue here, probably better not to list the unsupported destinations in the menu.
|
|
|
|
|
|
|
|
|
Re: synchronizing a single repository with multiple projects [message #756349 is a reply to message #756212] |
Sat, 12 November 2011 10:33 |
|
That's true this change can hang for some time ... to reduce it you can also participate in review process and verify if this fix really solves this issue. You can vote +1 and -1 for any change in gerrit.
Regardless source reference, the first versions of synchronize impl allows to specify both source and destination refs, but we find such approach was hard to understood for new users and makes it really hard to properly show results and handle actions in context menu, also checking out any reference in really fast in git. Because of that we decided to always use current HEAD as source ... we still have code that allow to specify source ref in our code base but I cannot guarantee that it fill produce proper results
I would say that showing commits that are in one ref and not in another should not be handled by synchronize view but rather by something else ... maybe "history diff" would be a proper name for this new feature. As far as I see the synchronize view was designed to show differences in files, yes I've done some hacking to implement 'git commits' model but it also show differences in files at the end. Maybe adding "Open in commit viewer" option to context menu for commit elements in git commits model will somehow solves yours problem. You can fill an enhancement bug for "history diff" or "Open in commit viewer" and maybe some one will pick it up
|
|
|
|
|
Re: synchronizing a single repository with multiple projects [message #756386 is a reply to message #756349] |
Sat, 12 November 2011 14:49 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
Re: extending Advanced Synchronization vs a new command, sure, either way, whatever is easier for the developers. We just need some way in egit to compare two arbitrary references. The closest thing in command-line git is probably 'git log source-ref ^dest-ref'. To me it feels close to what Advanced Synchronization is already doing but a new Log or Diff command would be just as good.
Re: an arbitrary reference as the destination in Advanced Synchronization (or some new Diff command) don't get hung up on the fact that the example happened to come from an svn bridge. That's not really relevant. Any file in the .git/refs tree should be considered a legitimate reference, regardless of where it came from. They're all the same, and they're all being listed in the destination pull-down menu anyway. We just can't use some of them.
In that sense the existing command is broken as it stands -- it lists destinations that can't actually be used. Surely it's simpler to allow any reference to be used as a the destination than it is to filter out certain entries for no particular reason? From what I saw of the checkin by Dariusz, this is just what he did: removed an unnecessary check of the path structure.
You're of course right that more of us should be contributing: we're all developers here after all. I do feel a bit guilty, and I'm curious about Gerrit, which I haven't used before. I just need to find the time...
[Updated on: Sat, 12 November 2011 14:51] Report message to a moderator
|
|
|
Re: synchronizing a single repository with multiple projects [message #756451 is a reply to message #756386] |
Sun, 13 November 2011 13:59 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
More info on this bug so we don't get hung up on irrelevancies. I also added the crux of this to the bug report.
First, a baseline case:
1. Create a reference manually by adding a file in .git/refs whose content is any valid SHA. Call it "xxx".
2. Run 'Compare With -> Branch Tag or Reference...'. Select this reference and observe that the operation behaves correctly.
3. Run 'Replace With -> Branch Tag or Reference...'.. Select this reference and observe that the operation behaves correctly.
4. Run 'Team -> Advanced -> Synchronize'. Select the reference and observe that this operation behaves correctly.
So far so good. Now a more interesting case (but no bridging involved):
5. Create another reference manually by adding a file in .git/refs/remotes whose content is any valid SHA. Call it "yyy".
6. Run 'Compare With -> Branch Tag or Reference...'. Select this reference and observe that the operation behaves correctly.
7. Run 'Replace With -> Branch Tag or Reference...'. Select this reference and observe that the operation behaves correctly.
8. Run 'Team -> Advanced -> Synchronize'. Select the reference and observe that this operation fails!
So what's going on?
Advanced Synchronize has to do some extra work if the "Always launch fetch before synchronization" option is enabled: if the destination reference is a remote-reference, it needs to know which remote to fetch from. One reasonable way to do this is to assume that any references under .git/refs/remotes will always have the form
.git/refs/remotes/<remote-name>/<reference-in-remote-repo>
The bug is in that assumption: Git does not require references under .git/refs/remotes to have this form.
The fix would then seem to be straightforward: verify that the reference really is a remote-reference before treating it as one. I believe this is exactly the change that was made but hasn't yet been accepted.
As can be seen, testing is very simple, just add a reference to refs/remotes that isn't in the remote-reference form.
[Updated on: Sun, 13 November 2011 14:06] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.04479 seconds