You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2005/02/26 10:04:56 UTC

new functions in 1.2

Hi,

I've just browsed through the API's which will be introduced in 1.2 and 
I don't quite understand the docs of some of them.

svn_client_status2()
--------------------
the doc for svn_client_status() says:
"Similar to svn_client_status2(), but with the ignore_externals 
parameter always set to TRUE."

Shouldn't that be "FALSE"? I mean an 'svn st' now always shows the 
externals, so the externals are _not_ ignored now?

svn_client_diff_peg2()
----------------------
The doc for svn_client_diff_peg() tells me:
"Similar to svn_client_diff_peg2(), but with the force parameter always 
set to FALSE."
But the "force" param isn't documented in svn_client_diff_peg2(). What 
does it do?

svn_client_update2()
--------------------
"The paths in paths can be from multiple working copies from multiple 
repositories, but even if they all come from the same repository there 
is no guarantee that revision represented by svn_opt_revision_head will 
remain the same as each path is updated."

Why not just do what TSVN does now in such a case?
- get the UID of the targets.
- if all UID's are the same, fetch the HEAD revision
- now update to that fetched HEAD revision (not HEAD but the specific 
revision).


Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: new functions in 1.2

Posted by "C. Michael Pilato" <cm...@collab.net>.
SteveKing <st...@gmx.ch> writes:

> Hi,
> 
> I've just browsed through the API's which will be introduced in 1.2
> and I don't quite understand the docs of some of them.
> 
> svn_client_status2()
> --------------------
> the doc for svn_client_status() says:
> "Similar to svn_client_status2(), but with the ignore_externals
> parameter always set to TRUE."
> 
> Shouldn't that be "FALSE"? I mean an 'svn st' now always shows the
> externals, so the externals are _not_ ignored now?

That's a bug, it's likely my fault, but regardless, I will fix it.
Done.  r13176.  Thanks, Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: new functions in 1.2

Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 26 Feb 2005, SteveKing wrote:

> svn_client_diff_peg2()
> ----------------------
> The doc for svn_client_diff_peg() tells me:
> "Similar to svn_client_diff_peg2(), but with the force parameter always
> set to FALSE."
> But the "force" param isn't documented in svn_client_diff_peg2(). What
> does it do?
>
The same as force in svn_client_diff2. Documented "by reference".

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: new functions in 1.2

Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 26 Feb 2005, Holger Hoffstaette wrote:

> On Sat, 26 Feb 2005 11:04:56 +0100, SteveKing wrote:
>
> > I've just browsed through the API's which will be introduced in 1.2 and I
> > don't quite understand the docs of some of them.
> >
> > svn_client_status2()
> > --------------------
> > the doc for svn_client_status() says: "Similar to svn_client_status2(),
> > but with the ignore_externals parameter always set to TRUE."
> >
> > Shouldn't that be "FALSE"? I mean an 'svn st' now always shows the
> > externals, so the externals are _not_ ignored now?
>
> I cannot answer that particular question but would suggest that the
> functions be renamed so that their meaning becomes clear. Otherwise in 3
> years there'll be svn_foo_bar(1|2|3|4|5) and nobody will remember what

Note that you can read aobut our deprecation policy in HACKING. You're
only supposed to use the latest version of a function available (if you
don't need to be compatible with a particular version of the libs.)

> they're supposed to do anymore. Always assume the documentation is wrong.

Well, comments get out-dated over time, but if the API documentation is
wrong, it should be fixed.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: new functions in 1.2

Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Feb 26, 2005, at 6:38 AM, Holger Hoffstaette wrote:

> On Sat, 26 Feb 2005 11:04:56 +0100, SteveKing wrote:
>
>> I've just browsed through the API's which will be introduced in 1.2 
>> and I
>> don't quite understand the docs of some of them.
>>
>> svn_client_status2()
>> --------------------
>> the doc for svn_client_status() says: "Similar to 
>> svn_client_status2(),
>> but with the ignore_externals parameter always set to TRUE."
>>
>> Shouldn't that be "FALSE"? I mean an 'svn st' now always shows the
>> externals, so the externals are _not_ ignored now?
>
> I cannot answer that particular question but would suggest that the
> functions be renamed so that their meaning becomes clear. Otherwise in 
> 3
> years there'll be svn_foo_bar(1|2|3|4|5) and nobody will remember what
> they're supposed to do anymore. Always assume the documentation is 
> wrong.

Not true.  Once Subversion goes to 2.0, svn_foo_bar2 functions will be 
renamed to fvn_foo_bar, and the old (deprecated) functions will go away

While we may very well wind up with svn_foo_bar_4 (although there's a 
slight chance), it's not something that we'll live with forever.

-Fitz 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: new functions in 1.2

Posted by Holger Hoffstaette <ho...@wizards.de>.
On Sat, 26 Feb 2005 11:04:56 +0100, SteveKing wrote:

> I've just browsed through the API's which will be introduced in 1.2 and I
> don't quite understand the docs of some of them.
> 
> svn_client_status2()
> --------------------
> the doc for svn_client_status() says: "Similar to svn_client_status2(),
> but with the ignore_externals parameter always set to TRUE."
> 
> Shouldn't that be "FALSE"? I mean an 'svn st' now always shows the
> externals, so the externals are _not_ ignored now?

I cannot answer that particular question but would suggest that the
functions be renamed so that their meaning becomes clear. Otherwise in 3
years there'll be svn_foo_bar(1|2|3|4|5) and nobody will remember what
they're supposed to do anymore. Always assume the documentation is wrong.
Just a humble suggestion. :)

-h



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Non-atomicity of svn_client_update2() [was: new functions in 1.2]

Posted by Roel Harbers <ro...@roelharbers.nl>.
Julian Foad wrote:
> SteveKing wrote:
> 
>> svn_client_update2()
>> --------------------
>> "The paths in paths can be from multiple working copies from multiple 
>> repositories, but even if they all come from the same repository there 
>> is no guarantee that revision represented by svn_opt_revision_head 
>> will remain the same as each path is updated."
> 
> 
> It would be good to remove that caveat.  It's pretty horrible really.
> 
>> Why not just do what TSVN does now in such a case?
>> - get the UID of the targets.
>> - if all UID's are the same, fetch the HEAD revision
>> - now update to that fetched HEAD revision (not HEAD but the specific 
>> revision).
> 
> 
> I don't see much point in fixing just one case (all UIDs the same), even 
> if that is the most common case.  We should fix it properly:
> 
> - Find all the different repositories of TARGETs.
> - For each repository:
>   - Find the HEAD revision of that repository.
>   - Update all the TARGETs that are in that repository to that revision 
> number.
> 
> Anyone fancy doing that (without making too many extra network 
> round-trips)?
> 
> Are there other APIs that have a similar problem?

I don't know about the API, but from a user perspective, it would be 
great if I could commit to several disjunct working copies from the same 
  repo in a single revision.

Roel Harbers


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Non-atomicity of svn_client_update2() [was: new functions in 1.2]

Posted by Julian Foad <ju...@btopenworld.com>.
SteveKing wrote:
> svn_client_update2()
> --------------------
> "The paths in paths can be from multiple working copies from multiple 
> repositories, but even if they all come from the same repository there 
> is no guarantee that revision represented by svn_opt_revision_head will 
> remain the same as each path is updated."

It would be good to remove that caveat.  It's pretty horrible really.

> Why not just do what TSVN does now in such a case?
> - get the UID of the targets.
> - if all UID's are the same, fetch the HEAD revision
> - now update to that fetched HEAD revision (not HEAD but the specific 
> revision).

I don't see much point in fixing just one case (all UIDs the same), even if 
that is the most common case.  We should fix it properly:

- Find all the different repositories of TARGETs.
- For each repository:
   - Find the HEAD revision of that repository.
   - Update all the TARGETs that are in that repository to that revision number.

Anyone fancy doing that (without making too many extra network round-trips)?

Are there other APIs that have a similar problem?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org