4 messages in com.perforce.revml[revml] copy_revs ?| From | Sent On | Attachments |
|---|---|---|
| Timothee Besset | 15 Dec 2003 14:04 | |
| Timothee Besset | 16 Dec 2003 03:15 | |
| Barrie Slaymaker | 16 Dec 2003 04:13 | |
| Barrie Slaymaker | 16 Dec 2003 05:31 |
| Subject: | [revml] copy_revs ? |
|---|---|
| From: | Barrie Slaymaker (barr...@slaysys.com) |
| Date: | 12/16/2003 04:13:41 AM |
| List: | com.perforce.revml |
On Tue, Dec 16, 2003 at 12:15:38PM +0100, Timothee Besset wrote:
On Mon, 15 Dec 2003 23:05:02 +0100 Timothee Besset <tti...@idsoftware.com> wrote:
This all seems to evolve around copy_revs. It looks like the VSS and the P4 sources are doing the job in copy_revs .. which I don't see mentioned in the documentation. Actually, there is one spot in the source where it says copy_revs is deprecated..
Silly me. You *did* mention copy_revs. I'll look at CVS or VSS source driver to learn about the data it should return.
It is supposed to scan the metadata and then send it to the destination. Generally, this is done by calling queue_rev for each VCP::Rev created. Because most repositories emit log from most recent to oldest, you can get at the last rev that have been queued and the last rev in each filebranch that has been queued in order to set its previous_id(). See last_rev() and last_rev_for_filebranch().
It's also deprecated as in I haven't had time to replace it, but I need to. If you put all your metadata scanning code in a subroutine called scan_metadata(), it'll be forward compatible. I'll change the existing sources' APIs to that soon.
I used my devnet account to ask the NxN people about their perl API, will see what they have to say about it.
Also asked for a guest account on public.perforce.com
Excellent on all accounts! Thanks.
- Barrie