SVK repository support

[cboos@…]

This topic was already mentioned on the list of features for the 2.0 Roadmap, so I thought I should created a ticket for it in order to comment on that topic.

Actually, SVK is supported, out of the box, because a SVK repository is just a regular Subversion repository. Simply configuring a Trac environment to use the SVK repository just works.

However, starting from this basic level of support, several SVK-specific enhancements could be made:

• show the list of mirrors
• when displaying a changeset, show if it is one generated by SVK (like those created while synchronizing a mirrored repository)
• annotate branches with their merge tickets
• ...

[otavio]

What you mean with "... Simply configuring a Trac environment to use the SVK repository just works."? I use SVK a lot but all mirrored from original SVN repositories.

Does SVK support to access a remote depotmap? That is what I understood with your comments.

[mrowe]

If you create a Trac environment using /home/username/.svk/local for the path to the Subversion repository, you will be able to browse your SVK repository in Trac.

[otavio]

Sure but this isn't a integration enough to say: SVK just work.

I think maybe Trac shoundn't support SVK for backend but support it's addons for allow more interesting views for user.

[cboos]

Some additional thoughts about mirrors...

Proper SVK support is indeed hard: the difficulty is mainly related to proper handling of mirrors and their changesets. The comments in those changesets will likely contain references to changesets in the original repository.

Several possible scenarii:

• Mirroring a normal SVN repository: a reference to the changeset [123] of the original repos. should actually be linked to the changeset e.g. [5453] in the mirror. Note that SVK allows you to skip changesets, so there's no garantee that you can find a local target for a given reference. Computing the offsets is likely to be a nightmare...
• Mirroring a Trac enabled SVN repository: a reference to the changeset [123] of the original repository could be linked to corresponding Trac. This would avoid the problems mentioned above. Again two possibilities:
  • simply redirect to the remote Trac of that project if it exists. This has the advantage of also correctly handling the reference to tickets and other Trac objects
  • setup a local Trac environment operating on a remote repository, which might be the only possibility if there's no remote Trac server...

This is somehow related to the multiple project support.

[norman@…]

FYI: If you're careful when doing your svk sync (i.e. always sync from the root, and start at revision 2) then you can keep your changeset numbers in sync.

[Tom]

Replying to norman@rasmussen.co.za:

FYI: If you're careful when doing your svk sync (i.e. always sync from the root, and start at revision 2) then you can keep your changeset numbers in sync.

Only if you use a single repository - if you have several repositories checked out in SVK, the changeset numbers go out of sync very quickly.

[norman@…]

Replying to Tom:

Replying to norman@rasmussen.co.za:

FYI: If you're careful when doing your svk sync (i.e. always sync from the root, and start at revision 2) then you can keep your changeset numbers in sync.

Only if you use a single repository - if you have several repositories checked out in SVK, the changeset numbers go out of sync very quickly.

Correct, being careful also include only mirroring a single remote repository per SVK tree. Each mirror needs it's own SVKROOT.

[cboos]

See also google:"svk pullyu"