Well, first off you should investigate branches. There are many
different workflows, but most of them involve use of branches and
merges in one way or another. For example, in your case you might
consider having a distinct "build" branch. The build master can then
merge in changes to that branch from the development branch using
some well-defined criteria.
Regarding overlapping changes, the svn "way" is to resolve these
overlaps late; that is the purpose of conflict checks at commit time.
Basically the philosophy is to allow the overlapping edits, and let
Subversion catch them when the second overlapping checkin occurs (it
spots this automatically). The conflict resolution process can then
be used to reconcile the two sets of changes.
--Tim
On Jan 4, 2007, at 7:24 PM, dgotard wrote:
>
> My company is considering migration from Visual Source Safe to
> Subversion.
> Presently, the development team leverages the lock-on-checkout
> feature of
> VSS to identify files which are currently being worked on (a report
> is run
> to identify files which are marked with a lock, and are therefore
> checked
> out for editing). The use cases are:
>
> 1. The build master wants to know what files within a
> specific branch
> (or project) are currently being edited before starting the build.
> 2. A developer is about to start working on a file, he/she
> wants to
> know if anyone else is currently editing that same file so that
> they can
> discuss any overlapping changes.
>
> Can someone suggest a Subversion mechanism which would satisfy
> these uses
> cases (without having to resort to locking every file before editing)?
>
> Any comments on the "best practices" of these use cases. Can these be
> situations be addressed through a change in how the team approaches
> it's
> development.
>
> Your comments or thoughts would be greatly appreciated.
>
> -David
> --
> View this message in context: http://www.nabble.com/Identifying-
> Modified-Files-tf2923692.html#a8172384
> Sent from the Subversion Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 5 08:00:39 2007