Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-vcm-dev] Adding/Refreshing CVS resources programmat ically 
   From: Kevin McGuire [mailto:Kevin_McGuire@xxxxxxx]

   > We've tried using the current setup, but it will involve putting
   > unreasonable requirements on the user (interpreting cryptic CVS
   > error messages and figuring out how to resolve conflicts, for
   > example)

   I don't see how having an API is going to allow you to avoid the conflict
   problem.  There's automerge in CVS, but some conflicts can't be
automerged.
   For control/meta files, manual merging is generally preferred.

   I haven't looked at Geoff's WVCM yet, but I assume that a
   repository neutral API is unlikely to give you auto-merge on
   commit, since for example in CVS merging is done on update, not on
   commit.  Rather, most implementors of the API (cvs included) would
   likely just return an error on the conflict case and expect (you)
   the caller to sort it out.  Or its a pessimistic provider and
   you'ld fail on the checkout for conflicts.  Geoff?

Yes, the WVCM API is as Kevin describes, i.e. if you have checked
out (unreserved) a version on a branch, and someone has checked in
a successor to that version on that branch, then the WVCM API will
throw an appropriate exception when you try to checkin, and the client
is then responsible for downloading the new version, helping the
user perform the merge, and trying the checkin again, this time
against the new version you downloaded.  Of course, someone else
may have gotten in ahead of you, and you'll have to repeat the process.

Alternatively, as Kevin indicates, you could reserve the branch in
the checkout, and then you know nobody else will be able to checkin
ahead of you on that branch.

The WVCM API does provide support for server-side merging, but only
from version to version (i.e. if you have checked in a version on one
branch, and want to merge that version to a checked in version on
another branch).

   It seems that you are hoping an API will shield you from the
   intricacies of the repository.  I don't know of a way to make that
   true - the caller (you, or the user) must always deal with such
   complications as you listed.

The client would be protected from some of the intricacies of a
particular repository, in that an implementation of WVCM is
responsible for interpreting the obscure error/status responses of the
repository, and converting them into one of a standard set of
exceptions (better that this be done once by a WVCM implementation,
than that every client have to deal with it).  This should at least
simplify some aspects of his client.

Cheers,
Geoff



   From birdo@xxxxxxxxxxxx:

   On Wednesday 04 September 2002 05:49, you wrote:
   > Roberto,
   >
   > Do you require that the resources be added to version control
immediately
   > or are you just concerned that a user may miss committing a resource?
   We've
   > had the same problem with the .project file. We considered
automatically
   > adding it to version control but decided against it because some user
do
   > not want to (or can't) store this file in the repository. Our solution
   for
   > CVS is to make it appearent to the user when files are not under
version
   > control (using decorators and prompting) but to make it easy for them
to
   > commit these files. To this end, commiting in the sync view will prompt
   to
   > add unadded resources and the plan is to give this same behavior to
Team
   >
   > Commit (see bug 22372
http://dev.eclipse.org/bugs/show_bug.cgi?id=22372).
   > Do you think that such facilities would be enough for you or do you
   really
   > feel that you need a standard API to add resources?
   >
   > Michael

   We've tried using the current setup, but it will involve putting
   unreasonable
   requirements on the user (interpreting cryptic CVS error messages and
   figuring out how to resolve conflicts, for example), so yes, we will
really

   need a standard API to handle common operations (at least add, checkout,
   commit, update, and a hook to automatically resolve conflicts).

Back to the top