Opened 8 years ago

Last modified 7 years ago

#367 accepted enhancement

When a repo URL changes, GetComponents should offer more help

Reported by: Erik Schnetter Owned by: Eric Seidel
Priority: major Milestone:
Component: GetComponents Version:
Keywords: Cc:


When a repo URL changes, GetComponents currently suggests to check out the repo from scratch (and presumably delete/ignore the old repo). This is very inflexible, in particular when the user has changes in the old repository, which often happens during development.

SVN (and presumably all other VC software) offer commands to update the URL, so that one can keep the current checkout. Of course, this makes only sense if this is the same repository that only moved to a new URL, but this seems to happen often enough.

GetComponents should at least output instructions for updating the URL.

It would be even better if GetComponents detected that new and old repo are the same, and then update the repo URL by itself.

Attachments (0)

Change History (10)

comment:1 Changed 8 years ago by Eric Seidel

Milestone: ET_2011_05
Status: newaccepted

I like the idea of updating the Repo URL automatically, but we'd need to be 100% certain that the new URL is in fact the same repo. With Git and Hg this should be fairly easy, since the commit hashes are cryptographically secure (I think we could just pick a commit at random and make sure it exists in both repos and the logs are the same). However, I'm not sure how we would do this in cvs or svn. Do you think the same idea would be secure enough?

comment:2 Changed 8 years ago by Erik Schnetter

For svn we can compare UUIDs:

Repository UUID: 17b73243-c579-4c4c-a9d2-2d5706c11dac

We can probably just ignore CVS.

Comparing a random commit is not good enough. It may be that two repositories are different branches, i.e. they would be 95% identical and then have diverged.

comment:3 Changed 8 years ago by Frank Löffler

Yes, for svn you can either lookup the UUID yourself, or you can try to avoid the internals and try a 'svn switch --relocate' and test for the exit value. This effectively also compared the UUIDs, but it does it for you and you are separated from any possible future change in the internals. Practically both give you pretty much the same, except maybe that even if you compare the UUIDs you would still need to do the relocation and check for its exit value to actually do the switch.

comment:4 Changed 8 years ago by Eric Seidel

I completely forgot about svn switch...

Another possibility for git would be to add the new URL as a dummy remote, and run git remote update <dummy>. In the case that the repos are completely unrelated, git will emit a warning that there are no commits shared. However, it will finish the command without throwing an error, making this approach kinda clumsy. There's no guarantee that the warning will remain going forward (or that older versions of git have it). I'm also not sure if it would catch cases where the repos share a common ancestry, but have since diverged (my guess is that it would not).

I'll have to look into the git/hg question more.

comment:5 Changed 8 years ago by Frank Löffler

Eric: do you think this could be included for the next release (quite soon)? If not, I would like to change the ticket to indicate that.

comment:6 Changed 8 years ago by Frank Löffler

Milestone: ET_2011_05ET_2011_11

comment:7 Changed 8 years ago by Eric Seidel

I just pushed a fix for switching to new branches/urls in svn. I still have to look up strategies for git/hg though.

comment:8 Changed 8 years ago by Eric Seidel

For git, it appears that git actually does some internal verification when you try to fetch from a new remote.

~/Source/Cactus/repos/CRL$ git remote add test
~/Source/Cactus/repos/CRL$ git fetch test
fatal: did not find object for shallow 234bdec2c1fac30dc0bc8337df906ce752c88c73
fatal: The remote end hung up unexpectedly

The problem is that the error message is not entirely consistent or informative...

~/Source/Cactus/repos/CRL$ git remote add test git://
~/Cactus/repos/CRL$ git fetch test
fatal: The remote end hung up unexpectedly

Also, if I try via https instead, it just seems to hang.

comment:9 Changed 7 years ago by Frank Löffler

Milestone: ET_2011_10

removing target milestone as this is solved for svn, and is very unlikely to be resolved for git and/or hg, as there isn't even an idea how to do this yet.

comment:10 Changed 7 years ago by Ian Hinder

Is it really solved for SVN? I have a Curie checkout and I manually did an svn switch on the manifest repository to get the new thornlist for the current trunk. I then fetched the CRL git repo and switched to the master branch to get the latest version. I then ran

[ianhin@login-damiana Cactus]$ bin/GetComponents -a --update --root=. manifest/

It first told me that the URL for simfactory2 had changed, so I moved it out of the way. It then told me

Error: The URL for EinsteinAnalysis/Multipole has changed, please perform a clean checkout.

Now, the URL will have changed because the branch has changed, but that is the only change, I think. Multipole is stored in SVN, so I don't think this is working, unless I've missed something.

Steps to reproduce:

# Download Curie version
wget --no-check-certificate
chmod 755 GetComponents
./GetComponents -a

cd Cactus

# Update GetComponents
cd repos/CRL
git fetch
git checkout master
cd ../..

# Update thornlist
cd manifest
svn switch
cd ..

# Move simfactory away (probably have to do this for Carpet as well)
mv simfactory simfactory.old

# Attempt to upgrade to latest version
bin/GetComponents --update --root=.  manifest/

Modify Ticket

Change Properties
Set your email in Preferences
as accepted The owner will remain Eric Seidel.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Eric Seidel to the specified user.
The owner will be changed from Eric Seidel to anonymous.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.