Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Matt Welland
Just a general comment on this proposal

To reiterate the solution provided by Mike, I think this problem can be
easily solved by user methodology with no changes to fossil. If you have
generated or user edited files create and check in templates. Add the
appropriate targets to your make file to copy (and possibly modify) the
template to the needed file if it does not exist.

These "special" case files are going to be one more thing a new user has to
learn and deal with and the ROI is very low. It will be hard to "see" the
different status between a normally controlled file and the special file.

An alternative would be to consider the git model where you have to mark
files for commit. It is a general solution that does address this need.

On Mon, Jul 2, 2012 at 6:55 AM, Stephan Beal  wrote:

> On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer  wrote:
>
>> My solution has been to push things out to the build system. What gets
>> stored in the repo is config.template. In this, the "values" for
>>
>
> Another option might, depending on the system, be to "include" a local
> config file/make file/whatever. e.g. in Make it might look like:
>
> -include Makefile.$(USER)
>
> the "-" before include means "don't fail if the file does not exist," and
> most devs have the same $(USER) on their dev machine(s).  (And if they
> don't, a symlink can work as a crutch to link multiple names to one
> makefile.) For small teams, Makefile.$(USER) might even be checked in.
>
> The Ant build system allows one to include custom property files, so you
> could add local.config to your imports and you're all set. Developers which
> don't need it simply need to create a 0-byte copy locally.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer  wrote:

> My solution has been to push things out to the build system. What gets
> stored in the repo is config.template. In this, the "values" for
>

Another option might, depending on the system, be to "include" a local
config file/make file/whatever. e.g. in Make it might look like:

-include Makefile.$(USER)

the "-" before include means "don't fail if the file does not exist," and
most devs have the same $(USER) on their dev machine(s).  (And if they
don't, a symlink can work as a crutch to link multiple names to one
makefile.) For small teams, Makefile.$(USER) might even be checked in.

The Ant build system allows one to include custom property files, so you
could add local.config to your imports and you're all set. Developers which
don't need it simply need to create a 0-byte copy locally.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Mike Meyer
On Mon, 2 Jul 2012 08:08:18 -0400
Richard Hipp  wrote:

> I am willing to *consider* some option that says "do not commit these
> files, even if they change, unless that are specifically named on the
> command-line".  I think this would be easy to implement by messing
> with the is_selected()/if_selected()
> function .

My issue with this solution is that this doesn't really solve the
problem as I've encountered it. That is, a config file that needs
local changes to run/build, but with a base version in the repo that
needs evolves along with the project.

My solution has been to push things out to the build system. What gets
stored in the repo is config.template. In this, the "values" for
everything document what they are used for. The end user (or a command
run by them, depending) creates "config" from that, filling in the
values as appropriate. The build (or launch, depending) system breaks
if the local version doesn't exist, and issues a warning if the
template is newer than the local copy (when it gets updated).

A SCM system could do that, with a private branch of the config file
for everyone who is building (running) the project, but that seems
like overkill.

  http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Jacek Cała
If it happens I have some spare time, I'll look on the
{is/if}_selected and will report on any progress.

  Cheers,
  Jacek


2012/7/2 Stephan Beal :
> On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała  wrote:
>>
>> Is there any difference except from being in the repo. I'd say,
>> "truly" ignored files are not in the repo at all, while "partially"
>> ignored happen to be although the scm just ignores their local
>> counterparts. Am I missing something?
>
>
> That's my point: fossil has to completely ignore one set and only deal with
> the other set in certain cases. In order to that, it has to be able to
> differentiate between the two sets of files. It can't do that if they're all
> in the ignore-glob (which has very specific semantics which users rely
> upon).
>
> In any case, Richard indicated that it "shouldn't be too hard to implement"
> using existing functionality. i can't personally commit to implementing it
> in the near future, but it's something i'd like to see at least
> experimentally implemented. In hindsight, i can't believe this feature
> suggestion has never come up before :/.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała  wrote:

> Is there any difference except from being in the repo. I'd say,
> "truly" ignored files are not in the repo at all, while "partially"
> ignored happen to be although the scm just ignores their local
> counterparts. Am I missing something?
>

That's my point: fossil has to completely ignore one set and only deal with
the other set in certain cases. In order to that, it has to be able to
differentiate between the two sets of files. It can't do that if they're
all in the ignore-glob (which has very specific semantics which users rely
upon).

In any case, Richard indicated that it "shouldn't be too hard to implement"
using existing functionality. i can't personally commit to implementing it
in the near future, but it's something i'd like to see at least
experimentally implemented. In hindsight, i can't believe this feature
suggestion has never come up before :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Martin Gagnon
On Mon, Jul 2, 2012 at 5:24 AM, Jacek Cała  wrote:

>   Hi All,
>
> I've got in my repo a small number of files that are changing but
> these changes are not meant to be send to the repo (are kind of
> user-specific). The files are needed in the repo but only in their
> initial or some specific version. Is there any way to turn off change
> tracking for some files? To be clearer, when doing 'fossil open
> myrepo' I'd like these files to appear in the filesystem but when
> doing 'fossil chan' I'd like them to not appear, maybe only when
> MISSING.
>
> I would expect this to work similar to 'fossil settings ignore-glob'
> w.r.t. 'fossil extra'.
>
>
>
This would be very useful for those IDE that modify a timestamp string in
the project file every time the project is open even without any
modifications..

Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Jacek Cała
2012/7/2 Stephan Beal :
> On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała  wrote:
>>
>> Couldn't it just be that when a file (a set of files '*.whatever') is
>> in the ignore-glob it behaves exactly like Richard suggested. From a
>> user perspective that would be simpler -- just one list which means
>> ignore yet not prevent from being added.
>
>
> How could the ignore code differentiate between truly ignored files and
> those which are "partially ignored"?

Is there any difference except from being in the repo. I'd say,
"truly" ignored files are not in the repo at all, while "partially"
ignored happen to be although the scm just ignores their local
counterparts. Am I missing something?

  Jacek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała  wrote:

> One more thought. Perhaps, there's no need for a separate ignore list
> but just a bit different semantics of the existing 'ignore-glob'.
>

In my experience, changing/extending semantics means lots of new room for
special cases and backwards compatibility problems. :/.


> Couldn't it just be that when a file (a set of files '*.whatever') is
> in the ignore-glob it behaves exactly like Richard suggested. From a
> user perspective that would be simpler -- just one list which means
> ignore yet not prevent from being added.
>

How could the ignore code differentiate between truly ignored files and
those which are "partially ignored"?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Jacek Cała
One more thought. Perhaps, there's no need for a separate ignore list
but just a bit different semantics of the existing 'ignore-glob'.
Couldn't it just be that when a file (a set of files '*.whatever') is
in the ignore-glob it behaves exactly like Richard suggested. From a
user perspective that would be simpler -- just one list which means
ignore yet not prevent from being added.

  Cheers,
  Jacek

2012/7/2 Richard Hipp :
>
>
> On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal  wrote:
>>
>> On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal 
>> wrote:
>>>
>>> i'm not personally convinced that an ignore list would completely solve
>>> the problem (i think that just might lead to more confusion ("i changed the
>>> file, why isn't it showing as changed?") and corresponding bug reports). But
>>> it might be a solution or part of a solution. Can you elaborate on how you
>>> imagine such a feature behaving?
>>
>>
>> Maybe we could have a local list, similar to ignore-glob, like:
>>
>> fossil forget-local ...list...of...files...
>> fossil remember-local ...list...of...files... (undoes the forget)
>>
>> "Forgotten" files would be excluded from commits unless they are
>> explicitly named on the command-line (as opposed to being in a directory
>> which was passed on the comment line). Fossil status "should probably" show
>> them as changed, in any case.
>>
>> But what happens if the remote is updated? Do those files participate in
>> merging (i suspect they should)? Are there other corner cases here?
>
>
> I am willing to *consider* some option that says "do not commit these files,
> even if they change, unless that are specifically named on the
> command-line".  I think this would be easy to implement by messing with the
> is_selected()/if_selected() function.
>
> So, to use Stephan's example, if you marked Makefile as no-autocommit, and
> there were changes to both Makefile and to file1.txt, "fossil commit" would
> only check-in the changes on file1.txt.  But "fossil commit Makefile *.txt"
> would check-in changes to both file.  Probably there should be another
> command-line option such as "fossil commit --all" that also picks up
> Makefile.  The "changes" command should show the changes to Makefile, but
> indicate that they are not checked in by default.  The check-in comment
> prompt string should indicate clearly that Makefile is omitted from the
> check-in because of the setting and it was not specified on the
> command-line.
>
> I don't think any changes are needed to update or merge or stash.  "fossil
> revert" is an interesting case - does it revert Makefile to the default, or
> doesn't it?  Maybe "fossil revert Makefile" or "fossil revert --all" is
> required?
>
> Correction:  I think "fossil changes" should only show Makefile if you give
> it an option like "--all".  Otherwise, "fossil all changes" (whose purpose
> it to show check-outs with any changes that you have forgotten to check-in)
> would give false hits for repos with only "Makefile-like" changes.
>
>
>>
>>
>> --
>> - stephan beal
>> http://wanderinghorse.net/home/stephan/
>> http://gplus.to/sgbeal
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Jacek Cała
2012/7/2 Stephan Beal :
> On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała  wrote:
>>
>> would be enough. However, I can imagine that someone has a large repo
>> and needs to set no-autocommit to more than 10 files. Then maintaining
>> an 'ignore-glob'-like list may become a pain.
>
>
> fossil/sqlite has routines for globbing, so it wouldn't be too painful to do
> things like:
>
> fossil remember-local 'foo.*'

Fine for me!

  Jacek
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała  wrote:

> would be enough. However, I can imagine that someone has a large repo
> and needs to set no-autocommit to more than 10 files. Then maintaining
> an 'ignore-glob'-like list may become a pain.
>

fossil/sqlite has routines for globbing, so it wouldn't be too painful to
do things like:

fossil remember-local 'foo.*'

(quoting the wildcard so that sqlite gets it instead of having the shell
expand it)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Jacek Cała
This is exactly how I would expect it to work. And I like the '--all'
option, too.

The only thing is if anything better than a list like 'ignore-glob'
can be proposed. In my case it's just a few files, so such a list
would be enough. However, I can imagine that someone has a large repo
and needs to set no-autocommit to more than 10 files. Then maintaining
an 'ignore-glob'-like list may become a pain.

  Cheers,
  Jacek

2012/7/2 Richard Hipp :
> I am willing to *consider* some option that says "do not commit these files,
> even if they change, unless that are specifically named on the
> command-line".  I think this would be easy to implement by messing with the
> is_selected()/if_selected() function.
>
> So, to use Stephan's example, if you marked Makefile as no-autocommit, and
> there were changes to both Makefile and to file1.txt, "fossil commit" would
> only check-in the changes on file1.txt.  But "fossil commit Makefile *.txt"
> would check-in changes to both file.  Probably there should be another
> command-line option such as "fossil commit --all" that also picks up
> Makefile.  The "changes" command should show the changes to Makefile, but
> indicate that they are not checked in by default.  The check-in comment
> prompt string should indicate clearly that Makefile is omitted from the
> check-in because of the setting and it was not specified on the
> command-line.
>
> I don't think any changes are needed to update or merge or stash.  "fossil
> revert" is an interesting case - does it revert Makefile to the default, or
> doesn't it?  Maybe "fossil revert Makefile" or "fossil revert --all" is
> required?
>
> Correction:  I think "fossil changes" should only show Makefile if you give
> it an option like "--all".  Otherwise, "fossil all changes" (whose purpose
> it to show check-outs with any changes that you have forgotten to check-in)
> would give false hits for repos with only "Makefile-like" changes.
>
>
>>
>>
>> --
>> - stephan beal
>> http://wanderinghorse.net/home/stephan/
>> http://gplus.to/sgbeal
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Richard Hipp
On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal  wrote:

> On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal wrote:
>
>> i'm not personally convinced that an ignore list would completely solve
>> the problem (i think that just might lead to more confusion ("i changed the
>> file, why isn't it showing as changed?") and corresponding bug reports).
>> But it might be a solution or part of a solution. Can you elaborate on how
>> you imagine such a feature behaving?
>>
>
> Maybe we could have a local list, similar to ignore-glob, like:
>
> fossil forget-local ...list...of...files...
> fossil remember-local ...list...of...files... (undoes the forget)
>
> "Forgotten" files would be excluded from commits unless they are
> explicitly named on the command-line (as opposed to being in a directory
> which was passed on the comment line). Fossil status "should probably" show
> them as changed, in any case.
>
> But what happens if the remote is updated? Do those files participate in
> merging (i suspect they should)? Are there other corner cases here?
>

I am willing to *consider* some option that says "do not commit these
files, even if they change, unless that are specifically named on the
command-line".  I think this would be easy to implement by messing
with the is_selected()/if_selected()
function .

So, to use Stephan's example, if you marked Makefile as no-autocommit, and
there were changes to both Makefile and to file1.txt, "fossil commit" would
only check-in the changes on file1.txt.  But "fossil commit Makefile *.txt"
would check-in changes to both file.  Probably there should be another
command-line option such as "fossil commit --all" that also picks up
Makefile.  The "changes" command should show the changes to Makefile, but
indicate that they are not checked in by default.  The check-in comment
prompt string should indicate clearly that Makefile is omitted from the
check-in because of the setting and it was not specified on the
command-line.

I don't think any changes are needed to update or merge or stash.  "fossil
revert" is an interesting case - does it revert Makefile to the default, or
doesn't it?  Maybe "fossil revert Makefile" or "fossil revert --all" is
required?

Correction:  I think "fossil changes" should only show Makefile if you give
it an option like "--all".  Otherwise, "fossil all changes" (whose purpose
it to show check-outs with any changes that you have forgotten to check-in)
would give false hits for repos with only "Makefile-like" changes.



>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal  wrote:

> i'm not personally convinced that an ignore list would completely solve
> the problem (i think that just might lead to more confusion ("i changed the
> file, why isn't it showing as changed?") and corresponding bug reports).
> But it might be a solution or part of a solution. Can you elaborate on how
> you imagine such a feature behaving?
>

Maybe we could have a local list, similar to ignore-glob, like:

fossil forget-local ...list...of...files...
fossil remember-local ...list...of...files... (undoes the forget)

"Forgotten" files would be excluded from commits unless they are explicitly
named on the command-line (as opposed to being in a directory which was
passed on the comment line). Fossil status "should probably" show them as
changed, in any case.

But what happens if the remote is updated? Do those files participate in
merging (i suspect they should)? Are there other corner cases here?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
On Mon, Jul 2, 2012 at 1:19 PM, Jacek Cała  wrote:

> The thing is that either I'll commit these file every time they change
> (which makes a bit of mess in the repo) or I need to do a selective
> commit which omits these files (which after a tens of commits become a
> bit annoying).
>

Coincidentally, i had just the same problem all last weekend, where i
didn't want to commit my makefile changes to the main repo (owned by
someone else). Before every commit i had to remove my Makefile symlink and
revert the old copy to ensure that i didn't hose the original, and
afterwards had to delete the in-tree copy and symlink it over to my
makefile. Annoying, yes, and i eventually worked around it by restructuring
the build to allow for a developer-local makefile to set up the local build
configuration before including the master makefile.

So the problem is there, yes, but i don't see how an SCM can help with that
particular case. It sees the original versions and considers any file with
a name it knows about to be under SCM control. i think that's a fair
assumption (and there's not an SCM out there which does not do this).

i'm not personally convinced that an ignore list would completely solve the
problem (i think that just might lead to more confusion ("i changed the
file, why isn't it showing as changed?") and corresponding bug reports).
But it might be a solution or part of a solution. Can you elaborate on how
you imagine such a feature behaving?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Jacek Cała
Hi Stephan,

I think it is an scm-level problem, at least for me ;-)

The thing is that either I'll commit these file every time they change
(which makes a bit of mess in the repo) or I need to do a selective
commit which omits these files (which after a tens of commits become a
bit annoying).

  Cheers,
  Jacek

2012/7/2 Stephan Beal :
> Hi! No, there us no such mechanism in fossil. I sometimes have similar
> problems with makefiles and config files, but i have never considered that
> to be an scm-level problem (maybe it is?).
>
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
> On Jul 2, 2012 11:24 AM, "Jacek Cała"  wrote:
>>
>>   Hi All,
>>
>> I've got in my repo a small number of files that are changing but
>> these changes are not meant to be send to the repo (are kind of
>> user-specific). The files are needed in the repo but only in their
>> initial or some specific version. Is there any way to turn off change
>> tracking for some files? To be clearer, when doing 'fossil open
>> myrepo' I'd like these files to appear in the filesystem but when
>> doing 'fossil chan' I'd like them to not appear, maybe only when
>> MISSING.
>>
>> I would expect this to work similar to 'fossil settings ignore-glob'
>> w.r.t. 'fossil extra'.
>>
>>
>>   Cheers,
>>   Jacek
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Turning off change tracking for certain files

2012-07-02 Thread Stephan Beal
Hi! No, there us no such mechanism in fossil. I sometimes have similar
problems with makefiles and config *files*, but i have never considered
that to be an scm-level problem (maybe it is?).

- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Jul 2, 2012 11:24 AM, "Jacek Cała"  wrote:

>   Hi All,
>
> I've got in my repo a small number of files that are changing but
> these changes are not meant to be send to the repo (are kind of
> user-specific). The files are needed in the repo but only in their
> initial or some specific version. Is there any way to turn off change
> tracking for some files? To be clearer, when doing 'fossil open
> myrepo' I'd like these files to appear in the filesystem but when
> doing 'fossil chan' I'd like them to not appear, maybe only when
> MISSING.
>
> I would expect this to work similar to 'fossil settings ignore-glob'
> w.r.t. 'fossil extra'.
>
>
>   Cheers,
>   Jacek
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users