| synchronizing a single repository with multiple projects [message #755132] |
Mon, 07 November 2011 08:36  |
Eclipse User |
|
|
|
I have several Git repositories that include multiple Eclipse projects. It appears as if the synchronization operations are synchronizing the selected projects one at a time, rather than synchronizing the repository as a whole. Is that correct?
This doesn't seem like the right behavior. Other egit operation works on the repository, regardless of which projects are selected. For instance if I run "Team -> Commit" from the right-click menu with one project selected, the result is that all changes are committed, not just the changes in the selected project. Why shouldn't synchronize work the same way, at least by default? For sure it takes longer to walk through the projects one by one.
At minimum seems like we need the option to synchronize at the repository level, for instance with a right-click menu item on entries in the 'Git Repositories' view. Right now there doesn't seem to be any way to do this in a workspace with multiple projects from a single repository.
|
|
|
|
| Re: synchronizing a single repository with multiple projects [message #755254 is a reply to message #755243] |
Mon, 07 November 2011 14:51  |
| Eclipse User |
|
|
|
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 #756386 is a reply to message #756349] |
Sat, 12 November 2011 09:49 |
| Eclipse User |
|
|
|
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 09:51] by Moderator |
|
|
| Re: synchronizing a single repository with multiple projects [message #756451 is a reply to message #756386] |
Sun, 13 November 2011 08:59 |
| Eclipse User |
|
|
|
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 09:06] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.05648 seconds
Home