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.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 4 16:21:58 2005