ability to rerun sync.pl (such as via cron, etc)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. It would be (potentially) simpler for our setup to just run sync.pl 
repeatedly.
2. However, it seems if you do that, you get duplicate commit logs added to the 
bug.

What is the expected output? What do you see instead?
Would it be possible to make sync.pl ignore already existing commit logs that 
it has added previously?

What version of the product are you using? On what operating system?
Latest, with patch 21_20 on Bugzilla 3.6.2

Please provide any additional information below.

Original issue reported on code.google.com by bomb...@bombcar.com on 8 Oct 2010 at 6:29

[GoogleCodeExporter]

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

Original comment by avatrax...@gmail.com on 9 Oct 2010 at 4:50

[GoogleCodeExporter]

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

Original comment by bomb...@bombcar.com on 9 Oct 2010 at 9:52

[GoogleCodeExporter]

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.

Original comment by bomb...@bombcar.com on 11 Oct 2010 at 4:04

[GoogleCodeExporter]

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

Original comment by bomb...@bombcar.com on 11 Oct 2010 at 5:49

[GoogleCodeExporter]

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?

Original comment by bomb...@bombcar.com on 11 Oct 2010 at 7:48

[GoogleCodeExporter]

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_*".

Original comment by avatrax...@gmail.com on 12 Oct 2010 at 5:02

[GoogleCodeExporter]

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?

Original comment by bomb...@bombcar.com on 12 Oct 2010 at 6:21

[GoogleCodeExporter]

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.

Original comment by avatrax...@gmail.com on 12 Oct 2010 at 9:12

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

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.

Original comment by bomb...@bombcar.com on 13 Oct 2010 at 3:29

[GoogleCodeExporter]

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.

Original comment by avatrax...@gmail.com on 13 Oct 2010 at 9:48

[GoogleCodeExporter]

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.

Original comment by avatrax...@gmail.com on 16 Oct 2010 at 1:52

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by avatrax...@gmail.com on 16 Oct 2010 at 3:32

[GoogleCodeExporter]

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. :-)

Original comment by avatrax...@gmail.com on 16 Oct 2010 at 6:36

• Changed state: Fixed
• Added labels: Milestone-Release0.2

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by bomb...@bombcar.com on 3 Nov 2010 at 11:32

[GoogleCodeExporter]

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.

Original comment by bomb...@bombcar.com on 3 Nov 2010 at 11:55

[GoogleCodeExporter]

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

Original comment by avatrax...@gmail.com on 4 Nov 2010 at 12:55

• Changed state: Verified