> From: Ryan Schmidt [mailto:subversion-2004@ryandesign.com]
>
> On 03.02.2005, at 20:43, Nick Seigal wrote:
>
> > We of course don't use the check-out-check-in model, but I wonder if
> > the
> > Subversion community would except the idea of an "exclusive working
> > copy" or
> > a "limited use working copy"? By setting and keeping track of the
> > number of
> > working copies allowed on any file or folder, we could have two
> > benefits:
> >
> > (1) Files and folders could be defined to only allow one
> working copy
> > at a
> > time, effectively "locking" them.
> > (2) Users could get information not only of how many
> working copies
> > (one,
> > n-number, infinite, none) were permitted on any file, but
> also how many
> > working folders were extant and for whom were they created (which
> > users).
> > (3) Files and folders could be "locked down" by setting
> the number of
> > working copies to zero.
>
> [snip]
>
> > Am I right to think this is not currently a part of
> Subversion in any
> > form?
> > Do others agree that this sort of info would be useful? Am
> I thinking
> > of
> > using Subversion correctly or is there a paradigm shift I
> need to make
> > that
> > makes this a non-issue?
>
> The problem will be that Subversion allows Joe User to check out as
> many working copies as he wants. Maybe he's just checking it out to
> have a look at the code, and doesn't intend to change anything, and
> will throw the working copy away when he's done looking. To make it
> work the way you want, Joe would now need a mechanism to tell
> Subversion that the copy he checked out can be scratched off
> the list.
> Also, supposing Joe does make changes and commits them, nothing
> prevents Joe from then making more modifications to the same working
> copy and committing them. So, "checking in" often doesn't mean "I'm
> done with this forever." In Subversion, it's usual for all active
> developers of a project to have at minimum one working copy of the
> entire project (or, at least, the part of the project they're working
> on) at all times, because it takes awhile to do a complete checkout,
> but updating an existing working copy is typically much faster. Bill
> Programmer might have two working copies -- one for fixing bug 37 and
> another for implementing feature 82.
>
> I was going to initially suggest that you could implement
> your desired
> working model with a combination of hook scripts and a
> private working
> copy tracking database, but after writing the preceding paragraph, I
> think you'll probably need a completely separate system, whereby
> developers access a separate database of some sort and make a note
> there that they want to start working on a project. Then they use the
> Subversion commands to either check out a working copy or
> update their
> existing working copy, make changes, commit, make changes, commit,
> etc., etc., and finally access the separate database again
> and indicate
> that they're done working. So, in the end, I think it's a lot of
> trouble, and doesn't fit with the way Subversion is designed.
The Subversion enhancement I described would do the same thing more-or-less
as the database you described. I am aware that the users usually have
working copies and that committing them is *not* the same as saying "I'm
done with this". My idea was to give activity statistics so that there was
a sense of how heavily each user was "using" their working copy of a
particular file. If the use of the same file is heavy for more than one
user, then merging may be difficult. In that case, the users should get
together and talk about compatibility of changes and timing of merges. When
we used VSS in a multiple-checkout environment, we made heavy use of the
information describing who had what checked out. It would have been nice to
know what they were changing or how much, but there was not metadata to help
with that. We just had to talk it over.
Using Subversion, we use a strategy currently to protect the trunk (or
current version branch) where all merges occur between user-specific feature
branches or from the trunk to the feature branch before coming back to the
trunk. Only one developer is usually entrusted with the maintenance of the
trunk and he will only merge files in that are demonstrated to be stable.
This helps reduce the chance of regression of the trunk, but it would be
nice to have more info.
> > What do all those web developers that have been using Subversion for
> > years
> > do about the issue of not being able to safely auto-merge
> most kinds of
> > files, e.g. images for websites are binaries and have this basic
> > merging
> > issue.
>
> I don't believe this is a problem for things like web site images. I
> think there is only a conflict if two developers attempt to edit the
> binary files at the same time -- Bill decides to make the icon more
> green at the same time that Jane makes it more blue. And that should
> occur pretty much never -- changes to images would occur
> because of new
> features, or bug fixes, and tasks like creating or modifying graphics
> are probably going to be assigned to exactly one person at a
> time -- so
> I expect there to be no problems with our use of Subversion.
> Indeed, I
> would assert that "most kinds of files" used in web site development
> are text files, so there's no problem there either.
>
> Images, being rather bite-sized, probably work well with Subversion
> since only one person probably changes them at any given time. Huge
> Word documents that everybody edits all the time when writing a
> complicated manual probably work much less well. Probably the manual
> would have to be divided into separate files, one for each
> chapter, or
> even divided more severely, to limit the chance that people edit the
> same file at the same time. Or a text-file-based format would need to
> be used to edit the source text, only compiling it into Word
> or PDF or
> whatever format via an automated process at a later time.
You assume that there is only one graphic designer or only one working on
each image file at a time. Perhaps this is true in practice, but a
situation in which it is not true is not that hard to imagine. I was hoping
that either Subversion has a way of handling this or there is a "best
practice" that folks use to prevent this. For example:
(1) "only one graphic designer working on each image file at a time". To
make this rule easy to follow, we need a feature like I described to see if
others are heavily working on the file. Oh, and that brings up two other
key policies: (2) "make all changes in a user-specific feature branch" and
(3) "commit changes to all files in your feature branch as frequently as
possible". These will insure that the activity statistics are useful.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 5 20:51:36 2005