On May 22, 2008, at 5:21 PM, Timothy Stone wrote:
I'm not sure, if I was BB, that I would even consider this...
reason: the setup described above, and in the original post, is
"not ideal at all," but not at all what CVS or SVN, or PVCS, or /
insert SCM here/ expects. Nor, is it any documented, or recommended
project management pattern.
To Matthias, I would ask, "Why are you being constrained to one
directory?" What is preventing you from have a "work" directory,
under which there is a "svn/project_name" and "cvs/project_name"
directory? It is an automated build process? What sort of project
would want you to use two different SCM repositories.
This is something I do on a daily basis, and if there is something
that I can assist with, I only need to know more about what you are
doing to provide some direction.
The usage pattern for this is the private versioning pattern (ref
http://www.scmpatterns.com/book/pattern-summary.html) in which you
essentially version all of your local "off-code-line" work
independently from the source codeline. This sounds like what
Matthias is looking to implement. It allows, essentially micro-
versioning of your work in progress with a local repository that.
Other approaches for this involve creating honest-to-god branches in
the host source control system and submitting all your changes there,
but multiple branches can be even more problematic from a keeping-up-
to-date-with-the-donor-branch than the orthogonal version control
approach, especially if your systems maintain limited branch/merge
history.
git is strangely popular for this pattern, because of the way it
handles metadata and because basically this is how it is views the
world. Perforce's free 2-user/5-workspace can also be used here. It
also handles metadata without scattering a bunch of directories
through your source tree. (insert ob comment about remembering to
override p4's pathological desire to lock down the whole damn source
tree here.)
Overall, the best solution is a codeline policy that allows frequent
submits of changes, but in some cases moving to such a policy may be
unwise or politically challenging. Having an offline scm system aids
in that effort.
However, as an SCM manager, I would not support a plurality of
offline systems - unless we were also, to some degree documenting
preferred deployment and usage - and I can understand where BBEdit
would make assumptions about the number of version control systems
asserting some claim over the history of a given file.
-Charles Albrecht
[EMAIL PROTECTED]
--
------------------------------------------------------------------
Have a feature request? Not sure the software's working correctly?
If so, please send mail to <[EMAIL PROTECTED]>, not to the list.
List FAQ: <http://www.barebones.com/support/lists/bbedit_talk.shtml>
List archives: <http://www.listsearch.com/BBEditTalk.lasso>
To unsubscribe, send mail to: <[EMAIL PROTECTED]>
