ability to rerun sync.pl (such as via cron, etc) about bugzilla-vcs HOT 17 CLOSED

Hmm, you actually are supposed to be able to run sync.pl repeatedly. Which VCS 
are you using? I'll look into it.

I'm using BZR - I ran it once against a trunk, and then again and it added the 
same change note twice.

To be precise, I ran it against a single tree, as in:

/bzr/project1

which has branches below it:

/bzr/project1/trunk
/bzr/project1/version2

and so on.

Then I ran it against 

/bzr/

which has additional projects (project2, etc) setup in a similar manner.

Afterwards, I noted that a patch for project1 was shown twice in the 
appropriate bug.

In fact, I just found one bug that has 4 identical commits on it:

Commits:    
1896 by Bill <et> at 2010-08-09 09:07:10 PDT
1896 by Bill <et> at 2010-08-09 09:07:10 PDT
1896 by Bill <et> at 2010-08-09 09:07:10 PDT
1896 by Bill <et> at 2010-08-09 09:07:10 PDT

I'm not sure how the internals of this work, but if I were to truncate the 
tables used by vcs and rerun the script, would it clear this up? Or is there a 
given table to truncate?

Ah ha.

The --repo argument to sync.pl must never change. Otherwise you will indeed get 
duplicates. It's just the --project argument that can change.

Yes, you can truncate both tables starting with "vcs_*".

Excellent, truncating the tables and rerunning the sync script seems to have 
worked.

Does the script have to be run from the bugzilla directory or can I call it 
from anywhere?

sync.pl does have to be run from the Bugzilla directory.

I'll keep this bug open because I may still want to have a way to assure that a 
single "project URL plus commit" doesn't get duplicated.

Hmmm. It still seems to be adding multiple copies - I've run it a few times, 
exactly the same each time, and I see the same number added.

Oh wait, I see what it's doing! I have multiple branches - such as:

project/trunk
project/branch1
project/branch2

and the bug was fixed in trunk before it was branched, so it sees it as "fixed" 
in all three branches and reports it for each one.

Ahhh, ah ha! Sounds like I need to keep track of the revid of each revision and 
make sure that I don't duplicate them within the same repository.

Okay, I'm going to release a new version of VCI that contains the features that 
I need for this, and then I'll update this extension to use them.

I've uploaded VCI 0.7.0_1, which contains the ability to generate a UUID for 
commits for every VCS. Now I have to start using this feature in the VCS 
extension.

Okay, I've fixed this! Now, commits with the same revid across different 
branches won't be imported as duplicates by sync.pl. If you currently have 
duplicates in your database when you upgrade, you'll get errors and you'll have 
to remove them using manual SQL.

With the way this change works, you'll generally want to be sure that you sync 
the trunk of each project before you sync the branches, so that the trunk 
commits show up on the trunk. I may actually make a change to sync.pl so that 
it always sorts branches named "trunk" first when syncing.

In order for the new feature to work, you need both the development version of 
bugzilla-vcs and VCI (straight from version control, for both). If you could 
grab those and test this out in your environment and let me know how things go, 
I would totally appreciate that. :-)

[deleted comment]

I am testing VCS-0.2 now and will let you know how it goes.

Awesome. It appears to be working fine - the "trunk" feature would be cool but 
as it is it ends up picking the lowest version as my branches are:

project/2.2b1
project/2.2b4
project/2.3
project/trunk

and that's cool, too, as it lets me see when it was fixed.

Great! I'm so glad to hear that it worked for you. :-)