> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: Tuesday, November 20, 2007 3:39 PM
>
> > >
> > > > Given the above it makes sense that:
> > > > ====================================
----------------- SNIP ----------------
> > > I'm missing something here. If you are working with content that
> > > can't be merged, why is it normal operating procedure to
> do the work
> > > without obtaining a lock? Or in the problem case, why do
> only some
> > > people know to obtain the lock even though other people
> are working
> > > on the same file? Note that if it really is standard
> procedure not
> > > to lock, there won't be any locks for you to see anyway...
> >
> > Yes, you are missing something here. Refer to #2 that you
> quoted, and
> > also to item #3, which for some reason you apparently didn't get to
> > before replying:
> >
> > 3. A lock is dynamically added to a file presumably due to unusal
> > circumstances.
> >
> > It is possible to choose to lock a perfectly normal file, and there
> > ARE valid reasons to do so. To see an example, please go back and
> > read the paragraph following that list of points you
> quoted. When a
> > person does this, nobody else knows UNLESS that person
> decides to send
> > a distribution email to tell them, OR the team leader tells
> the other
> > committers in some fashion.
>
> Right. If some file is completely reorganized, the correct
> way to handle that situation might *also* (but not
> exclusively) be to use locking. The correct way to handle the
> situation is to notify the team some major reworking is going
> on and that the specific file shouldn't be modified. Sending
> such notification to some distribution list would be one of
> the logical ways to do that.
And, apparently, that lock should NOT be easily communicable to other
developers. That is clearly what is being asserted here. One should
communicate the situation in any fashion EXCEPT through Subersion. I
cannot fathom this.
>
> > At no point - ever - did I imply that these files were
> "unmergable" or
> > had a "requires lock" property. If the file already has a property
> > attached that says "you must lock this to edit it", that
> information
> > is CURRENTLY visible in Ankh and Tortoise (immagine that!).
> > Therefore, I have no complaints about that particular feature.
> >
> > All I ask is that MORE INFORMATION which is CURRENTLY AVAILABLE be
> > presented to the developers in an easier to use format that
> requires
> > less work to attain. Why is that such a terrible thing? I am
> > becoming quite frustrated. Can someone at least acknowledge the
> > points I'm making, rather than set up a straw man and set
> fire to it?
>
> Because it won't solve the use case you're giving us here: if
> the file is locked, but it's not usually locked, why should
> the developer at all decide to update it and see if it's
> locked? For normal day-to-day operations it would be valid
> for him to start working on the file even before updating it,
> because any server side changes will be merged in anyway.
So you see no value, as a developer, in refreshing your workspace with
any updates currently on the server before beginning work, or continuing
work from a prior day? You'd rather be blissfully ignorant of anybody
else's changes, wait as long as possible to merge, and then deal with
conflicts that probably would not have existed if you updated 8 hours
ago? Really? I have to tell you, I think that is a fabulous way to
make more work for yourself. Have fun. I respectfully suggest that at
least some of us would rather not work that way. Are you suggesting we
are incorrect, and should get with the plan?
> Further more do your changes still have a very high chance of
> presenting developers with the wrong information. This means
> that very shortly after introducing this change people will
> learn to discard the information presented to them.
This statement appears to state that developers should and do ignore the
efforts of their peers because clearly their peers have no clue.
Interesting. What wrong information is this? What is the impact of
this wrong information? Are you saying that by making lock status
available that developers will suddenly choose to ignore other people's
work? Or, are you saying that because a lock indicator on their GUI
will sometimes be out of date, that they will no longer trust
Subversion? Are we really so stupid that we don't understand the
concept up "update"? We can't handle this information? It is
meaningless to know the status of a server at a specific point in time?
Here's an idea, how's about we add a "last updated" timestamp to the
information?
>
> Also, there is a lock discovery API which all clients can use
> (if only it were by running 'svn status -u' under the hood),
> so GUI clients which want to present (up-to-date) locking
> information can do so by presenting the latest on the server.
> These apis are the same for all clients, so it should be no
> harder to implement this on TSVN than it is to do so in
> smartsvn or any other client out there.
Certainly, right now, that information is available separately and on
the fly. My point is, and has always been, that it should also be added
to the standard workspace cache. It should be done by Subversion
because dozens of GUI clients that are unrelated to each other will then
be able to query a standard format and present the contents on the
screen.
Horrible, isn't it? You apparently would rather let each product team
come up with their own cache format for their own plugin, and woe be it
to the poor developer who uses two different tools at once (like us,
Ankh and Tortoise). As soon as I update in Tortoise, the information is
there, but Ankh is blissfully unaware, and the developr very quickly
learns not to trust the information.
> bye,
>
>
> Erik.
>
Yeah. Clearly I'm not convincing anybody. I see the arguments against
this feature come down to these points (combining Les' and Erik's
arguments):
1. You shouldn't work "that" way, and if you do, Subversion should not
help you stop.
2. Information about major code efforts should be communicated by any
means EXCEPT Subversion.
3. The lock information might be out of date as soon as it is retrieved
(but version information won't?)
4. If a GUI client wants to offer the feature, each one should do it in
their own way.
5. As soon as lock communication is available, developers will stop
trusting Subversion and each other.
6. It is perfectly normal for a developer to simply decide the lock-er
is clueless, break the lock, and continue doing their own thing.
I totally disagree with all those reasons, but there's nothing I can do
about it. Since nobody else is jumping in to my support, I can only
conclude that I am the only one who finds this peculiar. At this point,
all I can do is lay out these points for posterity and let it drop, so
that is what I am doing.
On the bright side, I now have a good reason to learn how to make my own
additions to Subversion. My expertise is Java and C#, but I can learn
gnu c. I just need to carve out the time somehow. Of course, it'll
never be merged into the project, but at least I can have the
satisfaction of doing it.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 16:39:34 2007