Re: url scheme for subversion changesets?

On 11/29/05, J. Patrick Bedell <jpb@infoeng.org> wrote:
> Hello,
> I am trying to figure out a URL scheme to specify specific
> changesets from a subversion repository, and I'm writing for some
> suggestions. The simple procedure that I am using is to use the url
> specifying the file in question, and append the query string
> parameter "changeset".

Here is what I did in the Insurrection tools:
http://svn.sinz.com/svn/Insurrection/?Insurrection=diff&getpatch=1&r=271&r2=271&r1=270

Now, why the 3 numbers in my case:
The first number is the peg revision the is to be used to follow the
path. Note that the path does not need to be from trunk as I show
above but may be to a specific sub-tree which may not exist in the
HEAD. The r1 and r2 are the revisions for the "diff" operation.
The above link actuall produces the patch file while the following link
produces an HTML representation of the patch file.

http://svn.sinz.com/svn/Insurrection/?Insurrection=diff&r=271&r2=271&r1=270

For reference, the change/log for this is:
http://svn.sinz.com/svn/Insurrection/trunk/?Insurrection=log&r=271

> Does anyone have a recommendation for how to specify a subversion
> changeset with a URL? Any suggestions at all will be welcome.

The key will be to define your rules. I always make the changeset
and patch code deal from trunk while still providing sub-tree and even
individual file changesets by making more specific paths in the URL.

Due to rename and delete and move operations, the peg revision
is needed, albeit in a more controlled API you may just use the
one revision as the peg revision and the diff revision. In a more
complex/complete API you may want to get a diff or changeset
for a given path as it exists in r344 but the changes that happened
back in r273 which may not be the same path and thus the need for
the peg revision vs the actual revision. The API could be smart and
if no peg revision is given to use either HEAD or the target revision
as the peg revision (I don't know which would be better - the svn
command line assumes HEAD as the peg revision so that may be
better but would make the URL fragile as the HEAD now may no longer
be the HEAD in 3 months and thus would cause the URL to become
broken. Again, this is why I did the full peg and target in my API
such that the URLs will remain valid even if HEAD changes/moves/etc)

--
Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org