Ah...I see. I am not new to version control, but new to Subversion and the
paradigms in use here.
In (the dreaded) Microsoft Visual Source Safe (from whence I came) things
work as follows:
"Generally, only one user can have a file checked out for modification at
one time. However, if your VSS administrator allows multiple check outs,
many users can check out the same file at the same time. When the first user
checks the file into VSS, that file becomes the current version. When
subsequent users check in their local copies, their changes are merged into
the file and a new VSS version is created. Binary format files cannot be
checked out by more than one person at a time.
You can also check items out exclusively that is, check them out so that no
one else can check them out while you have the file or project checked out.
Your VSS administrator can set an administrative option to disable multiple
check outs for an entire project all the time, or you can [...] exclusively
check the file out on a file-by-file and session-by-session basis."
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.
Benefit 1 would be userful for binaries and other situations where merging
will be a problem.
Benefit 2 would be an important addition to Subversion. The scenario has
come up at my workplace were I am considering changing a group of files and
I would like to know if anyone else has these files "in progress" with major
changes that might be so incompatible as to be unmergeable with the major
changes I also have planned. If so, I may want to hold off until they have
committed their changes before getting my working copy or branching.
Subversion doesn't currently tell me anything that will help me in this
situation, but if it could tell me, e.g.:
:: svn workingcopies <folder or file path>
Working Copies for <folder or file path>:
User Email Date/Time Aquired Commit Rate Byte Commit
Rate
THY thy@company1.com 01-29-2005 10:32:57 AM 1.31/day 4,506
KB/day
NIS nis@company2.com 02-01-2005 1:05:04 PM 5.38/day 215.34
MB/day
By this information, I know that the folder or file I am interested in is
under heavy use by NIS at nis@company2.com. I could send him an email
asking him for a patch or otherwise discuss strategy with him before
attempting to make my significant changes.
Benefit 3 would would be a nice way to further distinguish a tag (frozen
because no working copies are allowed) from a branch (potentially under
active develeopment, depending on if there are any users with current
working copies).
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?
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.
My feeling is that branching is incredibly easy and merging *successfully*
and *efficiently* is significantly difficult in Subversion. This makes
branching only about half as useful. If "exclusive or limited use working
copies" can help this situation, makes such a solution much more appealling
to me.
Thoughts? Criticisms?
> From: Glenn McAllister [mailto:gmcallister@sapient.com]
>
> The issue is around merging binary documents. There are
> algorithms that can do a (mostly) logical merge of multiple
> versions of a text file that produces something legible. Try
> that with a binary file (a graphic is the de-facto example)
> and usually the result is completely useless.
[snip]
> From: Keith Wellman [mailto:keith@Bladelogic.com]
>
> Yes, it's clear that binary merge is too context dependent to
> generalize, and it appears that subversion wisely punts on
> the issue and simply provides the files that any merge
> program would want (e.g., merge-left merge-right working).
> Leave it to some 3rd party to support merging.
>
> I'm new to subversion, but in practice I expect when dealing
> with binary items such as images or 3rd party binary
> libraries - there is no sensical interpretation of a merge.
> You want one or the other and it's easy to grab the right one
> and slam it into place. Svn deals with this situation in
> fine fashion.
>
> The problem arises when you have 'binaries' such as
> Framemaker binary files that can very reasonably be logically
> merged, but the nature of the binary markup makes it
> difficult to do (or too niche to bother doing). So unless
> Adobe provides a whiz-bang cool merge tool for Framemaker
> documents (which I don't believe they do) AND my tech writers
> feel comfortable using it (which they wouldn't) - they are
> left in fear of parallel changes to any document. This leads
> to their reliance on a locking / serial model for version control.
>
> So unless I'm missing something key to this issue, it looks
> like subversion really isn't the place for them until it can
> support an exclusive locking model.
>
> From what I can gather on the mail lists - this is in
> development now. Time for me to check the roadmap.
>
> If anyone has any further thoughts on the issue, I'd love to
> hear them.
>
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 3 22:02:14 2005