You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Anna Kelbert <an...@coas.oregonstate.edu> on 2008/05/02 23:54:58 UTC
svn:use-local feature request?
Hi everyone,
I've often encountered the following situation with SVN. A few
developers work simultaneously on some source code. Then there is often
a bunch of files which each developer changes according to his/her
individual taste and preferences, or temporary needs. These might
include program configurations or a makefile. They are often part of the
source code, and it makes sense to keep a version of these files in the
SVN repository. However, each individual developer would like to keep
his/her version of these files.
A simple example: developer A uses Intel compiler and developer B uses
GNU. They both checkout a makefile from the repository and change the
compiler name in the makefile. They then want to commit their code
modifications, but both wish to keep their own versions of the makefile.
Obviously, one could remember to revert such local modifications before
committing, but that would require a workaround unless you are willing
to lose your local changes over and over again. Besides, this procedure
is prone to human error.
This is such a common issue, that I figured I'd ask you about it first,
and perhaps submit a feature request. Something like an svn:use-local
property would do the trick. One could set the property on a file in
order to modify it and keep the local version without committing it to
the repository. One would then delete the property if any changes to
that file finally need to be committed.
What do you think? Thanks for any feedback!
Anya
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:use-local feature request?
Posted by John Peacock <jo...@havurah-software.org>.
Anna Kelbert wrote:
> developers work simultaneously on some source code. Then there is often
> a bunch of files which each developer changes according to his/her
> individual taste and preferences, or temporary needs.
There isn't any way to completely ignore local changes, but this method works well:
http://subversion.tigris.org/faq.html#ignore-commit
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:use-local feature request?
Posted by Christian Unger <ch...@mac.com>.
why not svn:ignore the makefiles?
cu
christian unger
On 03.05.2008, at 01:54, Anna Kelbert wrote:
> Hi everyone,
>
> I've often encountered the following situation with SVN. A few
> developers work simultaneously on some source code. Then there is
> often a bunch of files which each developer changes according to his/
> her individual taste and preferences, or temporary needs. These
> might include program configurations or a makefile. They are often
> part of the source code, and it makes sense to keep a version of
> these files in the SVN repository. However, each individual
> developer would like to keep his/her version of these files.
>
> A simple example: developer A uses Intel compiler and developer B
> uses GNU. They both checkout a makefile from the repository and
> change the compiler name in the makefile. They then want to commit
> their code modifications, but both wish to keep their own versions
> of the makefile.
>
> Obviously, one could remember to revert such local modifications
> before committing, but that would require a workaround unless you
> are willing to lose your local changes over and over again. Besides,
> this procedure is prone to human error.
>
> This is such a common issue, that I figured I'd ask you about it
> first, and perhaps submit a feature request. Something like an
> svn:use-local property would do the trick. One could set the
> property on a file in order to modify it and keep the local version
> without committing it to the repository. One would then delete the
> property if any changes to that file finally need to be committed.
>
> What do you think? Thanks for any feedback!
>
> Anya
>
> ---------------------------------------------------------------------
> 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
Re: svn:use-local feature request?
Posted by Karl Fogel <kf...@red-bean.com>.
Frank Gruman <fg...@verizon.net> writes:
> I will admit - I wish there was a way to set a global ignore list
> (from the server) to set this property and then certain users could
> remove the property if they need to make changes rather than trying to
> make sure that every developer sets up the properties the right way
> when we get new developers / new machines.
http://subversion.tigris.org/issues/show_bug.cgi?id=1974
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn:use-local feature request?
Posted by Frank Gruman <fg...@verizon.net>.
The way that we implement the feature you are asking for is to use the
svn:ignore property in each developer's working copy. This enables a
user to actually check a copy of that file back in if necessary global
changes are made, but still allow individual developers to ignore that
file when performing update / commit operations.
I will admit - I wish there was a way to set a global ignore list (from
the server) to set this property and then certain users could remove the
property if they need to make changes rather than trying to make sure
that every developer sets up the properties the right way when we get
new developers / new machines.
Hope that helps.
Regards,
Frank
On Fri, 2008-05-02 at 16:54 -0700, Anna Kelbert wrote:
> Hi everyone,
>
> I've often encountered the following situation with SVN. A few
> developers work simultaneously on some source code. Then there is often
> a bunch of files which each developer changes according to his/her
> individual taste and preferences, or temporary needs. These might
> include program configurations or a makefile. They are often part of the
> source code, and it makes sense to keep a version of these files in the
> SVN repository. However, each individual developer would like to keep
> his/her version of these files.
>
> A simple example: developer A uses Intel compiler and developer B uses
> GNU. They both checkout a makefile from the repository and change the
> compiler name in the makefile. They then want to commit their code
> modifications, but both wish to keep their own versions of the makefile.
>
> Obviously, one could remember to revert such local modifications before
> committing, but that would require a workaround unless you are willing
> to lose your local changes over and over again. Besides, this procedure
> is prone to human error.
>
> This is such a common issue, that I figured I'd ask you about it first,
> and perhaps submit a feature request. Something like an svn:use-local
> property would do the trick. One could set the property on a file in
> order to modify it and keep the local version without committing it to
> the repository. One would then delete the property if any changes to
> that file finally need to be committed.
>
> What do you think? Thanks for any feedback!
>
> Anya
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Re: svn:use-local feature request?
Posted by da...@jpmorgan.com.
Hi Anya,
Looking at your specific example:-
> A simple example: developer A uses Intel compiler and developer B uses
> GNU. They both checkout a makefile from the repository and change the
> compiler name in the makefile. They then want to commit their code
> modifications, but both wish to keep their own versions of the makefile.
A released product is made up of components which are built using specific
tools ... if you change the compiler you may introduce defects to your
code which are due to the binaries produced by defects in the compiler.
I've actually experienced this one in a previous role where as a sysadmin
we (unthinkingly) patched the central copy of the compiler in order to fix
an issue one team was having ... this however broke the build of one of
another team who were unknowlingly relying on the defect for their code to
work.
As an SCM best practice the version of the tools used to build your
released product should be tracked alongside your source code (IMHO).
Consequently your statement concerning developers wanting to be able to
modify (as an example) makefiles so that they can change the compiler ...
this is exactly the kind of situation you'd want to track in an SCM
system.
YMMV,
Dg.
--
David Grierson
JPMorgan - IB Architecture - Source Code Management Consultant
GDP 228-5574 / DDI +44 141 228 5574 / Email david.x.grierson@jpmorgan.com
Alhambra House 6th floor, 45 Waterloo Street, Glasgow G2 6HS
Generally, this communication is for informational purposes only
and it is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation
of any transaction. In the event you are receiving the offering
materials attached below related to your interest in hedge funds or
private equity, this communication may be intended as an offer or
solicitation for the purchase or sale of such fund(s). All market
prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice.
Any comments or statements made herein do not necessarily reflect
those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org