kfogel@collab.net wrote:
>Seriously, when I revert a change, it doesn't necessarily mean I'm not
>working on that problem anymore, it just means I'm undoing a false
>start. I don't think it would be very intuitive for 'revert' to
>unlock things the way 'commit' does -- they're not really symmetrical,
>because they don't both mean "I'm done with this problem now.".
>
>
>
PMFCI (thats "pardon me for chipping in" since I've been lurking on this
for ages)
The basic problem seems to be a wide variation in what people use (or
anticipate using) locks for. Subversion needs to be usable for as many
as possible.
Looking at the two main use cases I have (pardon the shouting for WHAT
USER TYPES)
Editing a non-binary file
- SVN CO gets an initial working copy of the file - it does not lock
- SVN UP gets an update of someone elses changes to the file
ok now I start working on the file, making changes
- SVN UP still gets an update of someone elses changes to the file
(possibly merging)
- SVN CI uploads the changes although I have not necessarily finished
working with the file
("Hey Walter, can I have that bug fix you just put in Blahblah.cs?"
"Sure, I'll just check it in")
I continue working on the file, making more changes
- SVN CI uploads my finished change.
OK, now let's throw a binary file into the mix
- SVN CO gets initial copy, does not lock
- SVN UP gets update, does not lock
ok, now I want to start working on the file
- SVN LOCK to get myself exclusive access to the file
now I start working on the file
- SVN UP will get updates to other files, but not this one (because I
have it locked, noone else can have made changes, right? <g>)
- SVN CI uploads the changes so far
I keep working on the file
- SVN CI + UNLOCK uploads my finished change
This would indicate to me that CI should *not* lock the file same as CO
does not lock it. And to avoid making the 'finished with' step two
commands, either a new command (SVN CU, SVN FINISH?) or a switch (SVN CI
--AND-UNLOCK) is required. Personally I would prefer a new command - SVN
CU does have a nice ring to it, although I'm sure I would be tempted to
dub it "Chuck Up"! I don't like the idea, as I saw suggested in one
message, of making SVN COMMIT do one thing, and SVN CI the other. To me
they have the same meaning, which is "commit the current version of my
work to the repository, because I'm happy enough with it (committed to
it) that I'll let others see it").
The two main schools of thought on locking seem to be "Locking is part
of the checkout/checkin process" and "locking is completely separate to
the checkout/in process". As Subversion comes from a Copy-Modify-Merge
model, I feel it should be independent, but it should be possible to
build a Lock-Modify-Commit process easily.
Now there are actually three main possibilities
1.- upload changed files without releasing any locks on them (SVN CI)
2.- upload changed files and release locks on them (SVN CU)
3.- upload changed files and release locks on them and on any
unmodified files (SVN CU --ALL?)
Personally all three seem perfectly valid to me and I might want to do
any of them, although the third is less of a problem, because I am
unlikely to lock a file that I am not about to start making changes to.
If I do have an unmodified file locked, then that presumably was either
quite deliberate (and I'll want any unlocking to be explicitly at my
request), or I've forgotten about it. Before I check stuff in, I nearly
*always* run SVN ST to see what changes I have pending. If that tells me
about locked-but-unmodified files, I will be aware of them and can take
appropriate action.
Looking a a SourceSafe-oriented IDE for a moment (Visual FoxPro), I have
these actions available to me:
(Note all files start off read-only)
* Get latest version (SVN UP)
* Check out (SVN LOCK + remove readonly attribute from file attrib -r
or chmod depending on your PoV)
* Check in, the dialog that is shown contains
- a list of currently "checked-out" files, with a checkbox next to
each. Whether only one file or all files are selected depends on how the
dialog was invoked.
- a button "SELECT ALL"
- a checkbox [ ] Keep checked out.
* Undo check out (SVN REVERT + SVN UNLOCK)
(Remember here of course that in SourceSafe, check out and locking are
always synonymous. Well, unless you subvert it (pun not important) and
remove the readonly attribute manually.)
My point here is that on 'check-in' I have the option of keeping locked
or unlocking, with neither being favoured, and I use both. The semantics
of a dialog like this aren't exactly like SVN CI, but it is the same
step in my workflow.
And I would agree on the case that REVERT should behave the same as
COMMIT, ie not unlock anything. Maybe REVERT --AND-UNLOCK. Again,
looking at the use cases for revert, I have three:
* I started making changes to the file but decided I made a mess of it
and need to start over. In this case I want to keep any lock.
* I started making changes to the file, but decided I shoudn't have and
need to back out and stop. In this case I want to release any lock.
* I'm merging another branch into trunk (actually whatever my WC is
tracking), and I don't want to bring in any automatic changes to that
file. In this case (assuming I have a lock), whether I want to keep the
lock or not depends on whether I am planning to make a manual change to
that file or not. I think it is safer if I keep the lock.
Sooo.. to try and cut a long tale short, I'd vote for the following
behaviour.
SVN CO and SVN UP do not change any locks
SVN CI/COMMIT does not change any locks
SVN CU (or SVN FINISHWITH or...) commits and unlocks any changes, but
does not lock any unchanged files
SVN CU --AND-ALL-THE-REST <g> commits any changes and unlocks all files
whether changed or not.
SVN REVERT does not change any locks. And doesn't complain if you have
any either.
SVN UNLOCK complains if you have uncommitted changes and will not unlock
SVN UNLOCK --FORCE will unlock even if you have uncommitted changes
and for good measure, it is probably consistent if..
SVN LOCK check that I have the latest version of the file, and if I
don't, should refuse to lock it
SVN LOCK --FORCE should lock whether I have the latest or not
I'm sort of ambivalent on...
* SVN UPDATE should fall over if I have a file locked and someone else
has changed since.
* New command to lock-and-update in one step. SVN EDIT? (like Perforce
P4 EDIT or SS CHECKOUT). I think this would be very useful and not as
an appendage to LOCK.
Plus - config settings, preferably PER WORKING COPY to default some of
the switches. If anything can be set by configuration file, then of
course it must also be possibly to override with a command-line switch.
I personally don't use REVERT often enough to feel strongly about having
a REVERT-AND-UNLOCK command, or even a switch to do the same. There's
not harm in having to revert and then separately unlock.
And after saying all that, whatever you guys come up with will probably
make enough sense that I won't really mind one way or another.
- Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 19 11:13:34 2004