Opened 20 years ago
Last modified 2 years ago
#978 new enhancement
Specify InterTrac context for a repository
Reported by: | Christian Boos | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | next-major-releases |
Component: | version control | Version: | devel |
Severity: | normal | Keywords: | svk repository |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
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
- …
Attachments (0)
Change History (18)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
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.
comment:3 by , 20 years ago
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.
comment:4 by , 20 years ago
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.
comment:5 by , 19 years ago
Component: | general → version control |
---|---|
Owner: | changed from | to
follow-up: 7 comment:6 by , 18 years ago
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.
follow-up: 8 comment:7 by , 17 years ago
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.
comment:8 by , 17 years ago
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.
comment:11 by , 14 years ago
Milestone: | triaging → 0.13 |
---|---|
Summary: | SVK repository support → Specify InterTrac context for a repository |
Well, SVK's not completely dead, but close enough that we could close this ticket ;-)
However, I'd still like to implement the second point in comment:4, the possibility to define an InterTrac "context" for a repository, so that wikifying the changeset comments could redirect to the "proper" Trac (e.g. if a commit references #978 and the .intertrac property would be 'trac', this would result in a link to http://trac.edgewall.org/ticket/978 and not in the local Trac). This will be very useful for any flavor of DVCS, where the repository can be cloned but the Trac is still "central".
comment:12 by , 14 years ago
Owner: | changed from | to
---|
comment:15 by , 12 years ago
Milestone: | next-stable-1.0.x → next-dev-1.1.x |
---|
well, once again… next-dev
comment:16 by , 10 years ago
Milestone: | next-dev-1.1.x → next-major-releases |
---|
Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.
comment:17 by , 10 years ago
Owner: | removed |
---|
comment:18 by , 9 years ago
Reporter: | changed from | to
---|
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.