You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Roghair, Frank" <fr...@philips.com> on 2012/06/13 13:59:14 UTC

Retrieve pristine version of a replaced file via the svn api

Hi All,

Developers in our organization need to have their changes reviewed before the commit is allowed.
For this purpose a customized tool was created called createReviewChangeSet.exe.
The tool does create a zip file containing a text file "changeSet.txt" which contains the change list with a explanation why the changes are needed.
Beside this file two directories "old" and "new" are part of the zip file.
The old directory contains the previous version of the file and the new directory contains the new version of the file.
The complete file path is part of the zip file.

Structure changeset.zip
                New
                        <dir>
                                <file>
                Old
                         <dir>
                                <file>
Changeset.txt

This tool was created for subversion 1.6 and based on the internals of subversion.
Basically what happened the tool copied the new file and the file.svn-base to a directory and afterwards that directory is zipped.
In case of a replaced file the copy is slightly different because the file.svn-revert was used.

                Modified file : actions   copy <new file> -> New/<di>r/<file>  and copy <file>.svn-base -> Old/<dir>/<file>
                Replaced file : actions   copy <new file> -> New/<di>r/<file>  and copy <file>.svn-revert -> Old/<dir>/<file>

Currently the preparations are ongoing to move to subversion 1.7.
The tool which was based on the internals of the working copy didn't work anymore.
Decided was to rewrite the tool using sharpsvn, meaning use the API and don't depend on the subversion internals anymore.
The new tool does work except for replaced files, I am unable to find a method to retrieve the pristine copy in that case.

The following code is used
FileInfo fileInfo = new FileInfo(targetOld);
       Directory.CreateDirectory(fileInfo.Directory.ToString());
       SvnExportArgs svnExportArgs = new SvnExportArgs();
       svnExportArgs.Revision = SvnRevision.Base;
       svnClient.Export(fileName, targetOld, svnExportArgs);

filename is the changed file including path in the working copy.
targetOld is the location where the file will end up in the exported directory structure.

The above code does work fine for modified files.
Unfortunate for a replaced file SvnRevision.Base doesn't return the pristine version.

Is there something like SvnRevision.Pristine ?

I did have contact with Bert Huijben, according to him this functionality is not available in the subversion API and therefore also not in the sharpsvn API.
Did I miss something or can this be handled as a change request for a future release?

Thanks in advance.

With kind regards,

Frank Roghair

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

Re: Retrieve pristine version of a replaced file via the svn api

Posted by Branko Čibej <br...@apache.org>.
On 13.06.2012 17:10, Julian Foad wrote:
> Branko Čibej wrote:
>
>> However, I shall now
>> demonstrate that Subversion already provides that functionality:
> This demo doesn't seem to include the replacement of a node, which is the case in question.

Well sure, It's not intended to; after all, their own tool obviously
doesn't handle replacements if it provides input for code review in a
format that ignores all tree-level changes. It doesn't take much effort
to run "svn status" first and look for /^R/.

One alternative in that case is to write a --diff-cmd compliant tool
that will record old and new file names to populate their
change-description file (along with building a tree of contents),
although you won't get keywors expanded in that case.


But that's all beside the point. Providing an API that locates pristine
files on disk is inherently wrong.

  * keyword expansion, eoln conversion, etc. have not been performed
  * the files may be compressed, or packed, or both
  * someday in the future, pristine files may not even exist

All of the above is solved by using "svn cat" to get the /contents/ of
the pristine file, which really is all they're interested in. And it
avoids having people mess about in the .svn directory.


-- Brane


Re: Retrieve pristine version of a replaced file via the svn api

Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:

> On 13.06.2012 16:33, Julian Foad wrote:
>>  I think this is a valid enhancement request: to have an API to get the 
>> WC base tree (not what the UI calls "base", but the result of the last 
>> checkout/update, which is called BASE (usually with capital letters) 
>> in libsvn_wc).  By "get the tree" I mean an API that covers getting the 
>> directory tree structure, text and properties, and also perhaps other 
>> relevant metadata such as revision numbers, last-changed info, etc.
> 
> You're overreacting to their request,

Yes, you're right; I should have put my pet project ideas in a new email thread, not here.

But my main point is that *if* there is missing API functionality then it's perfectly reasonably to request for the missing bit to be filled in.  (I haven't checked for myself that it really is missing functionality.)


> as you note below. There's also
> this thing called "svn diff" that already tells you everything you 
> need to know about the changes in the working copy.
> 
>>  We could of course just add one function that does the specific thing that 
>> you have found to be missing.
> 
> I don't believe this project should be in the business of helping people
> to avoid using a version control system.

I totally agree, but we should present a complete logical interface to the SCM.

> However, I shall now
> demonstrate that Subversion already provides that functionality:

This demo doesn't seem to include the replacement of a node, which is the case in question.

- Julian


> brane@zulu$ svnadmin create r
> brane@zulu$ svn co file://`pwd`/r w
> Checked out revision 0.
> brane@zulu$ cd w
> brane@zulu/w$ echo foo > f
> brane@zulu/w$ svn add f
> A         f
> brane@zulu/w$ svn ci -m ''
> Adding         f
> Transmitting file data .
> Committed revision 1.
> brane@zulu/w$ echo bar >> f
> brane@zulu/w$ svn diff
> Index: f
> ===================================================================
> --- f    (revision 1)
> +++ f    (working copy)
> @@ -1 +1,2 @@
> foo
> +bar
> brane@zulu/w$ svn cat f > g
> brane@zulu/w$ diff -u f g
> --- f    2012-06-13 16:38:49.000000000 +0200
> +++ g    2012-06-13 16:39:01.000000000 +0200
> @@ -1,2 +1 @@
> foo
> -bar
> brane@zulu/w$
> 
> 
> -- Brane
> 

Re: Retrieve pristine version of a replaced file via the svn api

Posted by Branko Čibej <br...@apache.org>.
On 13.06.2012 16:33, Julian Foad wrote:
> (I'm not cross-posting to users@.)
>
> I think this is a valid enhancement request: to have an API to get the WC base tree (not what the UI calls "base", but the result of the last checkout/update, which is called BASE (usually with capital letters) in libsvn_wc).  By "get the tree" I mean an API that covers getting the directory tree structure, text and properties, and also perhaps other relevant metadata such as revision numbers, last-changed info, etc.

You're overreacting to their request, as you note below. There's also
this thing called "svn diff" that already tells you everything you need
to know about the changes in the working copy.

> We could of course just add one function that does the specific thing that you have found to be missing.

I don't believe this project should be in the business of helping people
to avoid using a version control system. However, I shall now
demonstrate that Subversion already provides that functionality:

brane@zulu$ svnadmin create r
brane@zulu$ svn co file://`pwd`/r w
Checked out revision 0.
brane@zulu$ cd w
brane@zulu/w$ echo foo > f
brane@zulu/w$ svn add f
A         f
brane@zulu/w$ svn ci -m ''
Adding         f
Transmitting file data .
Committed revision 1.
brane@zulu/w$ echo bar >> f
brane@zulu/w$ svn diff
Index: f
===================================================================
--- f	(revision 1)
+++ f	(working copy)
@@ -1 +1,2 @@
 foo
+bar
brane@zulu/w$ svn cat f > g
brane@zulu/w$ diff -u f g
--- f	2012-06-13 16:38:49.000000000 +0200
+++ g	2012-06-13 16:39:01.000000000 +0200
@@ -1,2 +1 @@
 foo
-bar
brane@zulu/w$


-- Brane


Re: Retrieve pristine version of a replaced file via the svn api

Posted by Julian Foad <ju...@btopenworld.com>.
(I'm not cross-posting to users@.)

I think this is a valid enhancement request: to have an API to get the WC base tree (not what the UI calls "base", but the result of the last checkout/update, which is called BASE (usually with capital letters) in libsvn_wc).  By "get the tree" I mean an API that covers getting the directory tree structure, text and properties, and also perhaps other relevant metadata such as revision numbers, last-changed info, etc.


We could of course just add one function that does the specific thing that you have found to be missing.

This does remind me of an area I'd like to improve.  The current APIs have lots 
of inconsistencies and differences in terminlogy and no single point of 
definition for exactly what tree is referred to.  I think we should develop a uniform API that provide access to any tree of Subversion data: a WC base tree, a WC "pristine" (otherwise known as "base" in the UI) tree, a WC "actual" tree, or a tree that exists at a given revision and path in a repository.  In each case, I mean a complete tree, so for example a WC "actual" tree would not be just the set of nodes mentioned in the WC 'ACTUAL_NODE' table.  This API would be analogous and complementary to the way that svn_delta_editor_t or svn_editor_t provides a uniform way to communicate a *change* to any tree without being tied to what particular tree it is.  The "tree-read-api" branch I created a few months back was an exploration of this idea.  I don't think what I put in that branch was a good API design, but I think it would be really useful to create something achieving that goal of a uniform API, with a small set of implementations that give
 access to the specific kinds of tree that I mentioned.


- Julian




>________________________________
> From: "Roghair, Frank" <fr...@philips.com>
>To: "users@subversion.apache.org" <us...@subversion.apache.org>; "dev@subversion.apache.org" <de...@subversion.apache.org> 
>Sent: Wednesday, 13 June 2012, 13:59
>Subject: Retrieve pristine version of a replaced file via the svn api
> 
>
> 
>Hi All,
> 
>Developers in our organization need to have their changes reviewed before the commit is allowed.
>For this purpose a customized tool was created called createReviewChangeSet.exe.
>The tool does create a zip file containing a text file “changeSet.txt” which contains the change list with a explanation why the changes are needed.
>Beside this file two directories “old” and “new” are part of the zip file. 
>The old directory contains the previous version of the file and the new directory contains the new version of the file.
>The complete file path is part of the zip file.
> 
>Structure changeset.zip
>                New
>                        <dir>
>                                <file>
>                Old
>                         <dir>
>                                <file>
>Changeset.txt
> 
>This tool was created for subversion 1.6 and based on the internals of subversion.
>Basically what happened the tool copied the new file and the file.svn-base to a directory and afterwards that directory is zipped.
>In case of a replaced file the copy is slightly different because the file.svn-revert was used.
> 
>                Modified file : actions   copy <new file> -> New/<di>r/<file>  and copy <file>.svn-base -> Old/<dir>/<file>
>                Replaced file : actions   copy <new file> -> New/<di>r/<file>  and copy <file>.svn-revert -> Old/<dir>/<file>
> 
>Currently the preparations are ongoing to move to subversion 1.7.
>The tool which was based on the internals of the working copy didn’t work anymore.
>Decided was to rewrite the tool using sharpsvn, meaning use the API and don’t depend on the subversion internals anymore.
>The new tool does work except for replaced files, I am unable to find a method to retrieve the pristine copy in that case.
> 
>The following code is used 
>FileInfofileInfo = new FileInfo(targetOld);
>       Directory.CreateDirectory(fileInfo.Directory.ToString());
>       SvnExportArgs svnExportArgs = new SvnExportArgs();
>       svnExportArgs.Revision = SvnRevision.Base;                         
>       svnClient.Export(fileName, targetOld, svnExportArgs);
> 
>filename is the changed file including path in the working copy.
>targetOld is the location where the file will end up in the exported directory structure.
> 
>The above code does work fine for modified files.
>Unfortunate for a replaced file SvnRevision.Base doesn’t return the pristine version.
> 
>Is there something like SvnRevision.Pristine ?
> 
>I did have contact with Bert Huijben, according to him this functionality is not available in the subversion API and therefore also not in the sharpsvn API.
>Did I miss something or can this be handled as a change request for a future release?
> 
>Thanks in advance.
> 
>With kind regards,
> 
>Frank Roghair
>>________________________________
> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
> 
>
>

Re: Retrieve pristine version of a replaced file via the svn api

Posted by Branko Čibej <br...@apache.org>.
On 13.06.2012 13:59, Roghair, Frank wrote:
> Hi All,
>
> Developers in our organization need to have their changes reviewed before the commit is allowed.

All that effort, just to avoid using per-task branches and doing the
review before merging to the mainline.

-- Brane